Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (2)

View Page History
* Textarea: Zend_Form_Element_Textarea

h2. Methods

Zend_Form_Element has many, many methods. What follows is a quick summary of
their signatures, grouped by type:

* *Configuration:*
** setOptions(array $options)
** setConfig(Zend_Config $config)
* *I18N:*
** setTranslator(Zend_Translate_Adapter $translator = null)
** getTranslator()
* *Properties:*
** setName($name)
** getName()
** setValue($value)
** getValue()
** getUnfilteredValue()
** setLabel($label)
** getLabel()
** setOrder($order)
** getOrder()
** setRequired($flag)
** getRequired()
** setDescription($description)
** getDescription()
** getType()
** setAttrib($name, $value)
** setAttribs(array $attribs)
** getAttrib($name)
** getAttribs()
* *Plugin loaders and paths:*
** setPluginLoader(Zend_Loader_PluginLoader_Interface $loader, $type)
** getPluginLoader($type)
** addPrefixPath($prefix, $path, $type = null)
** addPrefixPaths(array $spec)
* *Validation:*
** addValidator($validator, $breakChainOnFailure = false, $options = array())
** addValidators(array $validators)
** setValidators(array $validators)
** getValidator($name)
** getValidators()
** removeValidator($name)
** clearValidators()
** isValid($value, $context = null)
** getErrors()
** getMessages()
* *Filters:*
** addFilter($filter, $options = array())
** addFilters(array $filters)
** setFilters(array $filters)
** getFilter($name)
** getFilters()
** removeFilter($name)
** clearFilters()
* *Rendering:*
** setView(Zend_View_Interface $view = null)
** getView()
** addDecorator($decorator, $options = null)
** addDecorators(array $decorators)
** setDecorators(array $decorators)
** getDecorator($name)
** getDecorators()
** removeDecorator($name)
** clearDecorators()
** render(Zend_View_Interface $view = null)


h2. Custom elements


There are many ways to customize elements; be sure to read the API documentation of Zend_Form_Element to know all the methods available.

h1. Creating Forms Using Zend_Form

The Zend_Form class is used to aggregate form elements, display groups, and subforms. It can then perform the following actions on those items:

* Validation, including retrieving error codes and messages
* Value aggregation, including populating items and retrieving both filtered and unfiltered values from all items
* Iteration over all items, in the order in which they are entered or based on the order hints retrieved from each item
* Rendering of the entire form, either via a single decorator that peforms custom rendering or by iterating over each item in the form
*
While forms created with Zend_Form may be complex, probably the best use case is for simple forms; it's best use is for Rapid Application Development and prototyping.

At its most basic, you simply instantiate a form object:

{code:php}
// Generic form object:
$form = new Zend_Form();

// Custom form object:
$form = new My_Form()
{code}

You can optionally pass in configuration, which will be used to set object state, as well as to potentially create new elements:

{code:php}
// Passing in configuration options:
$form = new Zend_Form($config);
{code}

Zend_Form is iterable, and will iterate over elements, display groups, and subforms, using the order they were registered and any order index each may have. This is useful in cases where you wish to render the elements manually in the appropriate order.

Zend_Form's magic lies in its ability to serve as a factory for elements and display groups, as well as the ability to render itself through decorators.

h2. Plugin Loaders

Zend_Form makes use of Zend_Loader_PluginLoader to allow developers to specify locations of alternate elements and decorators. Each has its own plugin loader associated with it, and general accessors are used to retrieve and modify each.

The following loader types are used with the various plugin loader methods: 'element' and 'decorator'. The type names are case insensitive.

The methods used to interact with plugin loaders are as follows:

* setPluginLoader($loader, $type): $loader is the plugin loader object itself, while type is one of the types specified above. This sets the plugin loader for the given type to the newly specified loader object.
* getPluginLoader($type): retrieves the plugin loader associated with $type.
* addPrefixPath($prefix, $path, $type = null): adds a prefix/path association to the loader specified by $type. If $type is null, it will attempt to add the path to all loaders, by appending the prefix with each of "_Element" and "_Decorator"; and appending the path with "Element/" and "Decorator/". If you have all your extra form element classes under a common hierarchy, this is a convenience method for setting the base prefix for them.
* addPrefixPaths(array $spec): allows you to add many paths at once to one or more plugin loaders. It expects each array item to be an array with the keys 'path', 'prefix', and 'type'.

