Skip to content

Things I learned about Zend Tool

Dear Reader,

I’m prepping some training on Zend Framework and have been working with Zend Tool a lot. When MWOP first told me about Zend_Tool, I thought cool. and when it hit the incubator, I grabbed it. I followed the two hour install instructions…then did it again, because I missed a step. Finally I had it and zf show version didn’t throw an error. However, everything else did. It pretty much sucked.

Each time a new version came out, I would grab zf and try it and be disappointed because…well, it sucked. So I stopped bothering.

Then something happened. I’m not sure when but I grabbed a copy this morning and tried it and…it didn’t suck. (ok, it had a major, show stopping flaw in it but the beauty of the PHP community is there’s usually someone around smarter than you that can help you figure it out. Thanks to Rob Allen for helping me find the error and then submitting a patch for it.)

The main point is, somewhere between the last time I tried it and this version, they refactored the suck out of it, which is great. It’s now a useful tool. How useful remains to be seen but for the moment, I am cautiously optimistic.

There are still some quirks about how I work and how it works and I’m not pointing any fingers at who is wrong but I’m older and have been doing this longer than it has. :) So I’m posting there here, mainly for me because I’ll forget them tomorrow if I don’t, and for you if it can save you a few minutes of frustration.

include_path nuttiness

Normally, when setting up a virtual server in Apache for a Zend Framework application I add a line similar to:

php_value include_path "./;D:/tmp/zftest/library;d:/xampp/xampp/php/PEAR"

This way PHP can find the Zend Framework and since it’s not going to move we might as well nail down it’s position.

However, now, Zend Framework seems to want to do that itself. Adding in the library directory in the conf file causes things to break. Apparently, Zend Framework is now smart enough to figure out it’s own include_path but not smart enough to recognize that it’s already set. (like, you know, trying to load a sample class and only setting it if the load fails?)

[Update: I’ve not tested this but since the application.ini contains

includePaths.library = APPLICATION_PATH "/../library"

I’m guessing I could comment that line out and let Apache deal with it once instead of Zend Framework dealing with it every page request.]

Default to production

I guess I can understand this one but it seems a bit backwards to me in most respects. If you use zf to create your project, the index file it creates will contain this line:

    || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production'));

The install defaults to production. Which is good in one way, because this way you don’t accidentally display errors to your users in a production system. However, if you made the first mistake, instead of seeing the nice welcome screen that the zf tool creates for you, you just get a white screen. If you’ve not actually written any code at this point, a white screen may seem logical. (Especially since the Quickstart Guide doesn’t give you a screen shot telling you what you should expect.

So if you are setting up a development system, make sure you either set the environment variable APPLICATION_ENV to development or change the index file to default to development. (I chose the latter since it was easier on Windows)


[UPDATE: Reader Bryan Zarzuela commented below that when creating a project, zf will deposit a .htaccess file in the public directory. In that file is the line:

SetEnv APPLICATION_ENV development

This should automatically set the APPLICATION_ENV to “development” the way I thought it should be. The problem I ran into is that by default, the current version of Apache defaults to:

AllowOverride None

Which prevents the Environment variable from being set. For this to work, you have to change it to

AllowOverride All

and then bounce Apache. If you do this before using zf then it should work as expected. Thanks to Bryan and Ralph for helping me trace this down. ]

I want to do it MY way

This isn’t so much a flaw in zf as a wish list item. Since I have to setup a storage directory for it to use (that was a whole ‘nother ball of nuttiness) why can’t the storage directory hold a .skeleton dir. The .skeleton dir is where I could drop additional directories and files I want added to each zf project I create. For instance, I like my apache logs in a logs dir at the same level as public_html. If zf had a .skeleton directory, I could drop a logs directory into it and every project I create form then on would have the logs directory.

Development has far outpaced documentation

The Zend Framework manual is a bear to navigate to begin with, especially when you aren’t sure exactly what you are looking for. However, the Zend_Tool section of the manual is sparse. I’m sure they will clear it up soon. However, right now, if you hit an error, you are really on your own and it’s good to know where to go find help. (hint, irc)

So as I said, these are just my notes. for now, with Rob’s patch, it works great for creating projects, controllers and views.

Now, can we teach it to create a login module? :)

Until next time,
I <3 |< =C= p.s. MWOP, we really should have made the "I am a Zend_Tool shirts." :)

9 thoughts on “Things I learned about Zend Tool

  1. Cal, I’m on it. :)

    Currently, I am adding diagnostic and setup capabilities to the zf.php script. This is crucial for several reasons, but the most prominent one is the include_path “nuttiness” you describe above. Fact of the matter is that there is typically no telling what is on the typical users include_path, and while I think its ok to scan it by default, I think there should be an easy way to configure it such that we can hard code either a) a zend_tool specific include_path, or b) tell it exactly where to find providers, explicitly via a configuration file.

    1.9 brings 2 new and much needed base features: runtime configuration and storage. Most of the features that have been requested thus far have been impossible to complete without the 2 mentioned above. For example, you mention wanting to have a custom skeleton, well, that cannot be done without a place to put it. As for include_path issues, the environment variables can only take you so far. What is really needed is a way to specify what we want for php ini values, that is what runtime configuration is about.

    Some of the things you mention above (for example the includePaths.library) are more specific to Zend_Application than to Zend_Tool (even though Zend_Tool generated it). When we talk about having an include_path inside of an application or project, that effectively allows us to do, what some people like to call, “freeze” a specific version of a library to a project. This is generally good so that you can upgrade the library generally available on your system, but allow projects to be frozen to a specific version of a library until the developer chooses to upgrade.

    Later this week, I’ll write a blog post outlining how you can have your logs directory :)

  2. Cal,

    If you look at the .htaccess file Zend_Tool generates with a project, you’ll see that it sets the environment to development (SetEnv APPLICATION_ENV development).

  3. @Brian,

    Thanks for the heads up. Even on Windows, I have a bad habit of using the ls -l command to list dirs instead of Window’s native dir and honestly, I had not noticed it. :) That would be a better way of doing it.

    [UPDATE: Ok, you are right it does exist but for some reason Apache (XAMPP on Windows) is not honoring it. I’ll have to look into why.]


  4. Pingback: PHPWomen T-Shirts – techPortal
  5. Pingback: Quickie Zend Framework Bootstrap Note – techPortal

Comments are closed.