That said, I do quite like the characters on the Manning books even if the accompanying font choice seems a little dated. I imagine that having to choose book covers for tech books must be a painful experience if you don’t have something like the O’Reilly single-tone prints or these Manning characters. This old post on Manning’s forum really made me laugh though:

“As a frequent purchaser of computer books however, I feel that I would be remiss if I did not tell you how thoroughly the cover of the book sucks. It’s major league weirdo shit – and I mean that in the most constructively critical way possible.

Luckily, he wasn’t specifically talking about our cover which could be seen as representing the grace that Zend Framework brings to PHP, that, or it was the best one of the three they showed us. I do like the brown though!

So if you’re really missing what I have to say or need to tell me what you have to say, you can catch me in any of those places. Once the book comes out I’m sure I’ll have more time for this blog.

“Zend Framework already has a set of conventions. In my opinion it’s a good thing to improve these conventions even further and make them apply not only for Zend Framework, but for PHP as a whole.”

I suspect that Zend Framework will introduce an interesting dilemma for Zend and PHP where by improving more users experience and understanding of so called advanced programming concepts like OOP, design patterns, etc, they will also increase their expectations of the underlying language.

What onus that puts on the development of PHP itself is really the question. It may be a positive one, with PHP developers and those from other frameworks/languages able to move between their framework and Zend Framework more comfortably. The negative may be that Zend Framework is working on a layer above PHP to the extent that it begins to feel like a language within a language (something that Lukas Smith has been referring to in his Kiss my … post) and the nagging question then creeps in as to how much we are duplicating the functionality of a web development focussed language in a web development focussed framework? I’ve already started kicking myself for getting a bit carried away and unnecessarily using Zend Framework components when the same can be achieved with PHP.

An even bigger question that I’m dealing with right now is what to train new programmers in? The argument is almost endless, but the answer is rarely PHP for any other reason than ease of entry. If developers are going to be working at the higher level that Zend Framework has moved development to, then the question is why start new programmers with a programming language that is rarely recommended as being at that level?

Zend Framework is actually a good way to get someone into PHP and also make sure they keep away from so many of the bad habits that have plagued PHP development. But that is partly a case of keeping them away from PHP itself. Wouldn’t they then be better learning a language that is often used to teach programming, like Python, and once they’ve developed good habits introduce them to a framework for development? In other words I would prefer to have someone learn PHP via Zend Framework whereas with Python I’d be content to have someone learn Python and then a framework.

The question I know that only time will answer is what the cross-pollination will be between Zend Framework and PHP. Targetting that at the core developers I’m interested to know what future plans there are for removing and/or adapting Zend Framework features that become native to PHP itself and/or become more widely hosted such as 5.3′s namespaces against Zend Framework’s pseudo-namespaces.

Of course I’m not naive enough to think that Zend hasn’t thought about any of this, but then I’m not looking at it from that high up. From my perspective the disciplines that Zend Framework introduce actually open possibilities that are as lateral as they are upwardly PHP. Once you climb the Zend Framework mountain you begin to see it has neighbouring mountains that it has a lot in common with and that’s actually a good thing.

The story is that the book that we are co-authoring on the Zend Framework has now been released through Manning’s early access program. This means you can read it as we’re writing it, basically.

It’s certainly hard work, in particular trying to find the time alongside the “day job”, but nonetheless rewarding and I do have to say thanks to Rob for asking me to be part of the process. When he originally asked I was quite taken aback in a “why me?!” way.

Anyway, I’ll chat more about it now that it’s more official and if you’re interested please feel free to let us know any thoughts/comments/ideas through either of our blogs or the author’s forum. The point of this early access program is to get as much feedback as possible and therefore improve the quality of the final publication.

It will likely be preaching to the converted for many of you but having had the odd “why use Zend Framework” discussion I felt it would be good to write it down in some form. Feel free to brutalise it as you see fit!

As it’s a PDF, you might like to read it using this trick from Jon Udell: Vertical PowerBook as ebook reader. He uses a Mac but I’m sure you can achieve much the same on other OS’s.

The point of RewriteRouter is to map urls, like ingredients.com.au/recipe/tomato_sambal, to whatever controller, action and parameters needed without having to use external (and often painful!) methods like mod_rewrite.

For the sake of this article I’ll use a relatively simple URL…

ingredients.com.au/articles/cooking/

First setup some routes in a config file “routes.php”. Note that this does require the latest version of the RewriteRouter which needs to be checked out from the subversion repository…

$config['routes']['articles'] = 
new Zend_Controller_Router_Route('articles/:category', 
array('category' => 'all', 
       'controller' => 'articles', 
       'action'      => 'index' ), 
       array('category' => '[a-z_]+') );

This establishes a route called “articles” that will respond to any url of the form “/articles/whatever” with the colon in :category indicating that it is an url variable that can be recovered through Zend_Controller_Action::_getParam( ‘category’ ). The controller and action indexes make the action “indexAction” in the controller file “ArticlesController.php” the final target. To cover cases where there is no category specified the default setting “all” is given. For extra assurance :category has to be a string containing only lower case letters and underscores as indicated by the final requirements array.

Next load them into the bootstrap file using Zend_Config_Array:

$routes = new Zend_Config( 
        Zend_Config_Array::load( 
       '../application/configuration/routes.php', 'routes' ) );

Then create the RewriteRouter object and pass it the $routes…

$router = new Zend_Controller_RewriteRouter;
$router->addRoutes( $routes );

All that is needed now is to pass the $router to the front controller…

$controller = Zend_Controller_Front::getInstance();
$controller->setRouter( $router );

That’s it, now the routes are nicely stored outside of the bootstrap file and with the rest of the domain files.

Further Reading

Aside from the manual pages mentioned I can’t close without pointing to an actual recipe for tomato sambal !!

Endnote

I should also mention that it’s well worth getting involved with the development of the framework even if you can only do so in a small way. After a relatively short discussion via the issue tracker about having some means to load routes in one hit, Michael Minicki had implemented one (thanks Michael).

“Underware”

The engine, code-named “Underware”, that underwater.com.au currently runs on is built almost entirely (excluding a few additional class files) from my own code. Developed, via several projects, over the course of about five years from a modified version of the PHP e-Commerce application Freetrade and the FreeEnergy structure (Actually, it’s interesting to look back over that FreeEnergy article to see how it’s almost a Model-View-Controller structure), Underware is now more object-oriented, more MVC’ed and more woven with design patterns than its early incarnations, however it still has loose threads.

Why grow your own?

Considering the amount of freely-available, open-source, PHP code it seems idiotic to be doing it all yourself. Sadly, the number of applications available is no indication of their quality, nor whether they will play nicely together, a point taken up by Clay Loveless in his Stop Writing Loner Applications post.

At every stage of Underware’s development I looked at pre-existing solutions, hoping to find one that wouldn’t force me to duplicate components I already had, such as user management. It wasn’t necessarily that I had better code, more that what I did have was only what I needed. Besides, I knew as I worked on it the code quality would also improve. Inevitably, after spending many unbillable hours pouring through different solutions I’d look at the clock and think “I could have spent those hours moving forward and coding a solution”!

Pros of doing it all yourself

• You only build, debug and support what you need.
• You know all the code.
• You learn a lot.

Cons of doing it all yourself

• You have to build and support every bit of code and unless you build it it’s not just going to appear from somewhere.
• You have to document it all.
• You have to spend time researching solutions to every issue, including system level ones that are not directly providing solutions for your clients.

Thankfully the increasing amount of frameworks available (i.e. rather than finished applications) combined with the growing object-oriented’ness of PHP mean it’s less of an either or situation.

So why Zend Framework?

Honestly, I think because it feels right and I say that not to be facetious, but partly because I see so many lengthy arguments for and against such and such framework as if one or the other holds the golden key. Part of the reason I went back to my roots was to show the influences on my way of structuring web applications and if you’re interested enough to look into them you may see some similarities. For me the Zend Framework not only fits the way I’m currently working but moves it forward, tying up some of the aforementioned loose threads for example.