Custom elements and decorators are an easy way to share functionality between forms and encapsulate custom functionality.

h2. Elements

Zend_Form provides several accessors for adding and removing elements from the form. These can take element object instances or serve as factories for instantiating the element objects themselves.

The most basic method for adding an element is addElement(). This method can take either an object of type Zend_Form_Element (or of a class extending Zend_Form_Element), or arguments for building a new element -- including the element type, name, and any configuration options.

As some examples:

{code:php}
// Using an element instance:
$element = new Zend_Form_Element_Text('foo');
$form->addElement($element);

// Using a factory
//
// Creates an element of type Zend_Form_Element_Text with the
// name of 'foo':
$form->addElement('text', 'foo');

// Pass label option to the element:
$form->addElement('text', 'foo', array('label' => 'Foo:'));
{code}

Once an element has been added to the form, you can retrieve it by name. This can be done either by using the getElement() method or by using overloading to access the element as an object property:

{code:php}
// getElement():
$foo = $form->getElement('foo');

// As object property:
$foo = $form->foo;
{code}

h3. Populating and Retrieving Values

After validating a form, you will typically need to retrieve the values so you can perform other operations, such as updating a database or notifying a web service. You can retrieve all values for all elements using getValues(); getValue($name) allows you to retrieve a single element's value by element name:

{code:php}
// Get all values:
$values = $form->getValues();

// Get only 'foo' element's value:
$value = $form->getValue('foo');
{code}

Sometimes you'll want to populate the form with specified values prior to rendering. This can be done with either the setDefaultValues() or populate() methods:

{code:php}
$form->setDefaultValues($data);
$form->populate($data);
{code}

h3. Global Operations
Occasionally you will want certain operations to affect all elements. Common scenarios include needing to set plugin prefix paths for all elements, setting decorators for all elements, and setting filters for all elements. As examples:

{info:title=Setting Prefix Paths for All Elements}
You can set prefix paths for all elements by type, or using a global prefix. As some examples:

{code:php}
// Set global prefix path:
// Creates paths for prefixes My_Foo_Filter, My_Foo_Validate,
// and My_Foo_Decorator
$form->addElementPrefixPath('My_Foo', 'My/Foo/');

// Just filter paths:
$form->addElementPrefixPath('My_Foo_Filter', 'My/Foo/Filter', 'filter');

// Just validator paths:
$form->addElementPrefixPath('My_Foo_Validate', 'My/Foo/Validate', 'validate');

// Just decorator paths:
$form->addElementPrefixPath('My_Foo_Decorator', 'My/Foo/Decorator', 'decorator');
{code}
{info}

{info:title=Setting Decorators for All Elements}
You can set decorators for all elements. setElementDecorators() accepts an array of decorators, just like setDecorators(), and will overwrite any previously set decorators in each element. In this example, we set the decorators to simply a ViewHelper and a Label:

{code:php}
$form->setElementDecorators(array(
'ViewHelper',
'Label'
));
{code}
{info}

{info:title=Setting Filters for All Elements}
In many cases, you may want to apply the same filter to all elements; a common case is to trim() all values:

{code:php}
$form->setElementFilters(array('StringTrim'));
{code}
{info}

h3. Methods For Interacting With Elements
The following methods may be used to interact with elements:

* addElement($element, $name = null, $options = null)
* addElements(array $elements)
* setElements(array $elements)
* getElement($name)
* getElements()
* removeElement($name)
* clearElements()
* setDefaults(array $defaults)
* setDefault($name, $value)
* getValue($name)
* getValues()
* getUnfilteredValue($name)
* getUnfilteredValues()
* setElementFilters(array $filters)
* setElementDecorators(array $decorators)
* addElementPrefixPath($prefix, $path, $type = null)
* addElementPrefixPaths(array $spec)

h2. Display Groups

Display groups are a way to create virtual groupings of elements for display purposes. All elements remain accessible by name in the form, but when iterating over the form or rendering, any elements in a display group are rendered together. The most common use case for this is for grouping elements in fieldsets.

