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.
Sunday, January 31, 2010
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
run() method in
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:
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
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
HeadTitleview 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_Paginatorin another blog post).
_initNavigation()sets up our navigation structure using
Zend_Navigation(I plan on further explaining
Zend_Navigationin 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.
Friday, January 29, 2010
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
APPLICATION_PATHconstant is defined. This is the full path to the
applicationdirectory. You'll see this constant used later.
APPLICATION_ENVconstant is defined. This will typically be either
development. This will be used to determine which configuration section to use.
librarydirectory is added to the include path. This is so that the
Zendlibrary code (if you decide to place it in your
librarydirectory) or any other libraries used can be found.
- A new instance of
Zend_Applicationis 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.
- 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
Zend_Application. In fact, this is the essence of the Front Controller pattern.
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:
- First the application environment is set so the application knows if it's running in
- In the demo application, I set the default character set to
- 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").
- Turn on the rewrite engine.
- Otherwise, rewrite the request to
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.
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.
Thursday, January 28, 2010
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:
- Model-View-Controller (MVC)
- Action Controllers
- View Scripts
- Modeling domain objects
- Data Mapper
- 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.
Wednesday, January 20, 2010
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.
Monday, January 11, 2010
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
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.
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.