Zend Framework is a free/open source web application framework. It can be used either as a component library or as a full-stack Model–View–Controller (MVC) framework. As compared to its 1.x counterparts, Zend Framework 2.0 is easier to learn, trivially simple to extend, and more performant. It is also easier to use just specific parts of the framework as needed. We will explore the many features of Zend Framework 2.0 including its tooling, functional testing, form, database, pagination, date, markup, navigation, and MVC components. Zend Framework 2.0 takes advantages of several new features in PHP 5.3 including closures/lambdas, namespaces, and late static binding. We will explore some of these new features to understand why PHP 5.3 is a requirement for Zend Framework 2.0 and how you can leverage these new features within your application itself. An example web application will be provided that you can use as a reference when building your own Zend Framework web application.

For those wondering, Zend Framework 2.0 is not out yet but SXSW is not until next March and Zend Framework 2.0 will most likely be released by then. The description above is based on the Zend Framework 2.0 Requirements and discussions on the Zend Framework contributors mailing list.

Over the last year, Magento has increased in popularity as a viable open source eCommerce platform for the mid to large scale online retailer. This rapid growth has lead to many questions on what has been fixed, what continues to be a problem, and how complex a system an eCommerce engine needs to be.

Have you used Magento? Are you considering using it for an upcoming project? Do you have a specific problem that Magento solves for you and would like to share your story? Join the roundtable and compare notes with others who have experience with Magento.

Meetings are open to the public via RSVP. You will have the chance to network and connect with fellow PHP developers.

To Participate:

1. Register on Eventbrite.
2. Sign up for the Burlington, VT PHP User Group list on Google Groups.
3. Forward this link to anyone else you feel would be interested in this meeting’s topics.

Next up for me was Derick Rethans’ Xdebug talk. Xdebug is an extremely useful tool for PHP developers. I’ve used its stack trace feature as well as its code coverage analysis via PHPUnit. I’ve also dabbled with its profiling capabilities. The session introduced me to several other Xdebug features with which I’d like to experiment.

After that I had the pleasure of seeing Matthew Turland’s talk on New SPL Features in PHP 5.3. New SPL data structures in PHP 5.3 include stacks, queues, heaps, priority queues, and sets. Matthew provided test code that compared the performance and memory usage of each these new data structures to that of using PHP’s array functionality.

I skipped the first afternoon session to take part in the Hack Track which happened to coincide with Zend Framework’s May Bug Hunt Days. I was granted commit access and directly committed my first bug fix, a small change to make HTTP headers case-insensitive.

Others stuck around to fix more bugs while I went to check out Bill Karwin’s Models for Hierarchical Data with SQL and PHP. Examples of hierarchical data include categories/subcategories, bill of materials, and threaded discussions. Bill talked about four main approaches to storing hierarchical data in SQL databases: adjacency list, path enumeration, nested sets, and usage of a closure table.

The adjacency list is a naive approach that almost everyone tries first. Basically, each entry knows its immediate parent. The problem with this approach is that querying deep trees can be very inefficient involving many joins. Path enumeration involves storing an enumerated chain of ancestors in each entry. This can be very efficient and take advantage of indexing. However, there is no referential integrity with this approach. The nested set approach seemed a bit complicated. I don’t feel I can explain it properly here, so you’ll have to check out Bill’s slides if you’re interested in how this works. The closure table approach made the most sense to me and didn’t seem overly complicated. Not only do you store each entry, but you also store every path including those from the parent node to each descendant, those from each ancestor to its child node, as well as a reflexive reference from the node to itself.

My final session of the day was Travis Swicegood’s Building Real-Time Applications with XMPP, the Extensible Messaging and Presence Protocol. If you’ve use Google Talk then you’ve used XMPP. As a web developer, the request and response pattern in HTTP is ingrained into my thinking. However, XMPP is a very different creature in that it keeps a socket open during what can be a lengthy exchange of messages. While I don’t think HTTP is going away anytime soon, real-time applications involving potentially large numbers of publishers and subscribers (e.g. Twitter) are becoming more prevalent and XMPP is well suited for this environment.

The field I was indexing, and subsequently using to find and delete documents, was a 40 character SHA-1 hash. While trying to track down the bug in my application, I discovered that only documents having a SHA-1 hash beginning with a digit were getting duplicated (in other words, were not being found when I tried to delete them) and that documents having a SHA-1 beginning with a letter were not getting duplicated (in other words, were being found and deleted).

A Stack Overflow post on searching numbers with Zend_Search_Lucene had the information I needed to fix the bug. First, I changed the hash field from a text field to a keyword field which prevented it from being tokenized (this, of course, required me to delete the existing index and re-index every document). Second, when searching on the hash field I replaced the default Text analyzer with the TextNum analyzer. These two changes seemed to do the trick, as I haven’t seen any duplicate search results after having run several index updates.

In the past you may have implemented consisted layouts in PHP using “includes” but, as you’ll see, layouts are much easier to manage than “includes”. The primary improvement over “includes” is that you can change the entire layout of your website without editing every single PHP script. This is because the layout decides where the content gets placed instead of each PHP script including the needed partials (e.g. header and footer). This is accomplished through an implementation of the Two Step View pattern.

If you’re using Zend_Tool then you can enable layouts using the command zf enable layout. This will create a layout view script, application/layouts/scripts/layout.phtml, and add the following line to the production section of your application/configs/application.ini file:

resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts/"

Zend_Layout has a front controller plugin that has two main jobs. First, it takes care of rendering the layout for us. Second, it retrieves what are called “named segments” from Zend Framework’s response object and assigns them as variables in your layout. A segment named “default” is assigned to the variable named content. Typically (unless you do something to override this) the “default” segment will contain the output of your individual controller actions. This means that you can render the content of your controller actions wherever you’d like in your layout view script by outputting the value of $this->layout()->content.

In the demo blogging application, Postr, I’ve also created a header layout view script, application/layouts/scripts/header.phtml, and a footer layout view script, application/layouts/scripts/footer.phtml. The header and footer layout view scripts are rendered by outputting the results of $this->render('header.phtml') and $this->render('footer.phtml'), respectively.

In my next post in this series I plan on taking a look at the Entry controller (application/controllers/EntryController.php) in the demo blogging application, Postr. We’ll explore its actions and corresponding view scripts. Zend_Form, Zend_Paginator, and modeling domain objects will be touched on briefly, but explored in more depth in later posts.

Model

Your domain objects. There is no Zend_Model since your domain logic is specific to your application. However, there are some best practices that have emerged in the Zend Framework community including Data Mappers (which I’ll talk about later).

See example Models in application/models/

View

The presentation layer. The default implementation uses PHP templates called view scripts. View script files have a default suffix of .phtml. There should be no domain logic in your view scripts. By default, there is one view script per controller action (we’ll see what that means shortly).

See example Views in application/views/

Controller

Connects the Model and the View. Each Controller contains one or more actions. The Controller’s job is to interpret input and pass it to the Model and also to provide Model data to the View.

See example Controllers in application/controllers/

By default, Zend Framework will route requests based on URI segments as follows:

:controller/:action[/:key/:value]

A few example URIs:

• foo/bar (foo controller, bar action)
• foo/bar/baz/shaz (foo controller, bar action, baz=shaz)

It is possible to customize this routing in pretty much any way conceivable but I’d suggest sticking with the default routing until you have a good handle on how it works.

In my next post in this series I plan on taking a slight detour so that we can explore a very useful component, Zend_Layout.

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.

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.

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.

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