The base class for display groups is Zend_Form_DisplayGroup. While it can be instantiated directly, it is typically best to use Zend_Form's addDisplayGroup() method to do so. This method takes an array of elements as its first argument, and a name for the display group as its second argument. You may optionally pass in an array of options or a Zend_Config object as the third argument.

Assuming that the elements 'username' and 'password' are already set in the form, the following code would group these elements in a 'login' display group:

{code:php}
$form-addDisplayGroup(array('username', 'password'), 'login');
{code}

You can access display groups using the getDisplayGroup() method, or via overloading using the display group's name:

{code:php}
// Using getDisplayGroup():
$login = $form->getDisplayGroup('login');

// Using overloading:
$login = $form->login;
{code}

h3. Global Operations
Just as with elements, there are some operations which might affect all display groups; these include setting decorators and setting the plugin path in which to look for decorators.

{info:title=Setting Decorator Prefix Path for All Display Groups}
By default, display groups inherit whichever decorator paths the form uses; however, if they should look in alternate locations, you can use the addDisplayGroupPrefixPath() method.

{code:php}
$form->addDisplayGroupPrefixPath('My_Foo_Decorator', 'My/Foo/Decorator');
{code}
{info}

{info:title=Setting Decorators for All Display Groups}
You can set decorators for all display groups. setDisplayGroupDecorators() accepts an array of decorators, just like setDecorators(), and will overwrite any previously set decorators in each display group. In this example, we set the decorators to simply a fieldset (the FormElements decorator is necessary to ensure that the elements are iterated):

{code:php}
$form->setDisplayGroupDecorators(array(
'FormElements',
'Fieldset'
));
{code}
{info}

h3. Methods for Interacting With Display Groups
The following methods may be used to interact with display groups:

* addDisplayGroup(array $elements, $name, $options = null)
* addDisplayGroups(array $groups)
* setDisplayGroups(array $groups)
* getDisplayGroup($name)
* getDisplayGroups()
* removeDisplayGroup($name)
* clearDisplayGroups()
* setDisplayGroupDecorators(array $decorators)
* addDisplayGroupPrefixPath($prefix, $path)

h3. Zend_Form_DisplayGroup Methods
Zend_Form_DisplayGroup has the following methods, grouped by type:

* *Configuration:*
** setOptions(array $options)
** setConfig(Zend_Config $config)
* *Metadata:*
** setAttrib($key, $value)
** addAttribs(array $attribs)
** setAttribs(array $attribs)
** getAttrib($key)
** getAttribs()
** removeAttrib($key)
** clearAttribs()
** setName($name)
** getName()
** setLegend($legend)
** getLegend()
** setOrder($order)
** getOrder()
* *Elements:*
** addElement(Zend_Form_Element $element)
** addElements(array $elements)
** setElements(array $elements)
** getElement($name)
** getElements()
** removeElement($name)
** clearElements()
* *Plugin loaders:*
** setPluginLoader(Zend_Loader_PluginLoader $loader)
** getPluginLoader()
** addPrefixPath($prefix, $path)
** addPrefixPaths(array $spec)
* *Decorators:*
** addDecorator($decorator, $options = null)
** addDecorators(array $decorators)
** setDecorators(array $decorators)
** getDecorator($name)
** getDecorators()
** removeDecorator($name)
** clearDecorators()
* *Rendering:*
** setView(Zend_View_Interface $view = null)
** getView()
** render(Zend_View_Interface $view = null)
* *I18N:*
** setTranslator(Zend_Translate_Adapter $translator = null)
** getTranslator()

h2. Sub Forms

Sub forms serve several purposes:

* Creating logical element groups. Since sub forms are simply forms, you can validate subforms as individual entities.
* Creating multi-page forms. Since sub forms are simply forms, you can display a separate sub form per page, building up multi-page forms where each form has its own validation logic. Only once all sub forms validate would the form be considered complete.
* Display groupings. Like display groups, sub forms, when rendered as part of a larger form, can be used to group elements. Be aware, however, that the master form object will have no awareness of the elements in sub forms.

A sub form may be a Zend_Form object, or, more typically, a Zend_Form_SubForm object. The latter contains decorators suitable for inclusion in a larger form (i.e., it does not render additional HTML form tags, but does group elements). To attach a sub form, simply add it to the form and give it a name:

