On the eve of the release of the Zend Framework's 1.6RC, found it interesting to read Lukas' comment on Matthew Weier O'Phinney's blog about how there were outstanding issues in existing core components of the Zend Framework that hadn't been resolved, and yet the Zend_* component library was still growing and accepting new proposals.

The last comment by Martin noted that Zend_Db still had some unresolved issues for over a year.

Matthew's response was that this was a community project and that priorities are dictated as such. Personally, this doesn't affect me because I'm hedging my bets on Doctrine as an ORM layer for PHP development.

I like Matthew's response because the Zend Framework's philosophy encourages the development of loosely coupled components wrapped up in a development philosophy that encourages open contributions, financial backing (thanks to Zend, IBM, Sun and others), Unit Testing and project transparency. Here's where things go a little wonky.

Partnership with the Dojo community

While I really enjoy the implementation of Zend_Form on the server side. It allows multiple configurations, supports validation and while the decorators are a bit obtuse, on a whole, the Zend_Form libraries thin out controllers and encapsulate the concern of data entry in a clean manner.

In this point release, however it seems like there's been a whole outgrowth of Zend_Dojo_* classes that cater to doing AJAX development with the Dojo stack. I'm not sold on Dojo as a client-side framework. Past experience with it has left me trying to sort out a large, over-specialized collection of patterns that almost do what I want but not quite. I also don't like the coupling that occurs between the data set, the client-side validation and the magic rendering of panels (like Accordian's and content panes).

An alternative architectural approach

I would rather write the events, the theme, the data and the validation separately and reduce duplication in each of those patterns rather than in the UI pattern as a whole. In short, I think they've abstracted the wrong part. The same example can be seen in ASP.NET form validators from two years ago.

With Prototype, I can rapidly mock out a site with the functional requirements and use Script.aculo.us to accent the presentation with animation. My functional specification isn't muddied with fancy visuals and it lets me focus on the event handling, validation and end states rather than the fancy effects.

By using Zend_Dojo, you won't be tempted to build a well-exposed Service Layer from Zend_Controller. The advantage here is that you lead development towards service-orientation. If you need to write a Flex front-end, or a whole new business-tier, you at least have the beginnings of a web service, whereas if your working with Zend_Dojo's declarative templating syntax, you're already coupling the events, validation and data into heavily abstracted UI patterns.

This approach doesn't lead development towards the production of a refined Service Layer, but to a specialized Dojo-friendly interface with markup-generation from Zend_Form classes into Dojo markup. I would rather see a Zend_Form Service API where developers can send / receive JSON messages to inherited Zend_Form and then have the Dojo community write an Adapter that would send / receive messages from Dojo widgets.

A year or two from now, I wouldn't be surprised if people will look at the same Zend bug tracker, asking where support for Dojo went after the Zend team jumps to the next cool Javascript framework on the block and we find ourselves with Zend_Form_SproutCore or some other dependency.

Tagged as: Commentary, design, dojo, Zend