> 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.

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=