{code:php}
$form->addSubForm($subForm, 'subform');
{code}

You can retrieve a sub form using either getSubForm($name) or overloading using the sub form name:

{code:php}
// Using getSubForm():
$subForm = $form->getSubForm('subform');

// Using overloading:
$subForm = $form->subform;
{code}

Sub forms are included in form iteration, though the elements it contains are not.

h3. Global Operations
Like elements and display groups, there are some operations that might need to affect all sub forms. Unlike display groups and elements, however, sub forms inherit most functionality from the master form object, and the only real operation that may need to be performed globally is setting decorators for sub forms. For this purpose, there is the setSubFormDecorators() method. In the next example, we'll set the decorator for all subforms to be simply a fieldset (the FormElements decorator is needed to ensure its elements are iterated):

{code:php}
$form->setSubFormsDecorators(array(
'FormElements',
'Fieldset'
));
{code}

h3. Methods for Interacting With Sub Forms
The following methods may be used to interact with sub forms:

* addSubForm(Zend_Form $form, $name, $order = null)
* addSubForms(array $subForms)
* setSubForms(array $subForms)
* getSubForm($name)
* getSubForms()
* removeSubForm($name)
* clearSubForms()
* setSubFormDecorators(array $decorators)

h2. Metadata and Attributes

While a form's usefulness primarily derives from the elements it contains, it can also contain other metadata, such as a name (often used as a unique ID in the HTML markup); the form action and method; the number of elements, groups, and sub forms it contains; and arbitrary metadata (usually used to set HTML attributes for the form tag itself).

You can set and retrieve a form's name using the name accessors:

{code:php}
// Set the name:
$form->setName('registration');

// Retrieve the name:
$name = $form->getName();
{code}

To set the action (url to which the form submits) and method (method by which it should submit, e.g., 'POST' or 'GET'), use the action and method accessors:

{code:php}
// Set the action and method:
$form->setAction('/user/login')
->setMethod('post');
{code}

{note}
The method and action are only used internally for rendering, and not for any sort of validation.
{note}

Zend_Form implements the Countable interface, allowing you to pass it as an argument to count:

{code:php}
$numItems = count($form);
{code}

Setting arbitrary metadata is done through the attribs accessors. Since overloading in Zend_Form is used to access elements, display groups, and sub forms, this is the only method for accessing metadata.

{code:php}
// Setting attributes:
$form->setAttrib('class', 'zend-form')
->addAttribs(array(
'id' => 'registration',
'onSubmit' => 'validate(this)',
));

// Retrieving attributes:
$class = $form->getAttrib('class');
$attribs = $form->getAttribs();

// Remove an attribute:
$form->removeAttrib('onSubmit');

// Clear all attributes:
$form->clearAttribs();
{code}

h2. Decorators

Creating the markup for a form is often a time-consuming task, particularly if you plan on re-using the same markup to show things such as validation errors, submitted values, etc. Zend_Form's answer to this issue is decorators.

Decorators for Zend_Form objects can be used to render a form. The FormElements decorator will iterate through all items in a form -- elements, display groups, and sub forms -- and render them, returning the result. Additional decorators may then be used to wrap this content, or append or prepend it.

The default decorators for Zend_Form are FormElements, HtmlTag (wraps in a definition list), and Form; the equivalent code for creating them is as follows:

{code:php}
$form->setDecorators(array(
'FormElements',
array('HtmlTag', array('tag' => 'dl')),
'Form'
));
{code}

This creates output like the following:

{code:html}
<form action="/form/action" method="post">
<dl>
...
</dl>
</form>
{code}

Any attributes set on the form object will be used as HTML attributes of the &lt;form&gt; tag.

You may create your own decorators for generating the form. One common use case is if you know the exact HTML you wish to use; your decorator could create the exact HTML and simply return it, potentially using the decorators from individual elements or display groups.

The following methods may be used to interact with decorators:

* addDecorator($decorator, $options = null)
* addDecorators(array $decorators)
* setDecorators(array $decorators)
* getDecorator($name)
* getDecorators()
* removeDecorator($name)
* clearDecorators()

h2. Validation

A primary use case for forms is validating submitted data. Zend_Form allows you to validate an entire form at once or a partial form, as well as to automate validation responses for XmlHttpRequests (AJAX). If the submitted data is not valid, it has methods for retrieving the various error codes and messages for elements and sub forms failing validations.

To validate a full form, use the isValid() method:

{code:php}
if (!$form->isValid($_POST)) {
// failed validation
}
{code}

isValid() will validate every required element, and any unrequired element contained in the submitted data.

Sometimes you may need to validate only a subset of the data; for this, use isValidPartial($data):

{code:php}
if (!$form->isValidPartial($data)) {
// failed validation
}
{code}

isValidPartial() only attempts to validate those items in the data for which there are matching elements; if an element is not represented in the data, it is skipped.

When validating elements or groups of elements for an AJAX request, you will typically be validating a subset of the form, and want the response back in JSON. processAjax() does precisely that:

{code:php}
$json = $form->processAjax($data);
{code}

You can then simply send the JSON response to the client. If the form is valid, this will be a boolean true response. If not, it will be a javascript object containing key/message pairs, where each 'message' is an array of validation error messages.

For forms that fail validation, you can retrieve both error codes and error messages, using getErrors() and getMessages(), respectively:

{code:php}
$codes = $form->getErrors();
$messages = $form->getMessage();
{code}

{note}
Since the messages returned by getMessages() are an array of error code/message pairs, getErrors() is typically not needed.
{note}

You can retrieve codes and error messages for individual elements by simply passing the element name to each:

{code:php}
$codes = $form->getErrors('username');
$messages = $form->getMessages('username');
{code}

{note}
When validating elements, Zend_Form sends a second argument to each element's isValid() method: the array of data being validated. This can then be used by individual validators to allow them to utilize other submitted values when determining the validity of the data. An example would be a registration form that requires both a password and password confirmation; the password element could use the password confirmation as part of its validation.
{note}

h2. Methods

The following is a full list of methods available to Zend_Form, grouped by type:

* *Configuration and Options:*
** setOptions(array $options)
** setConfig(Zend_Config $config)
* *Plugin Loaders and paths:*
** setPluginLoader(Zend_Loader_PluginLoader_Interface $loader, $type = null)
** getPluginLoader($type = null)
** addPrefixPath($prefix, $path, $type = null)
** addPrefixPaths(array $spec)
** addElementPrefixPath($prefix, $path, $type = null)
** addElementPrefixPaths(array $spec)
** addDisplayGroupPrefixPath($prefix, $path)
* *Metadata:*
** setAttrib($key, $value)
** addAttribs(array $attribs)
** setAttribs(array $attribs)
** getAttrib($key)
** getAttribs()
** removeAttrib($key)
** clearAttribs()
** setAction($action)
** getAction()
** setMethod($method)
** getMethod()
** setName($name)
** getName()
* *Elements:*
** addElement($element, $name = null, $options = null)
** addElements(array $elements)
** setElements(array $elements)
** getElement($name)
** getElements()
** removeElement($name)
** clearElements()
** setDefaults(array $defaults)
** setDefault($name, $value)
** getValue($name)
** getValues()
** getUnfilteredValue($name)
** getUnfilteredValues()
** setElementFilters(array $filters)
** setElementDecorators(array $decorators)
* *Sub forms:*
** addSubForm(Zend_Form $form, $name, $order = null)
** addSubForms(array $subForms)
** setSubForms(array $subForms)
** getSubForm($name)
** getSubForms()
** removeSubForm($name)
** clearSubForms()
** setSubFormDecorators(array $decorators)
* *Display groups:*
** addDisplayGroup(array $elements, $name, $options = null)
** addDisplayGroups(array $groups)
** setDisplayGroups(array $groups)
** getDisplayGroup($name)
** getDisplayGroups()
** removeDisplayGroup($name)
** clearDisplayGroups()
** setDisplayGroupDecorators(array $decorators)
* *Validation*
** populate(array $values)
** isValid(array $data)
** isValidPartial(array $data)
** processAjax(array $data)
** persistData()
** getErrors($name = null)
** getMessages($name = null)
* *Rendering:*
** setView(Zend_View_Interface $view = null)
** getView()
** addDecorator($decorator, $options = null)
** addDecorators(array $decorators)
** setDecorators(array $decorators)
** getDecorator($name)
** getDecorators()
** removeDecorator($name)
** clearDecorators()
** render(Zend_View_Interface $view = null)
* *I18N:*
** setTranslator(Zend_Translate_Adapter $translator = null)
** getTranslator()

h2. Configuration

Zend_Form is fully configurable via setOptions() and setConfig() (or by passing options or a Zend_Config object to the constructor). Using these methods, you can specify form elements, display groups, decorators, and metadata.

As a general rule, if 'set' + the option key refers to a Zend_Form method, then the value provided will be passed to that method.

Exceptions to the rule include the following:

* prefixPaths will be passed to addPrefixPaths()
* elementPrefixPaths will be passed to addElementPrefixPaths()
* displayGroupPrefixPaths will be passed to addDisplayGroupPrefixPaths()
* the following setters cannot be set in this way:
** setAttrib (though setAttribs *will* work)
** setConfig
** setDefault
** setOptions
** setPluginLoader
** setSubForms
** setTranslator
** setView

As an example, here is a config file that passes configuration for every type of configurable data:

{code:ini}
[element]
name = "registration"
action = "/user/register"
method = "post"
attribs.class = "zend_form"
attribs.onclick = "validate(this)"

prefixPaths.element.prefix = "My_Element"
prefixPaths.element.path = "My/Element/"
elementPrefixPaths.validate.prefix = "My_Validate"
elementPrefixPaths.validate.path = "My/Validate/"
displayGroupPrefixPaths.prefix = "My_Group"
displayGroupPrefixPaths.path = "My/Group/"

elements.username.type = "text"
elements.username.options.label = "Username"
elements.username.options.validators.alpha.validator = "Alpha"
elements.username.options.filters.lcase = "StringToLower"
; more elements, of course...

elementFilters.trim = "StringTrim"
;elementDecorators.trim = "StringTrim"

displayGroups.login.elements.username = "username"
displayGroups.login.elements.password = "password"
displayGroupDecorators.elements.decorator = "FormElements"
displayGroupDecorators.fieldset.decorator = "Fieldset"

decorators.elements.decorator = "FormElements"
decorators.fieldset.decorator = "FieldSet"
decorators.fieldset.decorator.options.class = "zend_form"
decorators.form.decorator = "Form"
{code}

The above could easily be abstracted to an XML or PHP array-based configuration file.

h2. Custom forms

An alternative to using configuration-based forms is to subclass Zend_Form. This has several benefits:

* You can unit test your form easily to ensure validations and rendering perform as expected.
* Fine-grained control over individual elements.
* Re-use of form objects, and greater portability (no need to track config files).
* Implementing custom functionality.

The most typical use case would be to use the constructor to setup specific form elements and configuration:

