The Zend of PHP

July 2007 saw the release of the 1.00 'production' release of the Zend Framework. To quote:

The Zend Framework project has developed solutions to solve frequent needs of web application developers, including the following areas:

* Powerful MVC framework
* Database access solution that balances ORM with efficiency and simplicity
* Lucene-compatible search engine
* Advanced I18N support
* Robust authentication/authorization classes and input filtering
* Rich web services client interfaces, including Google Data APIs and StrikeIron
* Many other useful classes to make you as productive as possible
* Thorough and high-quality test suites and documentation
* Open-source development process with an active community provides continuous review and testing

One of the many criticisms of PHP as a scripting language for web development is the lack of enforcement of separation of content from logic. Now Zend proposes an MVC framework for PHP.

MVC (Model-View-Controller) is usually associated with Smalltalk and the thick client even before client-server, let alone the web and RIA. MVC used in conjunction with frameworks such as Struts for J2EE is MVC in name only. The concern is this: keeping domain models and business models from being entangled in presentation issues. The web MVC variant is usually called Model 2 MVC. In Smalltalk, the evolution of MVC to Morphic (from Self) or to M/V without controllers (Cincom Smalltalk Widgetry) is a topic in itself. Dolphin Smalltalk has MVP (Model-View-Presenter) and provides a nice introduction at their Object-Arts site.

PHP starts with a bad rap for not having adequate modularity: it still lacks namespaces. Smalltalk itself is evolving to embrace namespaces and away from classic MVC so we have something curious occurring.

Here is what the Zend Framework appears to offer. I quote:
<qt>
Put simply; models contains your domain specific code such as a user class, views contains your templates, or view scripts as they are called, and controllers contains the files that process data to and from the models and views. Following this simple practice not only introduces a design pattern into your programming arsenal, but also organizes your code in a way that makes it more maintainable than a great many existing PHP applications.
</qt>
What we really have here is the front controller pattern that arose in J2EE in frameworks such as Struts where it is combined with a Command pattern.

In terms of security, PHP with the Zend Framework remains a filtering approach. What is not yet clear to me is how this chaining of filters and validators constitutes a framework. A Framework is not just a library of classes and certainly not a cookbook of recipes. A Framework can usually be understood as providing for the interoperation of services identified with components by enforcing constraints. The constraint might be: this service must be presented as an interface (now you are constrained to implement against a minimal abstraction.)

To have a framework it is not enough to have a class library providing a mechanism which removes ? and & from PHP URL's or adding more filtering.

You may want to check out the Zend Framework site with its webinar and demo wiki application. The site also links to manuals for the API and a developer reference. The latter opens on Access Control Lists; scroll down to find Controllers. What is missing is an overview of the framework such as is readily communicated by the Rails folks promoting Ruby. Having the familiar directory structure in itself does not establish 'convention-over-config'.

Perhaps whether you have 'c-over-c' comes down to 'GUI-shootouts', but that sort of thing does not impress architects concerned about security+maintainability. Saying you are using a 'framework' only goes so far. If what you meant is a library of classes that will be familiar to Struts developers, then why not Java with JavaServer Faces with jars, ears and Maven with the Spring 2.0 framework for security? What ties anyone to PHP in a business setting?

PHP has likley gotten to where it is because it posed no steep learning curve. And then it got a bad case of bloat. What results could be called 'wading through muck' rather than 'slogging uphill'. But when I arrive to perform on a maintenance contract, knowing what the framework was and that it was respected means a whole lot. Knowing what libraries were used gives very little indication of what you are in for.