YMC AG, Open Source Web 2.0 Content Management

In 2006 the eZ Publish developers were planning the migration to PHP5. This effort was combined with further modularization. Generic "building blocks" were defined that should later form the basis of the new eZ Publish. All of these programs called "Components" had some equivalent in the "old" eZ Publish. And they are impressively stable and practically useful, as they resume the functional tradition of their their ancestors, which have provided tons of examples, test cases and best practices over the years:

• Cache
• Configuration
• ConsoleTools
• Database
• EventLog
• Feed
• ImageAnalysis
• ImageConversion
• Mail
• PersistentObject
• Template
• Url
• Workflow

The development of these components was done following a very strict process to assure highest quality. This process was in line with the principles of refactoring a grown system:

1. identify requirements a components needs to fulfill (based on the requirements of the component in eZ Publish)
2. create a design (based on experiences made with eZ Publish)
3. implement (with unit tests), review and freeze the API

Since that time all mentioned Components have reached maturity. One could argue that the original mission of the eZ Components project has been fulfilled. The "blocks" can be used to build a new generation of the eZ Publish CMS on top of it.

Unfortunately, only few steps in this direction are taken. Instead new components are written, that do not have a direct ancestor in eZ Publish:

• UserInput
• Search
• Tree
• MvcTools
• Document

In my opinion the original development process doesn't fit for these new components. Their requirement and design phase can't rely on experiences from years of practical use of eZ Publish. As a result, more and more Components are published that have a stable API, however could be improved by altering the API based on experiences made using the components.

For example:

• UserInput is considered unusable even by its creator
• Search doesn't give you full control over SOLR (see the "ezcSearch Feedback" thread in the components mailing list)
• Tree requires the user to use a NULL column in a table, where only the root node could ever be NULL
• Authentication handles the session variable in a very unorthodox way
• The Lazy Initialization mechanism makes it necessary to copy and paste the same code for every component.

Since there is no public listing of projects that use eZ Components, nobody knows which harm would be done by fixing some of the above issues, giving up backwards compatibility thereby. The feedback on the mailing list makes it obvious, that some components are heavily used in production projects, whilst others (SignalSlot, Tree) might be used only by a handful of private projects. Still, the strict backwards compatibility rule applies to all components.

While so much effort is put into backwards compatibility there are still things that break, so actually the goal isn't fully achieved. For example a new feature of the PersistentObject component (IdentitySession) made two subtle changes that broke code of mine and of another eZComponents user:

• An array of persistent objects returned by the PersistentSession isn't indexed from 0 upward anymore, but indexed by the objects ids.
• PersistentSession::createFindQuery doesn't return an ezcQuerySelect anymore, but an instance of ezcPersistentFindQuery.

I see no problem with such breaks. Any developer needs to test before upgrading anyway. Therefore I suggest that, three years after the start of the Components, it is time to take a break and reconsider the mission, the process and the results. Do all the guidelines from three years ago still make sense? How can contributions become a better part of the general concept? What about Project V? While some components are included in the old eZ Publish there is still no public discussion about the development of Project V.

2006 there were 10 people at eZ Systems working full time on the Components. Many errors could be avoided in the design phase. Today, there are only 4 people payed (part time) to look over requirements and design documents. Naturally, 4 pairs of eyes will identify fewer design errors then 10 pairs. It would be helpful to know what priority eZ Systems actually assigns to the Components.