{code:php}
class My_Form_Login extends Zend_Form
{
public function __construct($options = null)
{
$username = new Zend_Form_Element_Text('username');
$username->class = 'formtext';
$username->setLabel('Username:')
->setDecorators(array(
array('ViewHelper', array('helper' => 'formText')),
array('Label', array('class' => 'label'))
));

$password = new Zend_Form_Element_Password('password);
$password->class = 'formtext';
$password->setLabel('Username:')
->setDecorators(array(
array('ViewHelper', array('helper' => 'formPassword')),
array('Label', array('class' => 'label'))
));

$submit = new Zend_Form_Element_Submit('login');
$submit->class = 'formsubmit';
$submit->setValue('Login')
->setDecorators(array(
array('ViewHelper', array('helper' => 'formSubmit'))
));

$this->addElements(array(
$username,
$password,
$submit
));

$this->setDecorators(array(
'FormElements',
'Fieldset',
'Form'
));
}
}
{code}

This form can then be instantiated with simply:

{code:php}
$form = new My_Form_Login();
{code}

and all functionality is already setup and ready; no config files needed. (Note that this example is greatly simplified, as it contains no validators or filters for the elements.)

h1. Creating Custom Form Markup Using Zend_Form_Decorator

Rendering a form object is completely optional -- you do not need to use Zend_Form's render() methods at all. However, if you do, decorators are used to render the various form objects.

An arbitrary number of decorators may be attached to each item (elements, display groups, sub forms, or the form object itself); however, only one decorator of a given type may be attached to each item. Decorators are called in the order they are registered. Depending on the decorator, it may replace the content passed to it, or append or prepend the content.

Object state is set via configuration options passed to the constructor or the decorator's setOptions() method. When creating decorators via an item's addDecorator() or related methods, options may be passed as an argument to the method. These can be used to specify placement, a separator to use between passed in content and newly generated content, and whatever options the decorator supports.

Before each decorator's render() method is called, the current item is set in the decorator using setElement(), giving the decorator awareness of the item being rendered. This allows you to create decorators that only render specific portions of the item -- such as the label, the value, error messages, etc. By stringing together several decorators that render specific element segments, you can build complex markup representing the entire item.

h2. Operation

To configure a decorator, pass an array of options or a Zend_Config object to its constructor, an array to setOptions(), or a Zend_Config object to setConfig().

Standard options include:
* placement: Placement can be either 'append' or 'prepend' (case insensitive), and indicates whether content passed to render() will be appended or prepended, respectively. In the case that a decorator replaces the content, this setting is ignored. The default setting is to append.
* separator: The separator is used between the content passed to render() and new content generated by the decorator, or between items rendered by the decorator (e.g. FormElements uses the separator between each item rendered). In the case that a decorator replaces the content, this setting may be ignored. The default value is PHP_EOL.

The decorator interface specifies methods for interacting with options. These include:

* setOption($key, $value): set a single option.
* getOption($key): retrieve a single option value.
* getOptions(): retrieve all options.
* removeOption($key): remove a single option.
* clearOptions(): remove all options.

Decorators are meant to interact with the various Zend_Form class types: Zend_Form, Zend_Form_Element, Zend_Form_DisplayGroup, and all classes deriving from them. The method setElement() allows you to set the object the decorator is currently working with, and getElement() is used to retrieve it.

Each decorator's render() method accepts a string, $content. When the first decorator is called, this string is typically empty, while on subsequent calls it will be populated. Based on the type of decorator and the options passed in, the decorator will either replace this string, prepend the string, or append the string; an optional separator will be used in the latter two situations.

h2. Standard Decorators

Zend_Form ships with several standard decorators.

h3. Callback

The Callback decorator can execute an arbitrary callback to render content. Callbacks should be specified via the 'callback' option passed in the decorator configuration, and can be any valid PHP callback type. Callbacks should accept three arguments, $content (the original content passed to the decorator), $element (the item being decorated), and an array of $options. As an example callback:

{code:php}
class Util
{
public static function label($content, $element, array $options)
{
return '<span class="label">' . $element->getLabel() . "</span>";
}
}
{code}

This callback would be specified as array('Util', 'label'), and would generate some (bad) HTML markup for the label. The Callback decorator would then either replace, append, or prepend the original content with the return value of this.

The Callback decorator allows specifying a null value for the placement option, which will replace the original content with the callback return value; 'prepend' and 'append' are still valid as well.

h3. DtDdWrapper

The default decorators utilize definition lists (&lt;dl&gt;) to render form elements. Since form items can appear in any order, display groups and sub forms can be interspersed with other form items. To keep these particular item types within the definition list, the DtDdWrapper creates a new, empty definition term (&lt;dt&gt;) and wraps its content in a new definition datum (&lt;dd&gt;). The output looks something like this:

{code:html}
<dt></dt>
<dd><fieldset id="subform">
<legend>User Information</legend>
...
</fieldset></dd>
{code}

This decorator replaces the content provided to it by wrapping it within the &lt;dd&gt; element.

h3. Errors

Element errors get their own decorator with the Errors decorator. This decorator proxies to the FormErrors view helper, which renders error messages in an unordered list (&lt;ul&gt;) as list items. The &lt;ul&gt; element receives a class of "errors".

The Errors decorator can either prepend or append the content provided to it.

h3. Fieldset

Display groups and sub forms render their content within fieldsets by default. The Fieldset decorator checks for either a 'legend' option or a getLegend() method in the registered element, and uses that as a legend if non-empty. Any content passed in is wrapped in the HTML fieldset, replacing the original content. Any attributes set in the decorated item are passed to the fieldset as HTML attributes.

h3. Form

Zend_Form objects typically need to render an HTML form tag. The Form decorator proxies to the Form view helper. It wraps any provided content in an HTML form element, using the Zend_Form object's action and method, and any attributes as HTML attributes.

h3. FormElements

Forms, display groups, and sub forms are collections of elements. In order to render these elements, they utilize the FormElements decorator, which iterates through all items, calling render() on each and joining them with the registered separator. It can either append or prepend content passed to it.

h3. HtmlTag

The HtmlTag decorator allows you to utilize HTML tags to decorate content; the tag utilized is passed in the 'tag' option, and any other options are used as HTML attributes to that tag. The tag by default is assumed to be block level, and replaces the content by wrapping it in the given tag. However, you can specify a placement to append or prepend a tag as well.

h3. Label

Form elements typically have labels, and the Label decorator is used to render these labels. It proxies to the FormLabel view helper, and pulls the element label using the getLabel() method of the element. If no label is present, none is rendered.

You may optionally specify a 'tag' option; if provided, it wraps the label in that block-level tag. If the 'tag' option is present, and no label present, the tag is rendered with no content.

By default, the Label decorator prepends to the provided content; specify a 'placement' option of 'append' to place it after the content.

h3. ViewHelper

Most elements utilize Zend_View helpers for rendering, and this is done with the ViewHelper decorator. With it, you may specify a 'helper' tag to explicitly set the view helper to utilize; if none is provided, it uses the last segment of the element's class name to determine the helper, prepending it with the string 'form': e.g., 'Zend_Form_Element_Text' would look for a view helper of 'formText'.

Any attributes of the provided element are passed to the view helper as element attributes.

By default, this decorator appends content; use the 'placement' option to specify alternate placement.

h2. Custom Decorators

If you find your rendering needs are complex or need heavy customization, or if you need to use multiple decorators of the same type, you should consider creating a custom decorator.

Decorators need only implement Zend_Decorator_Interface. The interface specifies the following:

{code:php}
interface Zend_Form_Decorator_Interface
{
public function __construct($options = null);
public function setElement($element);
public function getElement();
public function setOptions(array $options);
public function setConfig(Zend_Config $config);
public function setOption($key, $value);
public function getOption($key);
public function getOptions();
public function removeOption($key);
public function clearOptions();
public function render($content);
}
{code}

To make this simpler, you can simply extend Zend_Decorator_Abstract, which implements all methods except render().

As an example, if you wanted to have labels append a ':', and also display a '*' when required, you could write a decorator like the following:

{code:php}
class My_Decorator_Label extends Zend_Form_Decorator_Abstract
{
public function getLabel()
{
$label = $this->getOption('label');
if (null === $label) {
if ((null !== ($element = $this->getElement()))
&& ($element instanceof Zend_Form_Element) )
{
$label = $element->getLabel();
}
}

return (string) $label;
}

public function render($content)
{
$element = $this->getElement();
if (!$element instanceof Zend_Form_Element) {
return $content;
}

$label = $this->getLabel();
if ($translator = $element->getTranslator()) {
$label = $translator->translate($label);
}
if ($element->getRequired()) {
$label .= '*';
}
$label .= ':';

$separator = $this->getSeparator();
$placement = $this->getPlacement();
$view = $element->getView();
if (null !== $view) {
$label = $view->formLabel($element->getName(), $label, $this->getOptions());
}

switch ($placement) {
case (self::PREPEND):
return $label . $separator . $content;
case (self::APPEND):
default:
return $content . $separator . $label;
}
}
}
{code}

You can then place this in the decorator path:

{code:php}
// for an element:
$element->addPrefixPath('My_Decorator', 'My/Decorator/', 'decorator');

// for all elements:
$form->addElementPrefixPath('My_Decorator', 'My/Decorator/', 'decorator');
{code}

In this particular example, because the decorator's final segment, 'Label' matches the same as Zend_Form_Decorator_Label, it will be rendered *in place of* that decorator -- meaning you would not need to change any decorators to modify the output. (Needless to say, you can create decorators with different names; this simply shows how you can quickly and simply override existing rendering functionality through custom decorators.)