A review of the Zend Framework - Part 2

http://blog.octabox.com/2007/06/04/a-review-of-the-zend-framework-part-2/

[This is Part two of a three part review. Part one can be found here]

When I wrote the previous part of this review, covering the Registry and Database classes of the Zend Framework, the Framework was still at version 0.9.3 Beta. It has since reached version 1.0.0 Release Candidate, and interestingly enough, most of the changes affect the components I’ll be reviewing this time.

Zend_Controller, Zend_View - Model-View-Controller architecture

A Model-View-Controller implementation seems to be all the rage these days in web-development, and for good reason (though some wonder whether it realy is so). Briefly on the Model-View-Controller pattern - In a (web) application of growing complexity, it becomes paramount to separate logic from the presentational layer, allowing logic to be changed without requiring change in the presentational layer. Anyone who has developed for web in a straightforward manner, mixing client side code (e.g PHP) and presentational code (HTML, CSS), probably has noticed an increasing difficulty in making changes to a script as it grows in size and complexity.
In a manner of speaking, Style Sheets apply the same logic behind the MVC pattern - allowing separation of information from styling, and for reusability of styling code (Style Sheets). For more on the MVC pattern read the Wikipedia page or this article on PHPwact.

The Zend Framework provides the View and Controller parts of the MVC scheme, with the Model layer provided by the web developer according to the needs of a specific web-development project. Most models involve database access, and the Zend_Db_Table provides the building blocks for such models as I’ve mentioned in Part 1.

The Zend_Controller class hierarchy revolves around bootstrapping your application through a single script and instancing a Front Controller in that script (Zend_Controller_Front). The front controller handles incoming requests and dispatches them to Actions in Action Controller scripts (Zend_Controller_Action), Actions simply being methods (class functions) inside such controller scripts.

The Zend_Controller comes complete with its own Rewrite class (Zend_Controller_Router_Rewrite) which replaces usage of a server implemented rewrite module (such as Apache’s) for all purposes but the initial bootstrapping.

The Controller scheme of the Zend Framework also provides Request and Response objects representing the incoming server requests (Http or otherwise) and the corresponding responses, and allows to make modifications and retrieve information before and after the dispatching process.

Also available are Action Helpers and Controller Plugins which allow for the reuse of common code in controller scripts without having to subclass the original Zend_Controller_Action class.

All in all the Controller implementation of the Zend Framework is one of the most complete I’ve seen and certainly the most agile and extendable, however its not without its problems. Up until recently, the View integration in the Controller scripts have been rather non-existent. In previous versions of the framework, one would have to manually set up Views and their scripts which lead to some code redundancy inside a specific controller. In the latest versions, efforts were made to allow for a more streamlined integration of the View class in the controllers, providing several shortcut methods to instancing and rendering a View but it’s still not as mature as in some of the other PHP frameworks available.

The Zend_View class provides the View in the MVC scheme. There are no provided templating systems in the framework, so basic usage through the Zend_View would be rendering templates composed of HTML and inline PHP code. While this is my preferred method of operation, those who feel the need can integrate various templating systems with the Zend_View (here’s a nice article on integrating Smarty with Zend_View).

The Zend_View uses the __get() and __set() magical methods to dynamically insert and retrieve variables / objects in a View. Standard course of action would be to inject some data in the View through the Controller script using a model, and retrieve it for output inside the View (which is basically what the MVC pattern is all about).

Of course, the Zend_View comes replete with its own helpers scheme, which is little more than convenience method for calling up external classes called helpers. Since the framework provides only some basic form inputs classes at this point, the task of creating user interface classes is left to the web-developer. It remains to be seen if this would be remedied in the future, since other frameworks have provided an entire range of user-interface helpers, including some javascript and ajax integration.

Through the development of the Octabox project, I’ve created my own user-interface class hierarchy for abstraction of HTML and JavaScript operations, including a full set of Widget based classes that perform more advanced operations (such as the creation of the Octabox styled window and dialog boxes, the creation of the Tab based menues, custom select boxes and scrollbars and so forth), as the basis of the Octabox API, so I’m not holding my breath for any breakthrough helper design in the Zend Framework (and there is no indication one is forthcoming).

Zend_Session - Handling sessions

Sessions in the web environment allow maintaining state over Http, which is basically a stateless protocol. Users can be assigned unique identification strings which are used to identify them as they traverse a web site, and allow associating data with specific users (which is saved on the server).

Zend_Session encapsulates PHP session handling in an Object Oriented manner. Namespaces are used to segregate information, helping to avoid collisions (loss of data by accidentally overwriting it, a common occurrence with sessions) by promoting the use of different namespaces for different sets of information, and session namespace locking (preventing modifications to a specific namespace). A short blog on the perils of using sessions can be found here and another one on session security issues can be found here.

Also provided are several useful utility functions such as session ID regeneration, session expiration settings and session termination methods. All in all, Zend_Session helps avoid some common pitfalls when using sessions by using Object Oriented architecture without increasing complexity, and is a welcome addition to most a PHP developer’s library. It is used internally by Zend_Auth which I will cover next -

Zend_Auth - Authentication

Authentication in the web environment sense means confirming that a user is who he claims to be based on given credentials. The most common usage of authentication is via a Log-in form, where a user name and password are usually given (i.e. credentials), and are confirmed against credentials information on the server (i.e. authentication).

Zend_Auth provides several backends for authenticating (database, filesystem) as well as common methods for Http authentication (basic and digest), a full review of which is out of scope for this blog. Suffice to say Authentication results (called identity) can be stored into persistent storage, the default being using sessions (Zend_Auth uses Zend_Session internally in order to achieve session persistence). Authentication results can be a database row for example, which can include more than just the user name and password (Email address and user ID for example), the persistence of which can be very useful.

The persistence of identity via Zend_Auth is further enhanced by the fact that Zend_Auth is a singleton pattern implementation, meaning authentication results (i.e success/failure of which and identity persistence) can be called up easily from any script in your web application.

Zend_Auth and Zend_Session is a perfect example of two Zend Framework components working together without relying exclusively on one another (loose coupling, important!).

Zend_Cache - Data caching

Cache (pronounced cash) in computer terminology means storage of data which was computed / fetched previously. The purpose of cache is to provide faster access to commonly used data and to avoid the resource data fetching / calculation. Besides Http requests, which can’t be avoided (unless, of course, you do not wish traffic to your site), the two major resource consuming operations for a traditional web server are database queries and server side script processing (i.e. PHP). By caching data generated from such operations (such as dynamically generated web pages or database query results) into readily available data (such as into system memory or local file-system), much load can be taken off a web server (which is good for business).

Zend_Cache is the Zend Framework answer to PHP based caching solution. It operates by delegating the information gathering to a front-end class and caching the information using a back-end class.
Provided front-end class include a class for capturing output (using PHP’s output buffering), classes for caching function calls and object instances and classes for caching file-parsing results (such as XML) and complete HTML pages.
Back end classes for the cache result persistence are provided for file storage (basically turning dynamic content into static one for the duration of the cache), SQLite storage (a database implementation that is not actually an independent system process), memcached storage (a high performance object caching system), APC backend (Alternative PHP Cache, which is a PHP extension) and Zend Platform caching (which requires the Zend Platform to be installed obviously).

The operation of the cache is very simple - You gather the information you want cached using a cache front-end, and store it via a cache back-end. A check for cache existance is then added before the information is generated, and if the cache is found (cache hit) it is retrieved from the cache storage back-end instead of being dynamically generated.

Having used Zend_Cache for some time now, I feel that many PHP developers who might have shunned from caching for simpler projects because of lack of understanding and/or lack of motivation (I know I had this mindset until not so long ago) could definitely use this class as a standalone in almost every project, greatly enhancing their web applications performance.

Next week in the last section of this review, I will go over the Zend_Filter / Zend_Validate combo, Zend_Search_Lucene (a real gem!) and wrap up my impressions of the Zend Framework.

Comments, questions and clarifications are welcomed and appreciated.