Review: PHP|Architect’s guide to programming with Zend Framework

Here it is, the first book review on Scriptorama! And in English instead of Dutch, no less. Don't worry, I'll be switching back to our regular programming right after this posting .

I'll be taking a look at The PHP|Architect's Guide to Programming with Zend Framework, written by Cal Evans. After reading Ivo Jansch' review I got excited about it. I had been meaning to look into Zend Framework some more after a brief stint with it a few months ago. As a previous user of ZF, I was looking for a book to teach me the "right way" of using the Zend Framework. You know, best practices. So, I ordered the book and had a look.

Title:: PHP|Architect's Guide to Programming with Zend Framework
Author: Cal Evans
Publisher:: PHP|Architect
ISBN:: 978-0-9738621-5-7
Available through:
: PHP|Architect. It seems Dutch webshops haven't picked up on this book yet (I checked BOL.com and comcol.nl)
Website:: http://www.zfguide.com

The good

First off, I like the PHP|Architects Nanobooks collection. I have most of the books from the collection at the time of writing, so call me a fan. One particular useful thing is that if you buy directly from PHP|Architect, you'll also get the book in PDF. I always told myself I didn't like reading through PDFs but as I went through the PDF waiting for the paper-version it actually wasn't so bad. Searching in a PDF beats flipping through a book any day.

On to the book. The idea of the book is that you're slightly experienced PHP programmer, having a good grasp on OO (in PHP5). During the first chapters Mr. Evans will teach you how to setup a Zend Framework-based application, introducing the elements of Model-View-Controller step by step.

The book is easy to read and has a pragmatic aim at things I think webdevelopers are looking for these days: once you've implemented a basic webservice (Yahoo! and Flickr) consuming application using MVC, Mr Evans moves on teaching you how to implement AJAX actions within the MVC framework, ease maintenance by using Zend_Layout, set up your own ReST webservice and will even show you how to call a Controller from the commandline for maintenance purposes. These were the sections I particularly enjoyed.

The bad

There are however a few things that did annoy me. One thing that sort of amazed me (not in a good way, sorry) is the fact that there is a whole chapter, specially named as if it's the coolest thing since sliced pizza^H^H^H^H^H^Hbread, introducing a custom convenience class to access various components used throughout the demo application. While the idea is good enough, I don't understand why Mr. Evans didn't just use the readily available Zend_Registry class there, and instead spent an entire chapter introducing something custom.

Another thing is that some time is spent on asking you not to do particular things. Like not using a certain technique or not using the API codes shown in the book. Then you turn the page and the technique is used anyway and the full API codes are available in the book (and even the sourcecode)! I feel that if there was less of that, by just doing the right thing the first time around and just not showing ANY API codes (get your own, they're usually free!), there would've been more space to touch other interesting subjects now missing from the book, like Zend_ACL or I18N.

Conclusion

In conclusion: yes, the book has a few rough edges, things I don't quite agree with, but if you're able and prepared to look through these, it really is a nice introduction to the Zend Framework and if you are interested in working with Zend Framework, I would certainly recommend taking a look at it to get you started.

Reageer ook!

Hi!

Thanks for the review.

I get questioned about the Globals class a lot and specifically asked why I didn't just use the registry. The answer is twofold and the first part is not very good I'm afraid.

1: I've been using the Zend Framework since long before the Zend_Registry class was implemented. Globals is a strategy I stole from someone else, modified it to make it my own and it's one of those pieces of code that just works. I do use Zend_Registry in projects and you are right, it would be possible to replace some of the functionality of Globals using the Zend Registry.

2: I really like Singletons. PHP has various methods of faking a singletons but the language itself does not support them natively.

Take for instance the $_db. I could, using the registry, either check when I need it using an IF/THEN statement when I need a database connection and then create it if I need it and store it in the registry. That would work and honestly, for the number of times in the sample application that I actually use a DB connection, it's not going to affect performance at all. However, I find it easier simply to make the static call to Globals and let Globals figure out if I have a DB connection already and if not create it. This also saves me from just creating it somewhere in the page initialization on the off chance that I will need it. There is one thing that people (including Ivo himself) have pointed out to me about this and I’m the first to admin that this is a failing of Globals. If you need more than one DB connection, you have to hard code it. This is bad and I know it. Future iterations of Gloabls may make $_db either an array or a registry object. In this particular case, I am still pondering the benefit of using a Zend_Registry. Doing this would mean that getDb() would have to take an optional “descriptor” parameter indicating which db connection to get. It would default something like “default” so that if your app only uses a single database, you don’t have to worry about it. This would also mean that the new db instance’s configuration options would have to be stored in the config, preferably with the same descriptor. This way if the proper db instance doesn’t exist, we could create it and store it in the internal array. (or Zend_Registry instance)

Back to the topic of should or shouldn’t I use Zend_Registry in place of Globals, I have reviewed the code and concepts I talk about in the book and I do see where it would be possible to use the registry as a storage device inside of Globals but honestly, IMHO, it just adds a layer of complexity to the class and I don’t really see any benefit to it. (As opposed to the Zend_Config class that we use to store application-wide variables.)

So, for better or for worse, that is my reasoning for not using Zend_Registry.

BTW, I may have gone a bit overboard in that chapter. Globals is certainly not the greatest thing since sliced bread…or even pizza. I have a tendency to write tongue-in-cheek sometimes and feel that I may have given the wrong impression. It was just a fun way to start the chapter. :)

Thanks again for reviewing the book.

=C=

Door Cal Evans op 05.16.08 @ 9:27 pm | Permalink

@ CalEvans: Thanks for taking the time to respond to my little review!

> I have reviewed the code and concepts I talk about in the
> book and I do see where it would be possible to use the
> registry as a storage device inside of Globals but honestly,
> IMHO, it just adds a layer of complexity to the class and I
> don’t really see any benefit to it. (As opposed to the
> Zend_Config class that we use to store application-wide variables.)

Just to make sure, my suggestion would be to use the Zend_Registry class -instead- of the Globals class not -inside- the Globals class.

I think that the benefits of using the Zend_Registry instead of your Globals class would that 1) ZF developers would be already aware of it and it's workings, which beats having to deal with a new class 2) you don't hardcode entries into the class and 3) you don't have to modify your class to add new things.

That leaves us with lazy initialisation. I would argue that there are ways of implementing this while still being able to use the Zend_Registry system but I realise that unless the benefits I just stated have really convinced you of its merits, you'd just be stuck with slightly different code (which would solve your multiple DB issue, btw.). If you are interested in seeing my approach to this, let me know, and I'll send you an example.

Door Mathieu Kooiman op 05.17.08 @ 6:44 am | Permalink

RSS feed for comments on this post.

Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scriptorama.nl