Using ZF3 prototypes for hydrators and input filters
bakura10 opened this issue · comments
Hi,
As you may know I've been refactored hydrators as a ZF3 prototype (see here: https://github.com/zf-fr/hydrator) and I've also refactored input filter (still need to move it into its own repository until it is in ZF3). They both offer a lot of performance boost and more flexibility.
I'm thinking about using them in ZfrRest, but I'd like to know about you. What I want is to actually not breaking whole apps. So my idea is to register them under different key in the service manager: most likely "Hydrator\HydratorPluginManager" and "InputFilter\InputFilterPluginManager". This will not conflict the "HydratorManager" and "InputFilterPluginManager" of ZF2.
The other problems is that the keys "hydrators" and "input_filters" are (logically) taken by ZF2. I suggest having "zfr_hydrators" and "zfr_input_filters" key.
I'm also thinking about moving ZfrRest to PHP 5.5 too.
Do you think it is a good idea, or would you guys prefer that we stick to ZF2 components (for hydrators I think it's not a big problem, for input filters a bit more). My point is that if you're using ZfrRest, you likely have a REST application and Doctrine 2, so problems related to Zend\Form and Zend\Db using ZF2 hydrators and/or input filter is not that relevant.
+1000
I wouldn't use the prototypes in here.
Stick to ZF2 components. Eventually consider using 5.5 as a base, but stick to components. We can't depend on experimental stuff if we want any adoption.
We won't get any major adoption because of Apigility, anyway...
Envoyé de mon iPhone
Le 22 mai 2014 à 00:18, Marco Pivetta notifications@github.com a écrit :
I wouldn't use the prototypes in here.
Stick to ZF2 components. Eventually consider using 5.5 as a base, but stick to components. We can't depend on experimental stuff if we want any adoption.
—
Reply to this email directly or view it on GitHub.
Apigility is just a different approach to the problem. Doesn't mean that we
should move away from zf2 compatibility just because of some experiments
that we're doing.
Marco Pivetta
On 22 May 2014 00:25, Michaël Gallego notifications@github.com wrote:
We won't get any major adoption because of Apigility, anyway...
Envoyé de mon iPhone
Le 22 mai 2014 à 00:18, Marco Pivetta notifications@github.com a
écrit :I wouldn't use the prototypes in here.
Stick to ZF2 components. Eventually consider using 5.5 as a base, but
stick to components. We can't depend on experimental stuff if we want any
adoption.—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/166#issuecomment-43822420
.
Can't we work with experimental stuff in a separate branch?
I understand, but isn't little used packages like ZfrRest an ideal place to try new ideas and see if they fit to concepts ? :)
Actually all my ideas for the input filter refactor comes from my usage on ZfrRest, and they would actually help me a lot on zfrrest :)
Envoyé de mon iPhone
Le 22 mai 2014 à 00:27, Marco Pivetta notifications@github.com a écrit :
Apigility is just a different approach to the problem. Doesn't mean that we
should move away from zf2 compatibility just because of some experiments
that we're doing.Marco Pivetta
On 22 May 2014 00:25, Michaël Gallego notifications@github.com wrote:
We won't get any major adoption because of Apigility, anyway...
Envoyé de mon iPhone
Le 22 mai 2014 à 00:18, Marco Pivetta notifications@github.com a
écrit :I wouldn't use the prototypes in here.
Stick to ZF2 components. Eventually consider using 5.5 as a base, but
stick to components. We can't depend on experimental stuff if we want any
adoption.—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/166#issuecomment-43822420
.—
Reply to this email directly or view it on GitHub.
As long as it doesn't land in the stable branch, it's fine.
Yo, whats the status on this ?
Sorry I'm not working on ZfrRest anymore. On the various projects I'm working on I'm not using Doctrine and we're doing everything manually. More code but we like the explicitness and performance of it :).
If you want to take over this project id be happy to make you a maintainer.
@bakura10 I'm pretty much doing the same but I would like to use 2.7~ stuff from zend framework so if you could just merge my little pr and tag 0.5.0 :D?