On Monday 30 March 2009 12:00:10 you wrote: > Hi Benjamin, > > On 03/29/2009 10:57 AM Benjamin Eberlei wrote: > > I opened up an issue on ezPersistentObject to break up dependencies > > between the session and the 3 handlers load, save and delete. Currently > > their usage is only for internal reasons, but they offer huge > > optimization and extension points. > > > > Additionally despite the refactoring they are still to big in my opinion > > and additional features would only increase the handler classes, which > > would take up to many responsibilites. > > > > here is the ticket: > > http://issues.ez.no/IssueView.php?Id=14689&activeItem=4 > > > > My use case for this break up is the following: > > > > Data Mapping is quite a complex task and having generic load, save, > > delete components is not always the best way out in terms of performance > > or features and the single responsibility principle of OOP. > > > > I want to swap a delegate handler into the play, which based on the > > $class attribute decides which specific handler to call. This way I can > > build my own handlers for any entity that has performance issues or needs > > more special features. > > > > All the other entities could still use the shipped ezc handlers and > > benefit from its functionality. > > Regarding this ticket: > > I'm not sure if giving handler delegates to the session is a wise idea. > The intention behind the handlers was to simply split the very large > code base of ezcPersistentSession into smaller parts, which can better > be overlooked. Therefore the handler classes are marked as private by > now, since the user is not intended to use them dedicatedly. > > In addition, adding the handler instances as optional parameters makes > the interface bloated. There are only few use cases where it makes sense > to replace a handler. I could imagine that we outsource the handler > construction in the session into their own protected methods, though. > This way you can extend ezcPersistentSession and overwrite these methods > to create custom handlers > > Would that be a satisfying solution for you?
Creating a factory method on persistentsession would be nice I guess. But how does that come into play with the new identity persistent session? Are you going to create an interface and an abstract class for those? > > > For future versions of ezc there are additional benefits of this change: > > > > * New features like inheritence mapping or optimistic locking can be > > added into specific sub-class loaders and savers so that the already > > existing code does not get longer and more complex. > > * Performance Based Loaders with Association-Table-Mapping could be added > > into specific loaders that fetch an object and one ore more relations > > with one single select query and build them together correctly. > > * Use of Handlers should then be (optionally) configurable via > > ezcPersistentObjectDefinition > > I need to think about more about such things, since they were not in > scope of PersistentObject, yet, and I'm not sure how soon this will > come. I don't want to take the big step of making the internal handlers > public now and provide interfaces for them, before we come to the point > we really need them. This would result in loosing the opportunity of > breaking the handler API. I think the DataMapper pattern offers good extension points for all those features, and ezcPo being the only real data mapper (Doctrine to come end of this year i guess) in PHP, it would be nice if these features where available or could be added by the user at least. I see your case with the handler API, but since it is just a mirror of the persistent session API it is kind of public already. I know you want to hide as much as possible to keep it maintainable without having to work about BC and i really like the quality of the PO component that comes out of this policy. Still the component has numerous use-cases that differ just slightly from the way ezPo works currently, but they force you to switch or write another component, since you can't impose them upon ezcPo without rewritting most of the code. > > > This also affects the following issues: > > > > http://issues.ez.no/IssueView.php?Id=13127&activeItem=29 > > http://issues.ez.no/IssueView.php?Id=13264&activeItem=27 > > http://issues.ez.no/IssueView.php?Id=13177&activeItem=26 > > I'd like to see the features named in this issue, too. However, it won't > happen for the next release. Therefore we'll look at them again after that. > > Best regards, > Toby -- Benjamin Eberlei http://www.beberlei.de -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
