Comments about EventHandlerInspector about annotations HOT 11 OPEN

You need to split compile and runtime anyway, as otherwise this stuff is going to be terribly slow

from annotations.

Possibly, reason I'm doing it here is because of the implementation of doctrine-annotations. With a better cache setup, we could think of a lazy inspect.

from annotations.

only short reminder for later, because I have no time atm to valide it:
I've added a feature to disco recently. Disco uses doctrine-annotations to set up a DIC. Besides that, it uses ProxyManager for lazy loading. Maybe same combination can help us here? /cc @shochdoerfer @Ocramius

from annotations.

Not sure what is needed but a feature I have in mind for Disco since a while is this: Basically a change to allow to register custom annotations that generate code for custom wirings, e.g. to easily configure routings or security ACLs. Might also work for this case.

from annotations.

@codeliner could be potentially useful, I don't know disco so I can't really say.

from annotations.

yeah, I thought of it more like a reference implementation using annotations + proxymanager.
I don't know how Symfony handles all those bundle annotations. They all need to be cached somehow.
@prooph/symfony-team Does anyone know that?

A global annotation compiler + cache would be nice. Some prooph users also want to use JMS Serializer for payload serialization. If you want to go the annotation way you could use Disco as DIC + JMS + prooph/annotations and get a nice annotation-driven framework.

At the moment I'm really looking for ways to make working with prooph easier. Once you've understood the different parts and how to use them prooph is just great, but getting there is hard.
I worked on a side-project with exactly that goal: event-machine
It uses a programmatic approach rather than an annotation approach, but in the end both have the same goal: reduce boilerpate, increase development speed and improve experience

Turning a POPO into an aggregate with just a few annotations is great and could really help to understand some bits of Event Sourcing more easily. So I hope we find a good way to make it production-ready.

from annotations.

I don't know how Symfony handles all those bundle annotations. They all need to be cached somehow.

There's a cache warmup for non-container stuff, and the container itself is usually dumped as plain php

from annotations.

@Ocramius thx!
I'm wondering how annotation parsing is organized?
You need to point Doctrine to the entity directory and then Doctrine parses all entity files in there.
Disco needs to be pointed to an annotated configuration class.
How does a Symfony bundle know where controllers are located to parse REST, ROUTE or ApiDOC annotations for example? Is it based on conventions like controllers are always located in MyBundle\Controller ?

I'm looking for a way that could work for us:

• configuration: tell annotation parser about all annotated classes
• conventions: aggregates are in Model/, commands are in Command/, ....
• scan all files of the project
• tbd

from annotations.

AFAIK controllers must be registered in the routing. See http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/routing.html#activation

from annotations.

Possible interesting too: The JMSDiExtraBundle (allows service injection via annotations) uses configuration to parse also non controller classes: http://jmsyst.com/bundles/JMSDiExtraBundle/master/configuration

from annotations.

great hints, thx @UFOMelkor

from annotations.