Zend Form Mastery with Zend Config - Part 1 Custom Filter Paths

When you’re working with Zend Form you keep your configuration as much out of code as you can - right? Well, if you’ve been working withZend Form for more than a little while, you know that Zend Config really makes that pretty simple - well, some of the time. In this series we look, comprehensively at how to do it all with Zend_Config.

Update: Thank you to savvysketch for pointing out my lack of detail about setting form wide element prefix paths. This is now available.

When you’re working with Zend Framework, and code in general, you keep your configuration as much out of code as you can - right? Well, if you want to write maintainable and flexible code you do. Well, if you’ve been working with Zend Framework and Zend Form for more than a little while, you know that it really makes that pretty simple via Zend_Config - well, some of the time.

Unfortunately not always

That’s right, it’s not that simple, not by a long shot. Why’s that? There’s two key problems with using Zend Config to configure our Zend Forms:

  1. The Manual - That’s right, the manual doesn’t place a lot of emphasis on using Zend_Config objects to configure forms. It does give some options, but doesn’t go in to much depth.
  2. Code Investigation - You have to know the Zend Form code or do regular digging when you need to know an option

What a Whinger!!!

That’s right, depending on your background, I’m sure that you’ve just labelled me that - or maybe worse. I admit that points 1 and two could be seen as just being lazy. What developer worth their salt isn’t prepared to dig through code to find out how libraries, frameworks and applications really work?

How often do we really rely on a manual to give us all we need. After all, there isn’t endless time to write countless examples, and that’s what self-documenting code is for - right?! Yes! But that aside, sometimes it helps to have a bit of a boost along and not have to do all of the investigation yourself, especially when you’re in a bit of a hurry, or under the pump to get work done.

What’s in the Series

So, given that perspective, with this series of posts, I’m going to start covering some of the key configuration options for Zend Form. In this series we’re going to be looking at the following:

  • How configuration works
  • paths:
    • filters
    • prefix
    • elementPrefix
    • displayGroupPrefix
    • elementDecorators
  • element:
    • filters
    • validators
    • options
  • form:
    • options

In this one, I’m going to cover custom form filters.

Custom Form Filters

Per-Element Filters

Let’s say that we’ve written a custom filter to truncate text submitted in a form. How do we get that to simply work when the default is for Zend Framework to look for classes with a prefix of Zend_Filter_ and a path of Zend/Filter/?

Well, it’s easier than you think. Take a look at the form xml snippet below:

[xml] <phone_number> text 12 NotEmpty A phone number is required StringTrim Truncate 20 regTextInput false MaltBlue_ MaltBlue filter </phone_number> [/xml]

In this section we have two filters, trim and truncate. The trim filter is the built-in filter: Zend_Filter_StringTrim. The second one is our custom one, MaltBlue_Filter_Truncate. Without getting in to too much detail about the filter itself, it has one key option: stringLength. This sets the maximum length of the string that can be displayed for that element. Any text after that length will be truncated - it works as it says on the tin?

However, if we only added that the filter option in, then we’d see an exception thrown. Why, because only the default path and prefix are loaded. So we need to tell Zend Form where to find our new, custom, filter by providing it with a prefixPath.

To do this, look at thesection under the phoneNumber element and you’ll see that this provides it with three options:

  • prefix - the class name prefix

  • path - the class path to start searching in

  • type - the prefix path type

What this translates to is analogous to us having called the following snippet on the element, had we done all this in code:

$element->addPrefixPath('MaltBlue_Filter', 'MaltBlue/Filter/', 'filter');

Form-wide Filters

Now this is all well and good, but if we kept doing it this way, we’d have to include a prefixPath section for every element. Now this isn’t bad for one or two elements, but not for more than that; it’s just not very practical. Wouldn’t you agree? So how do we add them on a form-wide basis? Well, that’s a good question. Have a look at the code below which illustrates how to do this:


post MaltBlue_ MaltBlue filter [/xml]

Via the Zend_Form::setOptions() method, the above snippet has now added the prefix path to all elements added to the form. Now you can remove the prefixPath configuration from individual elements. If you’re curious, have a look at, approximately, line 317 in <your_library_path>/Zend/Form.php.

Now that we have both of these options in place, we’re now able, per/element or per/form or a combination of the two, to add custom filters to our form elements, without writing a specific line of code. What do you think? How do you see it helping you in your projects?

You might also be interested in these tutorials too...

Tue, May 22, 2012

Zend Form Mastery with Zend Config – Part 3 Standard Form &amp; Element Options

– Part 3 Standard Form & Element Options This is a Multi Part Series. Check out the other parts: Part 1 - Custom Filter Paths Part 2 - Core Form Configuration Part 4 - Configuring Zend Validators Options We’ve looked at custom form filters and we’ve looked at the core form configuration. But what about the other form properties? What about: setting an element as readonly an element as required ignoring an element and love them or hate them, what about decorators Element Options Outside of the options that we’ve looked at previously, there are a number of other options that we can consider implementing when configuring a Zend Form.

Mon, Jan 9, 2012

Beginning cloud development with cloudControl – Part 4 – Memcache

Here we are at part four of the Beginning Cloud Development with cloudControl series and in this part, we’re adding Memcached support. In part one of the series, we laid the foundation for the application and got up to speed with what cloudControl is, why it works and how to get started using it.

Then in part two, we started to flesh out the application that we started building in part one and added MySQL support to it. We showed how to work with cloudControl to manage the key requirements, such as enabling MySQL support, connecting to the MySQL database and keeping the database up to date from a maintenance perspective (creating the database schema and loading data in to the database).

Then in the third part of the series, we replaced MySQL with mongoDB support. Now, in this, the third part of the series, we’re going to finish up with adding Memcached support. As the core of the work’s already been done in the application, this tutorial will be shorter and simpler than the previous three. So, get out the code that you worked through from part 2, or download a copy of it from the github repository and let’s get started.

Tue, Jun 5, 2012

Zend Form Mastery with Zend Config – Part 4 Configuring Zend Validators

Welcome to the fourth and final part in the Zend Form Mastery with Zend Config series. Previously we looked at the basic form options, element and form wide prefixes, filters and element options. In this installment, we’re going to look at configuring Zend Validators via our XML config.

Want more tutorials like this?

If so, enter your email address in the field below and click subscribe.

You can unsubscribe at any time by clicking the link in the footer of the emails you'll receive. Here's my privacy policy, if you'd like to know more. I use Mailchimp to send emails. You can learn more about their privacy practices here.

Join the discussion

comments powered by Disqus