Skip to content
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

Using ZF3 prototypes for hydrators and input filters #166

Open
bakura10 opened this issue May 20, 2014 · 10 comments
Open

Using ZF3 prototypes for hydrators and input filters #166

bakura10 opened this issue May 20, 2014 · 10 comments
Milestone

Comments

@bakura10
Copy link
Member

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.

ping @Ocramius @mac_nibblet @danizord

@bakura10 bakura10 added this to the 0.5.0 milestone May 20, 2014
@danizord
Copy link
Contributor

+1000

@Ocramius
Copy link
Member

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.

@bakura10
Copy link
Member Author

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.

@Ocramius
Copy link
Member

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

http://twitter.com/Ocramius

http://ocramius.github.com/

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
.

@danizord
Copy link
Contributor

Can't we work with experimental stuff in a separate branch?

@bakura10
Copy link
Member Author

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

http://twitter.com/Ocramius

http://ocramius.github.com/

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.

@Ocramius
Copy link
Member

As long as it doesn't land in the stable branch, it's fine.

@macnibblet
Copy link
Contributor

Yo, whats the status on this ?

@bakura10
Copy link
Member Author

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.

@macnibblet
Copy link
Contributor

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants