<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
<title>Keith's Web Blog RSS Feed</title>
<language>en-us</language>
<link>http://www.keithwatanabe.net/index.php</link>
<description>Keith Watanabe's Website</description>
<item>
<title>Zend Framework</title>
<link>http://www.keithwatanabe.net/blogs/2007/10/10/e10df66a2ddb5bf46e4e923927d862cf.html</link>
<description><![CDATA[I'm currently hacking away at the Zend Framework,  which is probably my one millionth framework (okay, maybe not that many.  I think I'm up to five or six now).  While it's got a lot of jazz, the thing I've come to realize is that these frameworks are nothing more than a bunch of hammers, nails, boards and glue lying around.  You still have to draw your own plans to get a basic house going.  Or in our case, a real workable website.<br />
<br />
The thing I hate about some of these frameworks is that despite preaching good practices by componentizing everything (thus decoupling code), they never actually attempt to enforce on their users true good practices.  For instance, the controllers provided by Zend can end up holding monolithic code and redundant.  You can dump all types of business functionality within one controller and then potentially copy the same functionality into other controllers.  Or your controllers may not necessarily follow the same programmatic flow that one may desire.<br />
<br />
It's surprising that these frameworks are not more strict considering the depth of knowledge of web programming that has been developed in the past 10+ years.  For instance, the main Zend action controller has a method called preDispatch which would allow one to place authorization and validation code that might be common between controllers.  Well, considering that most controllers require authorization and validation code, why not just house part of that code inside of there in the first place?  You're going to end up subclassing this class regardless just to create a base class that can be common between controllers.<br />
<br />
Another truly annoying &quot;feature&quot; (or lack thereof) is the authorization and authentication methods that come with Zend.  For authentication, you practically have to write your own adapter and wrapper just to get a simple login to work.  If you want to use it along with a PHP session, you then have to draw together those components on your own.  They only provide a thin wrapper just above the $_SESSION global, which still can be accessed.  I don't really see a point.<br />
<br />
Authorization is handled a little better, but you still have to provide the hooks.  It's far too barebones to really be useful.  You can employ it just to say that you're utilizing that piece of the Zend framework, but you're honestly better off just rolling your own authorization scheme.<br />
<br />
The most annoying thing is that there's no out-of-the-box login controller nor controller that houses the authorization logic.  There's no real hooks that allows one to tie their controllers easily into Zend's ACL components.  You're practically on your own to put in something that probably has been done a billion times in very efficient manners.  This is horrible.<br />
<br />
Next we come to the validation piece.  I've rarely seen validation done well.  The Zend framework is no exception.  It's nearly as bad as the Spring Framework's validation methodology.  The problem is that you cannot easily do declarative validation.  I basically want to say given a page, here are several fields and for each field, here is a set of validations with possible values to validate against.  The Jakarta Commons Validator does a much better job, except the XML validation is a pain to use.  Still that's the basic gist, combined with using something like Struts to automatically execute the validation piece.  On the other hand, in Zend, you're expected to put it in the preDispatch method.  I mean, if you already know you're going to expect validation to occur prior to an action, why not just strategically have a subclassed controller that comes with Zend handle the validation automatically?  Although I think the Spring Framework's controllers suck for the most part, the one thing they did do correctly was provide numerous out-of-the-box controllers for various purposes.  Zend only provides two.<br />
<br />
The Model layer was probably the only piece that was done halfway decently.  It's fairly easy to program and nothing I haven't seen before.  Considering the popularity of some frameworks like CakePHP, Ruby On Rails, and Symfony, I'm quite surprised that Zend left out the scaffolding code.  I avoided Symfony because I thought Plone and its scaffolding code was not handled very elegantly (for instance, forcing one to use their convention; legacy databases wouldn't be compatible).  Still though, scaffolding is very important in this day's competitive and overdone framework laden programming community.  It's shocking to see such a useful tool ignored (at least for now).<br />
<br />
Again, my biggest complaint is that Framework only organizes the more web  specific code from PHP into a more organized set of classes.  I think Frameworks like these need to impose even stricter interfaces and have more useful tools or objects that are well known so people can concentrate on the application logic rather than writing additional wrappers to improve the convenience of using some of these frameworks.<br />]]></description>
<pubDate>Wed, 10 Oct 2007 08:44:01 -0600</pubDate>
<guid>http://www.keithwatanabe.net/blogs/2007/10/10/e10df66a2ddb5bf46e4e923927d862cf.html</guid>
</item>
</channel>
</rss>
