Starting the 3.0 branch
Locked
12345
12345
 
|
Hi everyone!
(Sorry, I meant to send this earlier, but had some email issues.)
I'd like to begin the process of getting our 3.0 branch started.
Besides the obvious of making use of 5.4 features such as traits, I think we should come up with some sort of list of goals / ideas for ZF 3.0, to start getting an idea of what we want to work towards. I'll also be starting and maintaining a 3.0 branch in the near future so that we'll have somewhere to begin merging pull requests that can't fit into a 2.x release.
To get things started: - PHP 5.4 (minimum), utilizing features such as traits internally in the framework. - While we have the freedom to break BC for 3.0, we need to keep it much less dramatic as what we saw from ZF1 -> ZF2 -- we should keep track of BC breaks as we introduce them into a 3.0 branch and make sure each one is well-justified.
- Remove all deprecated methods and classes that are in 2.x for the purpose of backwards compatibility. - ??? Once we have some good ideas floating around, I'll compile them into a wiki page and we'll have something clear to start with.
Please do not bring up ZF2 support lifetime or which PHP version ZF3 should require in this thread -- if you want to have those discussions, feel free to start another thread. --
Evan Coury, ZCE |
|
|
Heya! Bakura (Michael Gallego) brought up this one up some time ago, but I lost the email, so I'll just put my ideas here for future reference (we may as well open an issue on the zf2 repository). Things I'd like to see in ZF3: - a general normalization in how the various service managers/plugin managers are used (the routing plugin manager is a good example for that)
- cleanups in the form API, especially all the lazy instantiation (init(), prepare()...), which are very confusing to newbs as well as experienced devs - (possibly) compilining the service manager - yes, you heard me - I will start writing a PoC this summer - Moving components with low activity out of the main repository - Removal of the PhpEnvironment HTTP request (in favour of a builder object, or such, instead) - More flexibility in the view layer (old issue I brought up before) - allowing to use `Zend\View\View` to render single view models and to use events pre- and post- rendering of each view model. We should stop the PhpRenderer from being accessed explicitly - Service scopes (not sure if that's possible): there's some services that should NEVER be requested via service location, because they may be internal to a particular component or such (the request object for instance). The service locator could lock access to these services when outside of the context of a service factory (tricky! not sure it's possible)
- Removal of newables as services ( https://igor.io/2013/03/31/stateless-services.html ), so if a break is possible here, I'd like to see it. - A rewrite of ZendDeveloperToolbar (should be up to me since I'm maintaining it) There's more, but this should be enough for discussion. Also: we need a better medium for this topic, since the mailing list will choke here. On 30 May 2013 15:21, Evan Coury <[hidden email]> wrote:
|
|
|
In reply to this post by EvanDotPro
- PHP 5.4[.13]+ :) ArrayObject bug fix was in this one.
- Zend\Stdlib\ArrayObject - Let's get rid of this :) Bug has been fixed (does not mean we don't still need to return by reference but hey the main bug is gone). - Zend\Session - Rewrite this to be event based rather than where it is today. The architecture of the session component likely needs to be changed and it would be good to remove the array object handling IMO (we could offer it but by default keep it to arrays). I'm also not a huge fan of the containers, although it is more of the default approach. Going more event based in this area offers far more flexibility and eases some architectural concerns especially in how we load the session data and then store it at the end of the request. I would also like to hook it into the end of the application cycle to make it more explicit rather than having to register a shutdown function. - Zend\Navigation - Rewrite this thing. The view helpers need to be far more flexible; even if we need to supply some wrapping classes for how we chain together HTML and do variable replacements. It practically has to be extended in 90%+ cases to derive the output in a flexible way.
- Zend\EventManager - provide a lightweight implementation as well as the full implementation. The event system today can be slow due to all of the flexibility. Some events could be made to be far quicker by simplifying what it does and provide more lightweight implementation for general usage.
- Zend\Validator - make setting error messages more flexible. A common case is providing a wild-card to cover all messages rather than having to set each one by key. - Ease the setup process; let's just put it out there because we often say just use the skeleton application... Our defaults should be easy, clear and concise removing a lot of the up-front configuration for default abilities. (I like it with out this but I think it would be better for the end user developer).
- Documentation more book style or something. We need to really get better on this OR maybe Zend can hire a technical writer :p
|
|
|
In reply to this post by Marco Pivetta
On Thu, May 30, 2013 at 9:21 AM, Evan Coury <[hidden email]> wrote:
- Remove all deprecated methods and classes that are in 2.x for the purpose of backwards compatibility. `Zend\File\Transfer` would have my vote for removal in 3.0.
On Thu, May 30, 2013 at 11:02 AM, Marco Pivetta <[hidden email]> wrote: There's more, but this should be enough for discussion. Also: we need a better medium for this topic, since the mailing list will choke here. +1 Maybe a wiki page or GitHub issue to track comments? |
|
|
@cgmartin github please - I can barely remind how you use a wiki nowadays :P I have found another interesting one:On 30 May 2013 17:57, Christopher Martin <[hidden email]> wrote:
|
|
|
In reply to this post by cgmartin
In my (non-module) setup, only application.config.php is needed and support for environment specific overrides (dev, staging, etc), this meant having an 'MVC Bootstap Config' https://github.com/zendframework/zf2/pull/4000. In my case, I ended up copying all the service config info into application.config.php. * Using composer as the sole autoloader, honestly, it seemed a lot faster than the ZF2 one, and it also moves all of the autoloading config setup to the very front of the app initialization which is sufficient for a minimal (non-module) application setup and alleviates any session related serialization issues. * Renaming MVC\Application, I think it should be called MVC\Manager or MVC\MvcManager, instead of Application. The reason being is that currently getApplication() forces 'Application' to be a reserved word for the framework code, and removes it from the real application layer ... it may not be so bad, if the Application object was actually more easily extendable (currently it takes some understanding of why you can't just override the class name in the main 'application.config.php' file). Similar thoughts could be applied to say the event manager, e.g getMvcEventManger() .... i.e. the component name in the method name makes it a little more obvious. * Removing the word 'Controller' from template file paths (which are resolved by namespaces), e.g /application/member/controller/index is unnecessary, harder to explain and organize etc.
On Thu, May 30, 2013 at 10:57 AM, Christopher Martin <[hidden email]> wrote:
-- Greg |
|
|
Answers inline
On 30 May 2013 18:22, Greg <[hidden email]> wrote:
I don't get this one - what's the difference with a 0-module setup? :|
Also a non-module setup can use `config/autoload` - we could make the config listener separate from the module manager (and inject it in the module manager instead)
Great +1 for this - composer was ditched because of some security related discussions that were brought up in the past. People can disable packagist usage if that's the problem. For the "global installation path" I'd rather ask Seldaek - he may know a better way of handling that.
It is an application though, so I'm -1 on this... The application structure is quite flexible already, take a look at https://github.com/BinaryKitten/ZeffMu for reference.
That's going back to magic - it may be more interesting to just pass the controller name to the view path resolver instead... |
|
|
In reply to this post by Mike Willbanks
On 30 May 2013 16:55, Mike Willbanks <[hidden email]> wrote:
Just FYI I implemented support for this, see https://github.com/zendframework/zf2/pull/4120 |
|
|
Let's continue the discussion here, but I've decided to start a Google Moderator for this so we can all add and vote on specific ideas and features.... I think this will help give us a clear picture of what the community wants for ZF3 without having to grok through this thread later. :) --
Evan Coury, ZCE On Thu, May 30, 2013 at 9:46 AM, David Windell <[hidden email]> wrote:
|
|
|
And I forgot the link, of course.... Please add all of your ideas and vote here: --
Evan Coury, ZCE On Thu, May 30, 2013 at 10:25 AM, Evan Coury <[hidden email]> wrote:
|
|
|
In reply to this post by Marco Pivetta
On Thu, May 30, 2013 at 11:43 AM, Marco Pivetta <[hidden email]> wrote: --
The hardest part to overcome is the understanding of the service configurations, and the fact they you'll spin your wheels trying to specify the 'Application' class in the application.config.php, because of the way the that the rest of the bootstrap process is handled. This is even demonstrated in ZeffMu application, it first statically calls ZeffMu::init() but then you later on, in the module layer, specify the class name of the Application object. But shouldn't specifying any service object be easily achievable via the application.config.php?
Basically the module manager is not much more than a glorified bootstrap handler, whereas for a 0-module setup, all of that can (or should) be skipped with a single config file (i.e. application.config.php). To get a better sense of this, you'd have to try and bootstrap the ZF2 application, without modules, and to try and specify your own application service config. I do think ZF2 should provide support for running an application without requiring a module manager.
The pull request does support config/autolod, there is the config_glob_paths setting for this. The point is that we can compile configurations without depending on the module manager. If I recall, the tricky part is the module events and (subsequent merging etc) .. hence they ultimately do the same thing, but one is not event driven.
My point is that when saying, getApplication() the first thought is, which one? By renaming the core MVC one, it removes any ambiguity, and leaves the developer free to define what they want to mean by the term 'Application'. As said, it might be easier if it was more easily extendable without having to drop to the module layer before being able to define what it is.
Isn't that already happening? The controller's namespace constitutes part of the controller class name... What I'm getting at here is the PSR-0 organization of a 0-module setup
namespace Application\Member\Controller; Application/Member/Controller/IndexController.php
namespace Application\Account\Controller; Application/Account/Controller/IndexController.php With composer's autoloader, and 0-module setup (there is only one template stack path), and a single config file, its efficient for a minimal application. Greg |
|
|
I suppose given recent events, we had to some work on Zend\Feed to
remove strict dependencies and put in place segregated interfaces to make it palatable for Drupal to intergrate (they are replacing a large stack of custom code). We should extend that to other components as much as possible IF NEEDED elsewhere. Now that we have Composer, stuffing a library with dependencies that drag in too much of the framework shouldn't be as necessary as it once was with PEAR. Paddy On 30 May 2013 18:27, Greg <[hidden email]> wrote: > > > > On Thu, May 30, 2013 at 11:43 AM, Marco Pivetta <[hidden email]> wrote: >> >> Answers inline >> >> On 30 May 2013 18:22, Greg <[hidden email]> wrote: >>> >>> >>> I'd like to see support for a bare minimal setup, i.e where the usage of >>> the module manager is optional: >>> >>> * One main configuration file, either application.config.php or >>> global.php. Its not very cleary what application.config.php is really about, >>> and its also very limited in its scope.. so far it seems its only purpose is >>> to specify which modules are to be used. >>> >> >> I don't get this one - what's the difference with a 0-module setup? :| > > > > The hardest part to overcome is the understanding of the service > configurations, and the fact they you'll spin your wheels trying to specify > the 'Application' class in the application.config.php, because of the way > the that the rest of the bootstrap process is handled. This is even > demonstrated in ZeffMu application, it first statically calls ZeffMu::init() > but then you later on, in the module layer, specify the class name of the > Application object. But shouldn't specifying any service object be easily > achievable via the application.config.php? > > Basically the module manager is not much more than a glorified bootstrap > handler, whereas for a 0-module setup, all of that can (or should) be > skipped with a single config file (i.e. application.config.php). > > To get a better sense of this, you'd have to try and bootstrap the ZF2 > application, without modules, and to try and specify your own application > service config. I do think ZF2 should provide support for running an > application without requiring a module manager. > > >> >> >>> >>> In my (non-module) setup, only application.config.php is needed and >>> support for environment specific overrides (dev, staging, etc), this meant >>> having an 'MVC Bootstap Config' >>> https://github.com/zendframework/zf2/pull/4000. >>> >>> In my case, I ended up copying all the service config info into >>> application.config.php. >>> >> >> Also a non-module setup can use `config/autoload` - we could make the >> config listener separate from the module manager (and inject it in the >> module manager instead) > > > The pull request does support config/autolod, there is the config_glob_paths > setting for this. The point is that we can compile configurations without > depending on the module manager. If I recall, the tricky part is the module > events and (subsequent merging etc) .. hence they ultimately do the same > thing, but one is not event driven. > > >> >> >> >>> >>> * Using composer as the sole autoloader, honestly, it seemed a lot faster >>> than the ZF2 one, and it also moves all of the autoloading config setup to >>> the very front of the app initialization which is sufficient for a minimal >>> (non-module) application setup and alleviates any session related >>> serialization issues. >>> >> >> Great +1 for this - composer was ditched because of some security related >> discussions that were brought up in the past. People can disable packagist >> usage if that's the problem. >> For the "global installation path" I'd rather ask Seldaek - he may know a >> better way of handling that. >> >>> >>> >>> * Renaming MVC\Application, I think it should be called MVC\Manager or >>> MVC\MvcManager, instead of Application. The reason being is that currently >>> getApplication() forces 'Application' to be a reserved word for the >>> framework code, and removes it from the real application layer ... it may >>> not be so bad, if the Application object was actually more easily extendable >>> (currently it takes some understanding of why you can't just override the >>> class name in the main 'application.config.php' file). Similar thoughts >>> could be applied to say the event manager, e.g getMvcEventManger() .... i.e. >>> the component name in the method name makes it a little more obvious. >> >> >> It is an application though, so I'm -1 on this... The application >> structure is quite flexible already, take a look at >> https://github.com/BinaryKitten/ZeffMu for reference. > > > My point is that when saying, getApplication() the first thought is, which > one? By renaming the core MVC one, it removes any ambiguity, and leaves the > developer free to define what they want to mean by the term 'Application'. > As said, it might be easier if it was more easily extendable without having > to drop to the module layer before being able to define what it is. > > >> >> >>> >>> >>> * Removing the word 'Controller' from template file paths (which are >>> resolved by namespaces), e.g /application/member/controller/index is >>> unnecessary, harder to explain and organize etc. >>> >> >> That's going back to magic - it may be more interesting to just pass the >> controller name to the view path resolver instead... > > > > Isn't that already happening? The controller's namespace constitutes part of > the controller class name... What I'm getting at here is the PSR-0 > organization of a 0-module setup > > namespace Application\Member\Controller; > Application/Member/Controller/IndexController.php > > namespace Application\Account\Controller; > Application/Account/Controller/IndexController.php > > > With composer's autoloader, and 0-module setup (there is only one template > stack path), and a single config file, its efficient for a minimal > application. > > -- > Greg -- -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative |
|
|
In reply to this post by EvanDotPro
Hi,
one important issue I want to mention is about module compatibility. ZF 2.0 modules must (!) work out-of-the-box with ZF 3.0 or a decent migration tool should exist when ZF 3 is stable. Otherwise we might piss-off some ZF2 users which created lots of modules. Im already added this to the Zend Framework 3 Ideas Google moderator stuff... Regards, Ralf |
|
|
Hey Ralf! I don't think that will always be possible, but that's why we use semver (http://semver.org/) to handle breakagesOn 30 May 2013 23:42, Ralf Eggert <[hidden email]> wrote: Hi, |
|
|
Im with Ralf on this.
Diego Sapriza @AV4TAr On Thu, May 30, 2013 at 6:57 PM, Marco Pivetta <[hidden email]> wrote:
|
|
|
But surely for ZF2 modules to work out of the box, there can be no BC breaks at all. Which defeats the whole point of starting the 3.0 branch. Where the migration from ZF1 to ZF2 basically would require a rewrite to use the new components, if the BC breaks between 2 and 3 are just document correctly, then migrating your modules manually should not be a problem.The problem that I forsee is that developers of open libraries then might have to support two version, one compatible with 2.x and one with 3.x. Any input on this?
On 31 May 2013 14:16, Diego Sapriza <[hidden email]> wrote:
|
|
|
You can just branch off a 2.x branch of your libraries and keep master (or develop, if you use git flow) aligned with 3.x. That's no problem, really - we already had that various times even for minor revisions of the framework.On 31 May 2013 14:23, Michael Gooden <[hidden email]> wrote:
|
|
|
This post has NOT been accepted by the mailing list yet.
This post was updated on .
In reply to this post by Ralf Eggert
-1 for modules compatibility. ZF 3 will be much closer to ZF2 than ZF 2 was to ZF 1, but as said earlier, the whole point of ZF 3 is to fix some design flaws, or make things better (allowing BC), so of course modules will need update.
Here are some things I've thought about: Validator / filter - Refactoring a bit the Validator and Filter components. I've always found architecture for validator messages a bit complicated. For instance, FilterChain uses a PriorityQueue, while ValidatorChain uses a plain array (which makes it more complicated for some components like InputFilter where priority could be very useful). - For Validator and Filter component, we should use PHP Filter extension when possible in order to reduce our code to maintain. I'm thinking here about e-mail, IP address, number, regex... iirc Filter extension has some flaws in some part, so this should be decided individually for each validator/filter we could replace (sometimes, some currently options supported are lost, while sometimes we have more features). Input filter - I'm currently refactoring input filter component using SPL iterators. Matthew asked me if I could do it for ZF 2.3, I won't think it will be possible, as I need to refactor validators too. Input filter are to my opinion an essential (and very good !) component of ZF 2. But so many features were added that it is now a bit slow and cluttered. Then, some additional input filters like File input filter and Collection input filter were added, but we kept all the edge cases in the Base input filter. This should be refactored to only support basic functionalities, and allow an easier extending through SPL filters. - Remove the "init" hook by simply defining factories directly in the framework to create input filter. Form - Part of my fault, but forms became unecessarily complex to support all kind of edge cases. We can have two choices here: either we keep the big complexity to support all edge cases, or we are clear from the beginning about what each class should support, and offer simpler way to override things (through events). Hydrator - Hydrator should have their own namespace as they are an essential component too. - They should be rewritten in order to take advantage of SPL iterators too (so that we can allow to create recursive hydrators). Router - Router is one of the nicest component to my opinion. But it didn't really embrace the philosophy of the service manager. They use a static factory method to create route, and it makes it a hell to override things. It should be slightly rewritten to follow the same logic. ServiceManager - Very great component. - Speed should be a priority, as this is the most used component. - We should find a nice way to allow options with factories. - Plugin manager should have a factory, so that the factory read the config file instead of using module manager listeners. This should be done to remove this: https://github.com/zendframework/zf2/blob/master/library/Zend/Mvc/Service/ModuleManagerFactory.php#L46-L111 It became boilerplate code and I suspect it not to be efficient. Testing - From my experience, testing was rather difficult when including only a part of the framework. For some reasons, I've had a lot of times where Travis told me that things like "Zend\Serializer\AdapterPluginManager" were needed, while not used at all in my code. The simplest solution was to simply add the whole framework as a require-dev dependency to make it works as expected. I suspect the service manager registers some factories or do something that throws all those errors. Session - This component is hard to use. I don't know, but so many times I simply end up using $_SESSION because it was not intuitive to use. - Save handlers should implement SessionSaveHandler interface from PHP 5.4. |
|
|
In reply to this post by EvanDotPro
As discussed on IRC, I also suggest dropping service manager canonicalized names (basically the normalization process happening in the service manager names). Will add it to the list, since it's basically causing problems in: * circular dependency trackinghttp://www.google.com/moderator/#15/e=207d6f&t=207d6f.40&v=24 |
|
Administrator
|
On Mon, Jun 3, 2013 at 10:22 AM, Marco Pivetta <[hidden email]> wrote:
> As discussed on IRC, I also suggest dropping service manager canonicalized > names (basically the normalization process happening in the service manager > names). Will add it to the list, since it's basically causing problems in: > > * circular dependency tracking > * abstract factories > * performance Can you detail your claims for the first two points, please? This is the first I've heard of them, and I'd like to know what the issues are... (I'm aware of the performance issues already, though you improved those greatly for either 2.1 or 2.2, IIRC.) -- Matthew Weier O'Phinney Project Lead | [hidden email] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc |
«
Return to ZF Contributor
|
1 view|%1 views
| Free forum by Nabble | Edit this page |