Andrew Vayanis » Zend Framework

Intro to Zend Framework Routing

Andrew Vayanis — Fri, 20 Mar 2009 14:56:28 +0000

Edit: I originally started working on this article several months ago, however, as I was editing it, the Zend Framework team released a revamped reference guide that goes through much of what I discuss. Hopefully though, this still ends up being useful and informative for someone out there.

Edit #2: I don’t mean for this article to be followed verbatim, but rather, used as a guide to understanding Zend Framework’s routing process.

Now that I am using ZF for current projects at work, I have taken the opportunity to promote ZF with my colleagues. One colleague in particular, who has been using Code Igniter(CI), was somewhat perplexed by ZF’s seeming complexity, even after reading through the first few sections of the Reference Guide. In particular, he didn’t understand how ZF handled URIs as it is quite different from CI. So, I have put together the following, hopefully simple overview, explaining a bit about ZF’s routing and using it in conjunction with Zend_Config.

Out of the box, ZF routes URIs by turning the first segment into the controller and the second segment into the action, unless you have specified a module directory, in which case, the first segment becomes the module, the second segment the controller and the third segment the action. Any segments beyond that are converted into key-value pairs that are accessible through the front controller’s request object.

Therefore, something like http://www.vayanis.com/post/view/id/101/title/new-post is translated into a request for the ‘post’ controller, and ‘view’ action with two request parameters: ‘id’ with value ‘101′ and ‘title with value ‘new-post’. Accessing these parameters is simple:

$id = $this->_request->getParam('id');
$title = $this->_request->getParam('title');

Unfortunately, this default behavior is bad for SEO because it adds unnecessary and useless information to the URI, but like many things in ZF, there is a solution and so I turn to the Zend_Controller_Router_Rewrite.
As the documentation states:

Zend_Controller_Router_Rewrite is designed to allow for mod_rewrite-like functionality using pure php structures. It is very loosely based on Ruby on Rails routing and does not require any prior knowledge of webserver URL rewriting.

So, to simplify this URI, I can create the following route:

// Get Front Controller Instance
$front = Zend_Controller_Front::getInstance();
 
// Get Router
$router = $front->getRouter();
 
$route = new Zend_Controller_Router_Route(
    'post/:id/:title',
    array(
        'controller' => 'blog',
        'action'     => 'post'
    )
);
 
$router->addRoute('post', $route);

This will shorten the previous, lengthy URI from http://www.vayanis.com/post/view/id/101/title/new-post to http://www.vayanis.com/view/101/new-post

Finally, like most components, if you are not comfortable maintaining your configuration in pure php, you can instead use a INI config file. The equivalent of the previous example could be defined in an INI config file with the following code:

[production]
routes.post.route = "post/:id/:title"
routes.post.defaults.controller = blog
routes.post.defaults.action = post

To use the INI with a router, use the following:

// Get Front Controller Instance
$front = Zend_Controller_Front::getInstance();
 
// Get Router
$router = $front->getRouter();
 
$router->addConfig(new Zend_Config_Ini('path/to/route/config/file', 'production'), 'routes');

Creating Tables with Zend_Form

Andrew Vayanis — Wed, 26 Mar 2008 05:47:17 +0000

I recently published an article trying to shed some light on the Zend_Form component, in particular, when using it with Zend_Config_Ini. In the article I presented a config I developed while trying to learn Zend_Form myself, but unfortunately realized that using generic elementDecorators comes with a price.

Apparently, using elementDecorators overrides individual element level decorators. This leads to some unexpected and annoying results. For instance, in my previous example, I lose the ability to hide or even add individual attributes to specific elements. This leaves me with a form that has labels for each element including the submit button:

The only way I found to correct this problem is to add decorators to each element individually. This is highly redundant and hardly ideal, but it gives the control necessary to fix this problem. It also bloats the config file significantly; previously, the config was 31 lines long, but now it is 47 lines long:

[login]
; General Form Information
login.action = "login/submit"
login.method = "post"
login.id = "login"
 
; Form Decorators
login.decorators.elements.decorator = "FormElements"
login.decorators.table.decorator = "HtmlTag"
login.decorators.table.options.tag = "table"
login.decorators.form.decorator = "Form"
 
; Username Element
login.elements.username.type = "text"
login.elements.username.options.label = "Username:"
login.elements.username.options.required = true
login.elements.username.options.validators.alnum.validator = "alnum"
login.elements.username.options.validators.regex.validator = "regex"
login.elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
login.elements.username.options.validators.strlen.validator = "StringLength"
login.elements.username.options.validators.strlen.options.min = "5"
 
; Username Decorators
login.elements.username.options.decorators.helper = "ViewHelper"
login.elements.username.options.decorators.tableData.decorator.td = "HtmlTag"
login.elements.username.options.decorators.tableData.options.tag = "td"
login.elements.username.options.decorators.label.decorator = "Label"
login.elements.username.options.decorators.label.options.tag = "td"
login.elements.username.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.username.options.decorators.tableRow.options.tag = "tr"
 
; Password Element
login.elements.password.type = "password"
login.elements.password.options.label = "Password:"
login.elements.password.options.required = true
login.elements.password.options.validators.strlen.validator = "StringLength"
login.elements.password.options.validators.strlen.options.min = "6"
 
; Password Decorators
login.elements.password.options.decorators.helper = "ViewHelper"
login.elements.password.options.decorators.tableData.decorator.td = "HtmlTag"
login.elements.password.options.decorators.tableData.options.tag = "td"
login.elements.password.options.decorators.label.decorator = "Label"
login.elements.password.options.decorators.label.options.tag = "td"
login.elements.password.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.password.options.decorators.tableRow.options.tag = "tr"
 
; Submit Form Element
login.elements.submit.type = "submit"
login.elements.submit.options.label = "Submit"
 
; Submit Decorators
login.elements.submit.options.decorators.helper = "ViewHelper"
login.elements.submit.options.decorators.tableData.decorator = "HtmlTag"
login.elements.submit.options.decorators.tableData.options.tag = "td"
login.elements.submit.options.decorators.label.decorator = "Label"
login.elements.submit.options.decorators.label.options.tag = "td"
login.elements.submit.options.decorators.label.options.class = "submit"
login.elements.submit.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.submit.options.decorators.tableRow.options.tag = "tr"

Personally, I think this is poor design and feel it may even be a bug, but I will attempt to submit it to ZF’s issue tracker and see what they say. Otherwise though, I still feel as though Zend_Form is a great component, and will continue to publish any discoveries I come across.

Using Zend_Form with Zend_Config

Andrew Vayanis — Mon, 17 Mar 2008 05:35:41 +0000

In my previous post Zend Framework, A First Look, I discussed the lacking nature of ZF’s documentation, in particular, with regards to Zend_Form. I have since then learned that this is partly due to the fact that Zend_Form is a relatively new component. However, I still wanted to make use of Zend_Form in my current project and decided to trudge through the learning curve of creating a simple custom login form in conjunction with Zend_Config; the end result being an easy to maintain, custom form and this guide. Hopefully, this guide will make it easier for anyone else looking to take advantage of this very cool feature.

Before I begin talking about how Zend_Form works, I think it is important to explain a bit about Zend_Config and how an INI file is translated into PHP. As the Zend_Config Documentation points out, it makes use of PHP native parse_ini_file, however, this only goes so far as reading in the contents of the file and turning it into a 1 dimensional associative array(2 if a section is provided). Zend_Config extends this behavior by taking the keys of each association and breaking them down further based upon the specified key separator (default is ‘.’). and turning the remainder into arrays. In the end, Zend_Config takes a series of declarations such as the following:

login.elements.username.type = "text"

And turns it into:

Array
(
    [login] => Array
        (
            [elements] => Array
                (
                    [username] => Array
                        (
                            [type] => text
                        )
                )
        )
)

Now, back to Zend_Form. I think my biggest gripe with the documentation provided for Zend_Form is that it does not explain how anything is working behind the scenes. For instance, it does not explain that Zend_Form normalizes config statements by prepending ’set’ when making calls to member methods. This is invaluable as it explains why

    $form->setElementDecorators(array('ViewHelper'));

in PHP becomes

    elementDecorators.helper = "ViewHelper"

in a Zend_Config_Ini. Internally, elementDecorators tells Zend_Form to call setElementDecorators(); This small example also shows why it is important to know how Zend_Config_Ini actually translates an INI to PHP…

Array
(
    [elementDecorators] => Array
        (
            [helper] => ViewHelper
        )
)

As we can see this declares an array of decorators to be passed into setElementDecorators(); The keys, in this case “helper”, do not necessarily matter as it is only needed to index the array, the values are what matter, as that is what is passed and used within Zend_Form. Similarly, it is important to know that almost all aspects of form and form elements, excluding form element type, are implemented internally as options. The following is an example INI file with comments explaining particular sections.

    ; A basic Form config
 
    ; First level attributes are automatically treated as options.
    action = "login/submit"
    method = "post"
    id = "login"
 
    ; Form Decorators
 
    ; Again these decorators are treated as options of the main form.
    decorators.elements.decorator = "FormElements"
    decorators.table.decorator = "HtmlTag"
    decorators.table.options.tag = "table"
    decorators.form.decorator = "Form"
 
    ; Username Element
 
    ; Form Element Type is specified explicityly, not as an option.
    elements.username.type = "text"
 
    ; Username attributes (Label, Required, and validators are all
    ; declared as options).
    elements.username.options.label = "Username:"
    elements.username.options.required = true
    elements.username.options.validators.alnum.validator = "alnum"
    elements.username.options.validators.regex.validator = "regex"
 
    ; Validator parameters such as pattern to regex are also
    ; declared as options. I have not looked into it, but I
    ; assume this is due to the way Zend_Validate handles its
    ; own constructors.
    elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
    elements.username.options.validators.strlen.validator = "StringLength"
    elements.username.options.validators.strlen.options.min = "5"

Bringing it all together, the following is the first version of my login form.

    [login]
    ; General Form Information
    login.action = "login/submit"
    login.method = "post"
    login.id = "login"
 
    ; Form Decorators
    login.decorators.elements.decorator = "FormElements"
    login.decorators.table.decorator = "HtmlTag"
    login.decorators.table.options.tag = "table"
    login.decorators.form.decorator = "Form"
 
    ; Username Element
    login.elements.username.type = "text"
    login.elements.username.options.label = "Username:"
    login.elements.username.options.required = true
    login.elements.username.options.validators.alnum.validator = "alnum"
    login.elements.username.options.validators.regex.validator = "regex"
    login.elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
    login.elements.username.options.validators.strlen.validator = "StringLength"
    login.elements.username.options.validators.strlen.options.min = "5"
 
    ; Password Element
    login.elements.password.type = "password"
    login.elements.password.options.label = "Password:"
    login.elements.password.options.required = true
    login.elements.password.options.validators.strlen.validator = "StringLength"
    login.elements.password.options.validators.strlen.options.min = "6"
 
    ; Submit Form Element
    login.elements.submit.type = "submit"
    login.elements.submit.options.label = "Submit"
 
    login.elementDecorators.viewHelper = "ViewHelper"
    login.elementDecorators.errors = "Errors"
 
    login.elementDecorators.tableData.decorator.td = "HtmlTag"
    login.elementDecorators.tableData.options.tag = "td"
    login.elementDecorators.tableData.options.class = "test2"
 
    login.elementDecorators.label.decorator = "Label"
    login.elementDecorators.label.options.tag = "td"
 
    login.elementDecorators.tableRow.decorator.tr = "HtmlTag"
    login.elementDecorators.tableRow.options.tag = "tr"

This creates a login form with a username and password field along with a submit button. However, instead of being wrapped in a definition list using definition titles for labels and definition data for input fields, I have wrapped the labels and input fields within a table similar to the google login form. Notice though, that I have sectioned this form using [login]. Tthis is so that I can define all my necessary forms in one forms.ini file and load each form by section. I have also prepended each declaration with login. as a way to keep my form definitions organized and easy to read (to me at least).

Concluding this guide, I would like to reiterate, how useful I think Zend_Form is as it solves one of the most tedious process for any PHP project; form creation and validation. I hope it continues to evolve and mature, and I hope others find it as handy as I have. Although, if anyone has an easier solution, please let me know.

Zend Framework, A First Look

Andrew Vayanis — Fri, 14 Mar 2008 14:32:16 +0000

Having used Code Igniter for some small projects at work, I recently decided to take the time to acquaint myself with the Zend Framework(ZF) so that I could build my own comparison between two of the most, in my opinion, developed and used PHP frameworks. While I love the flexibility and functionality offered by ZF, I have become very frustrated and annoyed with some of their documentation. Even though it is detailed and expansive, it is no where near complete and somewhat frustrating to use.

Zend_Form is a great example of this incomplete documentation. Conceptually, I think the Zend_Form is great. It offers very useful, and much needed functionality for creating and validating forms within pages and although it offers 4 pages of documentation and highlights many features, it barely touches upon one of its most useful features: the ability to create a form by passing the constructor a Zend_Config_Ini object. In its simplest form this amounts to the following:

$loginForm = new Zend_Form(new Zend_Config_Ini('/path/to/form/config', 'login'));

This will create a Zend_Form object by passing it a Zend_Config_Ini object.

Unfortunately, when you decide to build a custom form using Zend_Config, the documentation on how this actually works, is extremely sparse. There are three examples of using the Zend_Config, however, they are not commented and there is no explanation as to how it works, there is only a weak reference to PHP object oriented code from which to draw conclusions from. Maybe, I am too used to the Java API documentation.

Anyways, after a few days with ZF, it has become apparent to me, that ZF is a very well written, powerful, extensible, and versatile PHP framework. However, due to its incomplete documentation, I would argue that its’ learning curve is fairly high, much higher than Code Igniter’s. In time though, I am sure the ZF developers will realize this, and make the effort to provide better documentation. In the meantime though, I am going to continue to use ZF and hopefully, take it upon myself to provide some insight; a Zend_Form tutorial using Zend_Config is already in the works.