Interested in the Zend PHP Framework

Zend, IBM and others have announced a collaboration project to create a Zend Framework using the following mission statement:

  • Keep PHP competitive among other technologies including Ruby-on-Rails, Spring, .NET, etc..
  • No framework today supports extreme simplicity
  • Provide “clean” IP to enable commercial use
  • Structured development process will lead to uniform code base
  • Take full support of PHP 5

The general community feeling on Planet PHP seems to be quite scared, as the new framework “threatens” to change the way PHP applications are developed, by providing a common set of tools and development methodologies. This is obviously a big change for everybody used to work either in the free-form fashion, or using one of the community-built frameworks.

The need for consistency

However, even though I’m a developer in one of the PHP application frameworks, I see the need for some standardization. Now the common ground shared between all the different PHP frameworks is just the language itself, forcing all projects to focus on building lots of low-level plumbing infrastructure instead of focusing on the features that could differentiate the applications.

Each application project or framework having to write their own low-level services means that by large the applications are not compatible with each other. If you want to for instance run a site that would contain blogs (using Wordpress), forums (using SM Forum) and photo galleries (using Gallery), each of them would most likely use different user and permission system, style templates and configuration tools.

This kind of inconsistency has lead to the state where each framework and CMS rolls their own instead of using the best-of-breed PHP applications. This means huge amount of wasted effort, and an opportunity for other programming environments like Ruby on Rails to pass PHP frameworks in functionality and appeal.

This situation is similar to the effort wasted by all the different Linux desktop environments in the past. However, instead of two or three serious contenders, the ease of PHP development has given rise to hundreds of different frameworks and content management systems. In the desktop environment scene, the different projects are already collaborating on lots of the base infrastructure, and are now starting to do the same in the look-and-feel space.

If done well, the Zend Framework could do the same for PHP projects. If done badly, it would merely introduce a yet another framework to the space.

Midgard point-of-view

Looking at the still-vapourwareish Zend Framework from the point-of-view of the Midgard Project, I see the possibility of benefitting from it. Currently MidCOM 2.5 framework is about 75k lines of code. Much of this is because functionalities like ACL and style engine have not yet been rolled into the Midgard Core, but also because lots of other base infrastructure like localization must still be done by MidCOM.

Now, if you think about Midgard, it consists of several separate parts:

Data abstraction layer

MgdSchema allows developers to abstract the database storage, and use query tools, access controls and extensibility with it. As common database abstraction is one of the Zend Framework goals, the way to access these tools would possibly change for PHP-level Midgard. But as Midgard’s scope extends outside the PHP world also to Java Content Repositories, using a straight SQL abstraction system would be out of question. It remains to be seen, if Midgard’s database abstraction layer could be used as a storage provider for the Zend Framework.

Style Engine

Templating and page assemply have traditionally been the strong points of Midgard, as often noted by CMS Watch. The power of it was slightly broken by the double standard imposed by MidCOM, but this is now getting wrapped back together.

The style engine and URL handling of Midgard is definitely something that should be still possible to keep as-is, even if something like Zend Framework would be used beneath.

User interfaces

The user interface layer would benefit a lot of collaboration and shared tools. We’re planning to follow Tango visuals and the GNOME Human Interface Guidelines to quite a big degree in Midgard. This part of UI is best collaborated using shared CSS rules and XHTML naming standards like Microformats.

However, form handling and AJAX are something where the Zend Framework could make things easier, consistent and more secure.

Development tools

The Zend Framework also has the possibility of making Eclipse the standard development environment for PHP development. As this is already the recommendation for Midgard developers, we are obviously eager to see the rise of better PHP tools for it.

So, what’s going to happen?

The Zend Framework project seems to be still a quite early stages, and despite claims that some code and specs exist, they still remain to be seen by the PHP developer community. Even in this stage, it would be crucial for the Zend Framework project to be available for peer review. Otherwise, it will be seen as just a corporate intrusion into the formerly open PHP framework space. Statements like this don’t help much:

We’re now working on setting up the collaboration infrastructure and engagement guidelines. We expect to have them ready by January 2006. In the meantime, we will use this medium to share progress on the project development.

I feel some urgency in seeing what is going on and planned in the project. The Midgard community is now starting to refactor the MidCOM framework to work on PHP5, and to utilize new language features like interface classes and exceptions. At the same time we’re starting to utilize functionalities moved from MidCOM to Midgard Core. This would be the optimal spot to take the Zend Framework into mind if it was available, making MidCOM even more consistent with the KISS ideology.

As we in Midgard community have quite a bit of experience with PHP component architecture, and with following strict coding standards, we could have some things to contribute to the PHP Collaboration Project, but unfortunately the process is still closed.

Read more Decoupled CMS posts.