Friday, June 4. 2010State of Zend Framework 2.0The past few months have kept myself and my team quite busy, as we've turned our attentions from maintenance of the Zend Framework 1.X series to Zend Framework 2.0. I've been fielding questions regularly about ZF2 lately, and felt it was time to talk about the roadmap for ZF2, what we've done so far, and how the community can help. Zend Framework 2.0 Roadmap2.0 marks the first new major release of Zend Framework, and, as such, is the first time we can break backwards compatibility. Major releases are generally of two flavors: large, new featuresets, or rewrites and refactoring to fix architectural concerns. ZF2 falls primarily in this latter category. I posted a rough roadmap in November on the ZF wiki, to which we received a lot of feedback. Several ideas we brought up that were contested, and we re-considered many of the decisions and goals we outlined as a result before we started implementation. Also, around 5 or 6 weeks ago, I started a discussion with Bill Karwin, who led the project from mid-2006 through the 1.0 release in 2007 and slightly beyond. He had some solid feedback on the nature of the roadmap, and with this information, results of a poll we did late last year, and feedback I've had via mailing lists, IRC, twitter, blogs, and more, I published a new roadmap that focussed less on implementation detail while firmly and succinctly stating the requirements for the project. Stated in a sentence: The primary thrust of ZF 2.0 is to make a more consistent, well-documented product, improving developer productivity and runtime performance. The basic goals are as follows:
We also stated several general development objectives for those contributing to ZF2:
For more detail on each of these goals, I encourage you to read the document. What has been accomplishedWhile the roadmap has only really stabilized recently, that does not mean we haven't been working steadily on its development. There were some objectives we anticipated as early as 2 years ago. Among these were migrating the project to namespaces, providing infrastructure to allow cherry-picking components for packaging, and updating the unit test infrastructure to make better use of more recent PHPUnit features. Shortly after 1.10.0 was released, I created a temporary git repository on my own server, and started work. The first task I did was to update the unit test suite and analyze all class files for dependencies to assist in the namespaces migration.
After completing this process, my entire team -- all three of us -- started
the work of migrating the code to namespaces. Ralph wrote a tool that scanned the
library and created a map file of existing classes and suggested
namespace/classname combinations. We then used this tool as a launching
point for the migration, each of us working on a component at a time. This
work was by no means automated -- we discovered very quickly that such a
tool only took care of the most cursory work. I detailed some of
our findings a couple months back; we ran into a number of issues we
never anticipated, and the progress has been far from speedy. At this point,
however, we have migrated everything but the We also rewrote a few components during this time, as we discovered inconsistencies or in areas where we had problems with unit testing. One such is a component that has been a pain point basically since its creation: Zend\Session. The new design gives a good idea of what can be accomplished during a focussed rewrite, and by using 5.3 features where they make sense, and I'm very pleased with how it turned out.
In parallel with this effort, I also did a fair bit of research determining
how we would offer our Git repository and
workflow. We're going for a fairly traditional workflow where only a small
handful of developers will have commit access, and all other contributors
will submit pull requests to those developers -- for everything ranging from
documentation fixes to bugfixes and feature topics. To ensure that those
contributing have signed a CLA, we have created a The official Zend Framework 2.0 Git repository is available for cloning:
The helpful folks at Github have also kindly provided a mirror of the repository; our hope is that contributors can fork from there in order to collaborate on new features and bug fixes. (I've also cloned it under my own Github account, for those who want to issue pull requests.) Warning! Zend Framework 2.0 development is in very early stages, and should not be used for developing production applications. In fact, the APIs will change in the coming weeks and months, and should not be relied on for really much of anything. Community InitiativesA number of new initiatives have sprung up in the last week surrounding the community's involvement in the ZF2 process. The primary goal of my team has been to get the library migrated sufficiently so that we can open the repository to cloning, and allow contributors to begin working on initiatives to improve the framework. This is now possible, and several other initiatives are emerging. Several community members have put forth the idea of a community review team. This effort is still taking shape, but the basic goals are:
For more information on this effort, please review the thread on the zf-contributors mailing list.
A number of contributors are also starting to discuss rewrites and
refactoring of components. Much of this is being done on the
End NotesThese are exciting times for Zend Framework development -- the first time we can break backwards compatibility since the 1.0 release, and a chance to participate in cutting edge PHP 5.3 development. While the process has been slow, it's also been incredibly rewarding and a huge learning experience -- and I'm glad I've had the chance to participate. I hope you'll join us! Comments
Display comments as
(Linear | Threaded)
It's a great work! And could you tell me when I can get the first beta/release version?
Nope. We're still planning out the milestones and dates.
I personally look forward to the implementation of Design by Contract in ZF. Having read Object Oriented Software Construction by Bertrand Meyer (the inventor/chief proponent of DbC) I would say it is one of the critical pieces missing in modern software architectures and would definitely recommend it for inclusion in the framework -- though I am curious how that would be done, since PHP does not natively provide the mechanism. See also http://www.eiffel.com/developers/design_by_contract.html in particular the slide presentations.
Thank you for this update! Great to see things moving along. Do you have any very general beta release timeframe in mind? I'm talking really general, such as 2010?
Thanks again, Jason In general is there a target date for 2.0? I'm guessing 2011 some time.
To all asking for release dates: we hope to have a release of some sort no later than Q4 of this year -- whether that's an alpha, beta, or final is still to be determined.
Looking foward for this release, doing my thirty system with ZF, and i really think it has a lot of point to improve. Especially a way of seeing the helpers methods in the view, and a more focused and specialized approach, like for web applications development, and not so generic.
One thing i think would really improve the start of a new ZF user would be a full web application demo with all the good practices implemented, ACL, AUTH, LAYOUT, INTERNALIZATION, MODULES, NAVIGATION, ROUTES, FORMS, VIEW HELPERS, CONTROLLERS HELPERS, CONTROLLERS PLUGINS, ORM. All this in a integrated way. Forget to say, other thing that would be great is a easier and better repository for people post theirs custom elements like Form Elements, Filters, Validations, View Helpers and so on, in a more open and social way.
I would like to see some attention on the performance of the framework?
It looks like the actual MVC is a little bit slower than some other php frameworks. It's actually one of the goals I stated in the article. If you follow the links to the requirements document, we even stipulate gains of 200-300%.
From the benching I've done, a good part of our issue is with class and plugin resolution, and there are some easy ways to correct those situations. haven't heard much about distributed modules. i think this is something that can really help take zf to the next level. having a huge extension/plugin repository is huge. just look at jquery, wordpress, joomla, etc
Hi Matthew,
I'm looking at the BC-Breaks file in your github repo.. The new class and function names are inconsistent! * "Zend_Server_Reflection_Class" becomes "Zend\Server\Reflection\ReflectionClass" * "Zend_Server_Reflection_Function" becomes "Zend\Server\Reflection\FunctionReflection" * "Zend_Server_Reflection_Method" becomes "Zend\Server\Reflection\ReflectionMethod" * "inherits()" renamed to "resourceInherits()" * "remove()" renamed to "removeResource()" * "removeAll()" renamed to "removeResourceAll()" ... This is cool! For my opinion the following changes should be done:
1. Refactoring the Zend_Application, Zend_Loader and Zend_Loader_Autoloader. I think Zend_Application (and Zend_Application_Bootstrap_*) should be changed for better implementation of IoC container. One of my suggestion is have convenient way get any loaded object from any place from container without using of Zend_Registry. Zend_Loader and Zend_Loader_Autoloader should be changed for better perfomance and removing unnecessary code. 2. Must have the Zend_Tree and Zend_Db_Tree_AdjacencyList, Zend_Db_Tree_NestedSet, Zend_Db_TreeMaterialized components. Working with trees in database is very frequent used operation. But for now ZF does not have this components and this is very weird. 3. I am very happy that code speed will be improved and we will have capability of use only required components from all framework (not all framework). Thank you! I have one more request about ZF2 - TO BE EASY TO MIGRATE TO RAILS
Yes, it will be awesome framework if be able to migrate easy to Ruby on Rails
1/ Seriously, ditch the old zend_form with the decorators pattern. It . just . sucks.
And/Or include an element that does not nothing but generate arbitrary html. Would really be helpful ! Ifind myself too many times having having to print the form (action/method/etc) and all elements separately just to control/add the html around. 2/ One thing that bugged me a lot a the beggining was "where do i put files like my decorators, filters, validators etc ?" In the library/zend (oh no), in a "home-brew" library, in some folders like models ? "Tell me !" Extending classes in ZF is really easy and can save lots of time because web is often almost identical tasks. But the Quickstart (and basic project structure) doesn't really help you to jump into that because of the needed autoloading. That's a missing part in ZF of what a framework shoud be doing to its user. 3/ I think the ajax implementation is a bit overwhelming ( init actions in controller with propers formats, then re-asks the format in the data sent etc 4/ Doctriiine. 5/ Seriously, does people really use Dojo over jQuery ? It's sad to feel "like a subcitizen" when using jQuery with ZF. 6/ Give all the options in the documentation !! Example : The Alnum validtor : "This validator includes an option to also consider white space characters as valid." So ... how to I use this option ? The doc leave you there .. Oh and the search option does not find much (try "Alnum" !) I know many of my remarks would seem stupid or trivial to a experienced ZF developer but this is exactly NOT the point Matthew, please bring the ZF Lucene support up to date with the main apache Lucene project - it's way out of date.
Thanks! Tom What ZF really need, in order to be used at enterprise level:
1. Better PDF module - not just the useless drawText, but tables, forms, etc. Have you ever tried to create an invoice with Zend_Pdf? 2. Really good and up-to-date module to work with files - Excel, Word, etc. Pear_Spreadsheet is very limited and outdated, so it is not a solution. Have a look at PHPExcel and PHPWord. PHPWord is not at v1 but PHPExcel has been for a long time. I have used it and it meets almost all of my needs - can't create charts yet.
I really like the direction the top tier PHP frameworks are taking.
ZF sold itself as easy to use. For very advanced PHP experts perhaps. But for intermediate programmers like myself it is far from easy to use. And the documentation, even paid documentation, isn't much help. My suggestion: full and complete documentation that clearly explains everything and does not leave the user guessing.
Please note that documentation reorganization is one explicit goal of the ZF2 milestones. We aim to have all components provide documentation in a specific, predictable way, which includes documentation of all configuration items, use cases, etc.
Une interesting thing I´m doing right now in a project, is using the Zend Framework inside Moodle. So it may be good to document how to use some components alone, like Zend_View.
I'd actually argue that our documentation _currently_ does that, and does a poor job of showing how to use components together. The Zend_View documentation, for instance, shows using Zend_View as a standalone component... and there's not much information elsewhere on how it integrates with the MVC (other than that it's present and you can assign variables to it).
Add Comment
|
Calendar
QuicksearchLinksArchivesCategoriesSyndicate This BlogShow tagged entries |
|||||||||||||||||||||||||||||||||||||||||||||||||





There are no shortage of PHP frameworks, some grow large vibrant communities and a number wither and die over time. A number of the larger frameworks by user base have announced plans for the next steps in their evolution. Specifically we examine the n...
Tracked: Jul 27, 01:06