Blog Moved

I've moved my blog over to http://bradley-holt.com/. If you subscribe to my feed then please update the feed URL to http://feeds.feedburner.com/bradley-holt (it should redirect automatically but it's not a bad idea to resubscribe using the new URL). Unfortunately I'm not able to redirect the posts themselves.

Bootstrapping Zend Framework Applications

See Bootstrapping Zend Framework Applications at its new home on bradley-holt.com.

In my previous post I talked about how the Front Controller pattern is implemented in Zend Framework. We saw how every application request can go through the public/index.php script. Everything that your application does is then eventually called from either the bootstrap() or run() method in Zend_Application.

One of the constructor arguments passed to Zend_Application specified the configuration file to use. In the case of the demo blogging application, Postr, you'll see that the configuration file used is application/configs/application.ini. If you look at this configuration file you'll see that there are four sections: production, staging, testing, and development. The staging, testing, and development sections all inherit from production meaning that they will inherit all of its settings, unless overridden (as is the case, for example, with the phpSettings.display_errors setting in testing and development).

The other constructor argument passed to Zend_Application specified the application's environment. For those paying close attention, the environment was actually the first argument and the configuration file was the second argument passed to the constructor of Zend_Application. By default, the demo application is set to run in development mode. This means that the development section from application/configs/application.ini will be used. Remember, development inherits from production so any settings not explicitly overridden from production would be inherited and used.

There's quite a bit that can be setup in the configuration file. However, some things may be easier to (or only possible to) setup programmatically. This is where application/Bootstrap.php comes in. In your Bootstrap class you can write initializers for various parts of your application. These methods should be protected and their names should begin with _init. Let's look at the initializers I've written in the demo application:

• _initViewHeadTitle() first makes sure that the "view" resource has been bootstrapped and then gets this resource, which we happen to know is an object of type Zend_View_Abstract. We then set the separator used by the HeadTitle view helper to " :: ". This means that each head title appended or prependend will be separated by this string. Next, a title of "Postr" is prepended so that this title will be used on every page.
• _initPagination() simply sets the partial view script to be used by Zend_Paginator (I plan on further explaining Zend_Paginator in another blog post).
  
• _initNavigation() sets up our navigation structure using Zend_Navigation (I plan on further explaining Zend_Navigation in another blog post as well).

In my next post in this series I plan on taking a look at the Model-View-Controller pattern in Zend Framework.

Front Controller Pattern in Zend Framework

See Front Controller Pattern in Zend Framework at its new home on bradley-holt.com.

I recently gave a Zend Framework Introduction presentation at our local PHP Users Group. I built a demo blogging application called Postr that I used as an example throughout the presentation. There was way too much material to cover in the time available so I plan on writing a series of blog posts, each covering a specific area of Zend Framework. Here is the first (and hopefully not the last!) post in this series based on the presentation and demo application.

Like many other frameworks, Zend Framework provides an implementation of the Front Controller pattern. This means that all HTTP requests can be sent through a centralized point. This allows you to take advantage of Zend Framework's routing and Model-View-Controller (MVC) components, if you so choose. By default this is the public/index.php file (click to see the source code). Note that in Zend Framework only the public directory is accessible to website visitors, all of your other directories should be outside of your document root. You'll see several things happening in the public/index.php script:

1. The APPLICATION_PATH constant is defined. This is the full path to the application directory. You'll see this constant used later.
2. The APPLICATION_ENV constant is defined. This will typically be either production, staging, testing, or development. This will be used to determine which configuration section to use.
3. The library directory is added to the include path. This is so that the Zend library code (if you decide to place it in your library directory) or any other libraries used can be found.
4. A new instance of Zend_Application is created. Two arguments are passed to its constructor: the application environment (defined in 2) and the location of the configuration file. Typically this is application/configs/application.ini. The application path (defined in 1) is used to provide the absolute path to the configuration file.
5. The application is then bootstrapped and run. It may seem odd to those used to writing PHP scripts, but everything that happens in your application is subsequently called from either the bootstrap() or run() method in Zend_Application. In fact, this is the essence of the Front Controller pattern.
   

By itself, public/index.php can't make sure that all HTTP requests go through it. If you're using Apache as your web server then you can use its rewrite module to do this (other web servers have equivalent functionality). This is typically done in public/.htaccess. There are several things happening in this file:

1. First the application environment is set so the application knows if it's running in production, staging, testing, or development mode.
2. In the demo application, I set the default character set to utf-8.
3. Some environments require you to set a rewrite base. If needed, this is usually the first part of the URI (e.g. just / if your application is the only thing on the web server or /postr/ if your application is in a subdirectory named "postr").
4. Turn on the rewrite engine.
5. Don't rewrite if the requested file is a regular file with size greater than zero, is a symbolic link, or is a directory. This way static files such as images, CSS files, and JavaScript files aren't rewritten.
6. Otherwise, rewrite the request to index.php.

In my next post in this series I plan on taking a look at what happens during the bootstrapping phase of your Zend Framework application.

Zend Framework Introduction

