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.
This is a Multi Part Series. Check out the other parts:
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:
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.
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>
text12NotEmptyA phone number is requiredStringTrimTruncate20regTextInputfalseMaltBlue_MaltBluefilter
</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:
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:
[xml]
postMaltBlue_MaltBluefilter
…
[/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?
– 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.
Today we move on in learning how to configure the basics of Zend Forms, such as action, method, enctype, accept, accept-charset et al with Zend Config XML. It couldn’t be simpler.
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.
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.
Join the discussion
comments powered by Disqus