More pragmatically there are factors like the fact that my clients can worry less about being so totally dependant on me for every facet of their applications; I can benefit from all the external input to the framework itself; I can focus on solving client needs more and system level needs less and not to be ignored is the Zend part of the framework which for me puts at least some stamp of longevity and consistency on the code base.

Some further Underware influences

• Philip Greenspun’s Software Engineering for Internet Applications, in particular the section on content management.

• Design patterns picked up from various sources, but really understood in Head First Design Patterns and phpPatterns. The Head First Java is also a good read, particularly if like me you’re really only after a better understanding of OOP rather than wanting to specifically program Java applications.

• Marcus Baker’s articles on unit testing. I plan to read more about PHPUnit too but Marcus’ writing was really a good intro to a practice I must practice more of!

Some current Zend Framework reading

• Using Layouts with the Zend Framework
• Zend Framework Tutorial
• Blueprint for PHP Applications

“In your view scripts, often it is necessary to perform certain complex functions over and over; e.g., formatting a date, generating form elements, or displaying action links. You can use helper classes to perform these behaviors for you.”

Currently the framework (version 0.1.3) includes a small selection of form helpers which will no doubt expand as it matures. For now I’m more interested in the ability to add custom helpers for specific project use. The first thing I did was to set up the same directory structure as Zend_View_Helper as is suggested when subclassing controllers:

library/
    Zend/
        View/
            Helper/
    MyProject/
        View/
            Helper/

Having my project specific helper files in library/MyProject/View/Helper/ will make it easy to keep them separate from Zend core updates.

The next step is to tell Zend_View to look in the custom helper directory as well as the default Zend helper directory. This just requires adding the new helper path to the Zend_View object I created in the public_html/index.php file:

$view = new Zend_View;
$view->addHelperPath('MyProject/View/Helper');

Cautionary Note (* see update below)

The above is actually a bit of a fiddle to get working if you decide like I did to use a relative path to your helper files. I had set…

set_include_path( /home/exciting_zfw_site/library/ );

…pointing to the main Zend library directory, however, Zend_View_Abstract:: _loadClass() uses is_readable() as a check before loading any helper or filter files like so…

if (is_readable($dir . $file)) {
    include $dir . $file;

    if (! class_exists($class, false)) {
        $msg = "$type '$name' loaded 
                        but class '$class' not found within";
        throw new Zend_View_Exception($msg);
    }

    return $class;
}

…and since is_readable just ignores include paths, your new helper files won’t be found. This is currently listed as a bug but for the moment I simply changed…

if (is_readable($dir . $file)) {
    include $dir . $file;

…to…

if (include $dir . $file) {

…and it worked fine. Portability was the reason I wanted to keep the paths relative as I move files from a development server to the live server. It’s much easier to keep as few path configuration settings as possible.

The next step is pretty well documented in the manual but for the sake of completeness I’ll keep going. Create a new helper file:

class Zend_View_Helper_DoStuff {

    public function doStuff()
    {
        return 'Hello to you all';
    }
}

Another Cautionary Note

Something that caught me out was that the new helper class must be called Zend_View_Helper_YourNameHere rather than MyProject_View_Helper_YourNameHere which seems a little odd considering it’s position in the directory structure I mentioned before. While logically it is a Zend_View helper class, it will be kept with other subclassed files with your own “namespaced” class names under the MyProject directory so it seems to break a convention.

Ready to use

After saving the new helper file in MyProject/View/Helper/DoStuff.php it should be available to use in your view scripts like so:

<?php echo $this->doStuff(); ?>

When writing helper classes the key points to initially getting them to work are the naming conventions as illustrated by my doStuff example:

1. Class name must be Zend_View_Helper_DoStuff
2. The class must contain a public function doStuff()
3. The file must be save as DoStuff.php

As mentioned in my post on getting to know Zend_View elements of the above may well change as development continues.

Further Reading

View Helpers in the Zend Framework Manual

* Update

Forget the above hack…

if (include $dir . $file) {

…as it will produce warnings as Zend_View_Abstract::_LoadClass() attempts to include the doStuff file from any other path in the _path stack. Instead the only solution I’ve found to currently work is to specify a relative path like so:

$view->addHelperPath('../MyProject/UW/View/Helper');