Event driven programming
TomHAnderson opened this issue · 2 comments
I think this would benefit from event tie-ins. For instance I would like to build a configurable hydrator rather than use annotations. But there are many event models out there. I prefer Zend Framework. This repository seems to try to be rather framework agnostic.
Is the project open to building in events?
I generate my entities from orm:generate-entities and my schema is all in XML thanks to Skipper and I never use annotations. But I still think this library has promise for my methods.
A PSR-14 event manager would be great e.g. https://github.com/phossa2/event
I am not very keen on introducing events in this project. First of all I think events can be hard to use, because it is not always clear when and in what order they happen.
But most importantly we are on a very tight schedule with an internal project that heavily rely on this lib. And we must be able to move quickly and easily with whatever requirements we might have in the near future. For this reason we cannot afford to significantly increase the maintenance cost of this lib (with more complex code and wider API surface), if it does not answer a direct need for our internal project.
That also means non-annotation is out-of-scope for the time being. If you need a custom hydrator, then you can compose, or write from scratch, a DefaultFieldResolver. But if you need a custom type factory, then I'm afraid, you are on your own for the time being.
What we maybe could do is refactor getRecursiveClassAnnotations() and getClassAnnotation() into an interface and you could provide your own implementation that do whatever you need them to do (read from XML files).
But honestly I am not sure if it's worth the effort on your part (and mine). This lib has its own set of annotations and will never directly access Doctrine annotations, instead it will use the available ClassMetadata. So the fact that you do not use annotation for Doctrine entities should not prevent you from using annotations for this lib.