See Zend Framework Introduction at its new home on bradley-holt.com.

Slides from last night's Zend Framework Introduction at the Burlington, Vermont PHP Users Group are now available online:

Zend Framework Introduction

View more presentations from Bradley Holt.

The presentation is available under a Creative Commons license.

As I mentioned earlier, there's also a demo blogging application called Postr available on GitHub. The application is available under a free/open source New BSD License so feel free to use, redistribute, and/or modify it however you'd like.

Learn Zend Framework

See Learn Zend Framework at its new home on bradley-holt.com.

At tonight's (Thursday, January 28, 2010) Burlington, Vermont PHP Users Group meeting I'll be giving a Zend Framework Introduction presentation. I'll be covering how to use several features of Zend Framework and common patterns including:

• Zend_Tool
• Zend_Application
• Model-View-Controller (MVC)
• Zend_Layout
• Action Controllers
• View Scripts
• Zend_Test
• Modeling domain objects
  
• Zend_Form
• Zend_Db_Table
• Data Mapper
• Zend_Paginator
• Zend_Date
• Zend_Markup
• Zend_Navigation
• Controller Plugins

I've created a demo blogging application called Postr that I'll be using as an example throughout the presentation. Thanks to Jason there is some CSS that makes the application much more usable. I will post the presentation to my SlideShare account after tonight's meeting.

The meeting is from 6:00 PM - 8:00 PM at Office Squared in Burlington, Vermont. If you're in the area and interested in attending then you can register for free on Eventbrite.

Open Source and Open Standards Bill

See Open Source and Open Standards Bill at its new home on bradley-holt.com.

The other day there was a discussion on the VAGUE mailing list about an open source and open standards bill (H.516) [PDF] recently introduced in the Vermont General Assembly (a.k.a. legislature). It's technically an amendment to an existing act and has the following stated purpose:

This bill proposes to require the department of information and innovation to advise against the acquisition by a state agency of proprietary software or software that operates by means of proprietary protocols when acceptable functionality can be achieved with open source software and open standard protocols and to ensure that the expected total life-cycle costs of software are fully evaluated prior to acquisition.

Overall I see this as a positive move for the State of Vermont. It does not seem to put the requirement for open source and open standards ahead of the particular business needs at hand since it only "advise[s] against the acquisition by a state agency of proprietary software or software that operates by means of proprietary protocols when acceptable functionality can be achieved with open source software and open standard protocols." However, Mitch Lieberman points out:

@BradleyHolt functionality does not directly = biz value IMHO, biz value needs to include ROI of functions, thus includes TCO

I agree with Mitch that the bill could do a better job of addressing not just functionality, but also return on investment (ROI) and total cost of ownership (TCO). These should be the primary considerations of any responsible organization in deciding what software to use. However, since it is the public's money being used to purchase this software it is worth considering whether our resources are being used to further entrench proprietary software and standards, or whether we are instead enriching the public commons by supporting open source software and open standards.

In addition to the above, there are some details of the bill that demonstrate some possible misunderstandings of how open source software works. While it's not anywhere in its text, the bill is described as being "An act relating to comparing the costs and benefits of downloading free open source software with purchasing proprietary computer software." There are a couple of misconceptions in this one statement. First, cost should not always be the primary motivation behind using open source software: the freedoms it gives you are just as important. In fact, not all proprietary software costs money and not all open source software is available free of charge. Second, "downloading" is simply a means of distributing software. Proprietary software can often be downloaded. Open source software is sometimes distributed on a physical medium.

It's not stated explicitly in the bill, but people sometimes think that if they release their own software under an open source license they are somehow giving up control of the licensed software project. While there are many benefits of giving up control (which are outside the scope of this blog post), it's worth noting that you don't have to. When you license your software you still own the copyright on that software. You can still do whatever you want with that software, including release it under a different license later. Once you accept outside contributions then you need to honor whatever license has been given to you be your contributors (unless they agree to transfer copyright to you, but this can be tricky). It's your choice whether or not to accept those contributions in the first place. You are still completely in control (as long as you want to be) and have simply given others the possibility of benefiting from your work.

Zend Framework Route Context Plugin

See Zend Framework Route Context Plugin at its new home on bradley-holt.com.

I want to share a simple, yet very useful, custom Zend Framework plugin that we use on almost all of our projects. The plugin (and associated code in the layout file) provides the Zend Framework route context as CSS classes on the body element. This allows us to change the design (using CSS) and/or behavior (using unobtrusive JavaScript) on the page based on the Zend Framework route. For example if the module name was default, the controller name was news, and the action was get then the opening of the body element would like this:

<body class="default news get">

There are some limitations. For example, you need to be careful not to overlap module, controller, or action names. If this is a problem for you then you could preface the class names (e.g. module-default, controller-news, action-get).

The RouteContext plugin hooks into the preDispatch event and creates an array of route context strings. This example simply uses the module, controller, and action names as the route context. Often I'll add other contextual strings to this array as needed. This array is then assigned to the view. The layout view script then simply implodes this array into the value of the class attribute using a space character as the glue.