-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments about EventHandlerInspector #4
Comments
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. |
only short reminder for later, because I have no time atm to valide it: |
You need to split compile and runtime anyway, as otherwise this stuff is going to be terribly slow |
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. |
@codeliner could be potentially useful, I don't know disco so I can't really say. |
yeah, I thought of it more like a reference implementation using annotations + proxymanager. 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. 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. |
There's a cache warmup for non-container stuff, and the container itself is usually dumped as plain php |
@Ocramius thx! I'm looking for a way that could work for us:
|
AFAIK controllers must be registered in the routing. See http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/routing.html#activation |
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 |
great hints, thx @UFOMelkor |
see: https://github.com/mrook/annotations/blob/master/src/EventHandlerInspector.php#L29-L40
can't that be done lazy within findMessageInvoker() method?
The text was updated successfully, but these errors were encountered: