Previous Next

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 performs 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; its best use is for Rapid Application Development (RAD) and prototyping.

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

// Generic form object:
$form = new Zend_Form();

// Custom form object:
$form = new My_Form()

You can optionally pass in a instance of Zend_Config or an array, which will be used to set object state and potentially create new elements:

// Passing in configuration options:
$form = new Zend_Form($config);

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.

Plugin Loaders

Zend_Form makes use of Zend_Loader_PluginLoader to allow developers to specify the 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'.

Additionally, you can specify prefix paths for all elements and display groups created through a Zend_Form instance using the following methods:

  • addElementPrefixPath($prefix, $path, $type = null): Just like addPrefixPath(), you must specify a class prefix and a path. $type, when specified, must be one of the plugin loader types specified by Zend_Form_Element; see the element plugins section for more information on valid $type values. If no $type is specified, the method will assume it is a general prefix for all types.

  • addDisplayGroupPrefixPath($prefix, $path): Just like addPrefixPath(), you must specify a class prefix and a path; however, since display groups only support decorators as plugins, no $type is necessary.

Custom elements and decorators are an easy way to share functionality between forms and encapsulate custom functionality. See the Custom Label example in the elements documentation for an example of how custom elements can be used as replacements for standard classes.

Elements

Zend_Form provides several accessors for adding and removing form elements from a 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.

Some examples:

// 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:'));

Note: addElement() Implements Fluent Interface

addElement() implements a fluent interface; that is to say, it returns the Zend_Form object, and not the element. This is done to allow you to chain together multiple addElement() methods or other form methods that implement the fluent interface (all setters in Zend_Form implement the pattern).

If you wish to return the element instead, use createElement(), which is outlined below. Be aware, however, that createElement() does not attach the element to the form.

Internally, addElement() actually uses createElement() to create the element before attaching it to the form.

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:

// getElement():
$foo = $form->getElement('foo');

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

Occasionally, you may want to create an element without attaching it to the form (for instance, if you wish to make use of the various plugin paths registered with the form, but wish to later attach the object to a sub form). The createElement() method allows you to do so:

// $username becomes a Zend_Form_Element_Text object:
$username = $form->createElement('text', 'username');

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:

// Get all values:
$values = $form->getValues();

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

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

$form->setDefaults($data);
$form->populate($data);

On the flip side, you may want to clear a form after populating or validating it; this can be done using the reset() method:

$form->reset();

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:

Example #1 Setting Prefix Paths for All Elements

You can set prefix paths for all elements by type, or using a global prefix. Some examples:

// 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');

Example #2 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:

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

Example #3 Setting Decorators for Some Elements

You can also set decorators for a subset of elements, either by inclusion or exclusion. The second argument to setElementDecorators() may be an array of element names; by default, specifying such an array will set the specified decorators on those elements only. You may also pass a third argument, a flag indicating whether this list of elements is for inclusion or exclusion purposes. If the flag is FALSE, it will decorate all elements except those in the passed list. As with standard usage of the method, any decorators passed will overwrite any previously set decorators in each element.

In the following snippet, we indicate that we want only the ViewHelper and Label decorators for the 'foo' and 'bar' elements:

$form->setElementDecorators(
    array(
        'ViewHelper',
        'Label'
    ),
    array(
        'foo',
        'bar'
    )
);

On the flip side, with this snippet, we'll now indicate that we want to use only the ViewHelper and Label decorators for every element except the 'foo' and 'bar' elements:

$form->setElementDecorators(
    array(
        'ViewHelper',
        'Label'
    ),
    array(
        'foo',
        'bar'
    ),
    false
);

Note: Some Decorators are Inappropriate for Some Elements

While setElementDecorators() may seem like a good solution, there are some cases where it may actually end up with unexpected results. For example, the various button elements (Submit, Button, Reset) currently use the label as the value of the button, and only use ViewHelper and DtDdWrapper decorators -- preventing an additional labels, errors, and hints from being rendered. The example above would duplicate some content (the label) for button elements.

You can use the inclusion/exclusion array to overcome this issue as noted in the previous example.

So, use this method wisely, and realize that you may need to exclude some elements or manually change some elements' decorators to prevent unwanted output.

Example #4 Setting Filters for All Elements

In some cases, you may want to apply the same filter to all elements; a common case is to trim() all values:

$form->setElementFilters(array('StringTrim'));

Methods For Interacting With Elements

The following methods may be used to interact with elements:

  • createElement($element, $name = null, $options = null)

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

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 usually best to use Zend_Form's addDisplayGroup() method to do so. This method takes an array of element names 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:

$form->addDisplayGroup(array('username', 'password'), 'login');

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

// Using getDisplayGroup():
$login = $form->getDisplayGroup('login');

// Using overloading:
$login = $form->login;

Note: Default Decorators Do Not Need to Be Loaded

By default, the default decorators are loaded during object initialization. You can disable this by passing the 'disableLoadDefaultDecorators' option when creating a display group:

$form->addDisplayGroup(
    array('foo', 'bar'),
    'foobar',
    array('disableLoadDefaultDecorators' => true)
);

This option may be mixed with any other options you pass, both as array options or in a Zend_Config object.

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.

Example #5 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.

$form->addDisplayGroupPrefixPath('My_Foo_Decorator', 'My/Foo/Decorator');

Example #6 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):

$form->setDisplayGroupDecorators(array(
    'FormElements',
    'Fieldset'
));

Using Custom Display Group Classes

By default, Zend_Form uses the Zend_Form_DisplayGroup class for display groups. You may find you need to extend this class in order to provided custom functionality. addDisplayGroup() does not allow passing in a concrete instance, but does allow specifying the class to use as one of its options, using the 'displayGroupClass' key:

// Use the 'My_DisplayGroup' class
$form->addDisplayGroup(
    array('username', 'password'),
    'user',
    array('displayGroupClass' => 'My_DisplayGroup')
);

If the class has not yet been loaded, Zend_Form will attempt to do so using Zend_Loader.

You can also specify a default display group class to use with the form such that all display groups created with the form object will use that class:

// Use the 'My_DisplayGroup' class for all display groups:
$form->setDefaultDisplayGroupClass('My_DisplayGroup');

This setting may be specified in configurations as 'defaultDisplayGroupClass', and will be loaded early to ensure all display groups use that class.

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)

  • setDefaultDisplayGroupClass($class)

  • getDefaultDisplayGroupClass($class)

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()

    • setDescription($value)

    • getDescription()

    • setLegend($legend)

    • getLegend()

    • setOrder($order)

    • getOrder()

  • Elements:

    • createElement($type, $name, array $options = array())

    • addElement($typeOrElement, $name, array $options = array())

    • 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()

    • setDisableTranslator($flag)

    • translatorIsDisabled()

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:

$form->addSubForm($subForm, 'subform');

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

// Using getSubForm():
$subForm = $form->getSubForm('subform');

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

Sub forms are included in form iteration, although the elements they contain are not.

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):

$form->setSubFormDecorators(array(
    'FormElements',
    'Fieldset'
));

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)

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:

// Set the name:
$form->setName('registration');

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

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:

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

You may also specify the form encoding type specifically using the enctype accessors. Zend_Form defines two constants, Zend_Form::ENCTYPE_URLENCODED and Zend_Form::ENCTYPE_MULTIPART, corresponding to the values 'application/x-www-form-urlencoded' and 'multipart/form-data', respectively; however, you can set this to any arbitrary encoding type.

// Set the action, method, and enctype:
$form->setAction('/user/login')
     ->setMethod('post')
     ->setEnctype(Zend_Form::ENCTYPE_MULTIPART);

Note:

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

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

$numItems = count($form);

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.

// 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();

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:

$form->setDecorators(array(
    'FormElements',
    array('HtmlTag', array('tag' => 'dl')),
    'Form'
));

This creates output like the following:

...

Any attributes set on the form object will be used as HTML attributes of the <form> tag.

Note: Default Decorators Do Not Need to Be Loaded

By default, the default decorators are loaded during object initialization. You can disable this by passing the 'disableLoadDefaultDecorators' option to the constructor:

$form = new Zend_Form(array('disableLoadDefaultDecorators' => true));

This option may be mixed with any other options you pass, both as array options or in a Zend_Config object.

Note: Using Multiple Decorators of the Same Type

Internally, Zend_Form uses a decorator's class as the lookup mechanism when retrieving decorators. As a result, you cannot register multiple decorators of the same type; subsequent decorators will simply overwrite those that existed before.

To get around this, you can use aliases. Instead of passing a decorator or decorator name as the first argument to addDecorator(), pass an array with a single element, with the alias pointing to the decorator object or name:

// Alias to 'FooBar':
$form->addDecorator(array('FooBar' => 'HtmlTag'), array('tag' => 'div'));

// And retrieve later:
$form = $element->getDecorator('FooBar');

In the addDecorators() and setDecorators() methods, you will need to pass the 'decorator' option in the array representing the decorator:

// Add two 'HtmlTag' decorators, aliasing one to 'FooBar':
$form->addDecorators(
    array('HtmlTag', array('tag' => 'div')),
    array(
        'decorator' => array('FooBar' => 'HtmlTag'),
        'options' => array('tag' => 'dd')
    ),
);

// And retrieve later:
$htmlTag = $form->getDecorator('HtmlTag');
$fooBar  = $form->getDecorator('FooBar');

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()

Zend_Form also uses overloading to allow rendering specific decorators. __call() will intercept methods that lead with the text 'render' and use the remainder of the method name to lookup a decorator; if found, it will then render that single decorator. Any arguments passed to the method call will be used as content to pass to the decorator's render() method. As an example:

// Render only the FormElements decorator:
echo $form->renderFormElements();

// Render only the fieldset decorator, passing in content:
echo $form->renderFieldset("

This is fieldset content

");

If the decorator does not exist, an exception is raised.

Validation

A primary use case for forms is validating submitted data. Zend_Form allows you to validate an entire form, a partial form, or 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.

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

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

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):

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

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:

$json = $form->processAjax($data);

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:

$codes = $form->getErrors();
$messages = $form->getMessages();

Note:

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

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

$codes = $form->getErrors('username');
$messages = $form->getMessages('username');

Note:

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.

Custom Error Messages

At times, you may want to specify one or more specific error messages to use instead of the error messages generated by the validators attached to your elements. Additionally, at times you may want to mark the form invalid yourself. This functionality is possible via the following methods.

  • addErrorMessage($message): add an error message to display on form validation errors. You may call this more than once, and new messages are appended to the stack.

  • addErrorMessages(array $messages): add multiple error messages to display on form validation errors.

  • setErrorMessages(array $messages): add multiple error messages to display on form validation errors, overwriting all previously set error messages.

  • getErrorMessages(): retrieve the list of custom error messages that have been defined.

  • clearErrorMessages(): remove all custom error messages that have been defined.

  • markAsError(): mark the form as having failed validation.

  • addError($message): add a message to the custom error messages stack and flag the form as invalid.

  • addErrors(array $messages): add several messages to the custom error messages stack and flag the form as invalid.

  • setErrors(array $messages): overwrite the custom error messages stack with the provided messages and flag the form as invalid.

All errors set in this fashion may be translated.

Retrieving Valid Values Only

There are scenarios when you want to allow your user to work on a valid form in several steps. Meanwhile you allow the user to save the form with any set of values inbetween. Then if all the data is specified you can transfer the model from the building or prototying stage to a valid stage.

You can retrieve all the valid values that match the submitted data by calling:

$validValues = $form->getValidValues($_POST);

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()

    • setDisableTranslator($flag)

    • translatorIsDisabled()

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. If the accessor does not exist, the key is assumed to reference an attribute, and will be passed to setAttrib().

Exceptions to the rule include the following:

  • prefixPath will be passed to addPrefixPaths()

  • elementPrefixPath will be passed to addElementPrefixPaths()

  • displayGroupPrefixPath 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:

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

disableTranslator = 0

prefixPath.element.prefix = "My_Element"
prefixPath.element.path = "My/Element/"
elementPrefixPath.validate.prefix = "My_Validate"
elementPrefixPath.validate.path = "My/Validate/"
displayGroupPrefixPath.prefix = "My_Group"
displayGroupPrefixPath.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"

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

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 init() method to setup specific form elements and configuration:

class My_Form_Login extends Zend_Form
{
    public function init()
    {
        $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('Password:')
                 ->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'
        ));
    }
}

This form can then be instantiated with simply:

$form = new My_Form_Login();

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

Another common reason for extension is to define a set of default decorators. You can do this by overriding the loadDefaultDecorators() method:

class My_Form_Login extends Zend_Form
{
    public function loadDefaultDecorators()
    {
        $this->setDecorators(array(
            'FormElements',
            'Fieldset',
            'Form'
        ));
    }
}
Previous Next
Introduction to Zend Framework
Overview
Installation
Learning Zend Framework
Zend Framework Quick Start
Zend Framework & MVC Introduction
Create Your Project
Create A Layout
Create a Model and Database Table
Create A Form
Congratulations!
Autoloading in Zend Framework
Introduction
Goals and Design
Basic Autoloader Usage
Resource Autoloading
Conclusion
Plugins in Zend Framework
Introduction
Using Plugins
Conclusion
Getting Started with Zend_Layout
Introduction
Using Zend_Layout
Zend_Layout: Conclusions
Getting Started Zend_View Placeholders
Introduction
Basic Placeholder Usage
Standard Placeholders
View Placeholders: Conclusion
Understanding and Using Zend Form Decorators
Introduction
Decorator Basics
Layering Decorators
Rendering Individual Decorators
Creating and Rendering Composite Elements
Conclusion
Getting Started with Zend_Session, Zend_Auth, and Zend_Acl
Building Multi-User Applications With Zend Framework
Managing User Sessions In ZF
Authenticating Users in Zend Framework
Building an Authorization System in Zend Framework
Getting Started with Zend_Search_Lucene
Zend_Search_Lucene Introduction
Lucene Index Structure
Index Opening and Creation
Indexing
Searching
Supported queries
Search result pagination
Getting Started with Zend_Paginator
Introduction
Simple Examples
Pagination Control and ScrollingStyles
Putting it all Together
Zend Framework Reference
Zend_Acl
Introduction
Refining Access Controls
Advanced Usage
Zend_Amf
Introduction
Zend_Amf_Server
Zend_Application
Introduction
Zend_Application Quick Start
Theory of Operation
Examples
Core Functionality
Available Resource Plugins
Zend_Auth
Introduction
Database Table Authentication
Digest Authentication
HTTP Authentication Adapter
LDAP Authentication
Open ID Authentication
Zend_Barcode
Introduction
Barcode creation using Zend_Barcode class
Zend_Barcode Objects
Zend_Barcode Renderers
Zend_Cache
Introduction
The Theory of Caching
Zend_Cache Frontends
Zend_Cache Backends
The Cache Manager
Zend_Captcha
Introduction
Captcha Operation
CAPTCHA Adapters
SimpleCloud API: Zend_Cloud
Document Service Introduction
Queue Service Introduction
StorageService Introduction
Zend_CodeGenerator
Introduction
Zend_CodeGenerator Examples
Zend_CodeGenerator Reference
Zend_Config
Introduction
Theory of Operation
Zend_Config_Ini
Zend_Config_Json
Zend_Config_Xml
Zend_Config_Yaml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Introduction
Declaring Getopt Rules
Fetching Options and Arguments
Configuring Zend_Console_Getopt
Zend_Controller
Zend_Controller Quick Start
Zend_Controller Basics
The Front Controller
The Request Object
The Standard Router
The Dispatcher
Action Controllers
Action Helpers
The Response Object
Plugins
Using a Conventional Modular Directory Structure
MVC Exceptions
Zend_Currency
Introduction to Zend_Currency
Using Zend_Currency
Options for currencies
What makes a currency?
Where is the currency?
How does the currency look like?
How much is my currency?
Calculating with currencies
Exchanging currencies
Additional informations on Zend_Currency
Zend_Date
Introduction
Theory of Operation
Basic Methods
Zend_Date API Overview
Creation of Dates
Constants for General Date Functions
Working Examples
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Zend_Db_Table Relationships
Zend_Db_Table_Definition
Zend_Debug
Dumping Variables
Zend_Dojo
Introduction
Zend_Dojo_Data: dojo.data Envelopes
Dojo View Helpers
Dojo Form Elements and Decorators
Zend_Dojo build layer support
Zend_Dom
Introduction
Zend_Dom_Query
Zend_Exception
Using Exceptions
Basic usage
Previous Exceptions
Zend_Feed
Introduction
Importing Feeds
Retrieving Feeds from Web Pages
Consuming an RSS Feed
Consuming an Atom Feed
Consuming a Single Atom Entry
Modifying Feed and Entry structures
Custom Feed and Entry Classes
Zend_Feed_Reader
Zend_Feed_Writer
Zend_Feed_Pubsubhubbub
Zend_File
Zend_File_Transfer
Validators for Zend_File_Transfer
Filters for Zend_File_Transfer
Zend_Filter
Introduction
Standard Filter Classes
Filter Chains
Writing Filters
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Zend_Form Quick Start
Creating Form Elements Using Zend_Form_Element
Creating Forms Using Zend_Form
Creating Custom Form Markup Using Zend_Form_Decorator
Standard Form Elements Shipped With Zend Framework
Standard Form Decorators Shipped With Zend Framework
Internationalization of Zend_Form
Advanced Zend_Form Usage
Zend_Gdata
Introduction
Authenticating with AuthSub
Using the Book Search Data API
Authenticating with ClientLogin
Using Google Calendar
Using Google Documents List Data API
Using Google Health
Using Google Spreadsheets
Using Google Apps Provisioning
Using Google Base
Using Picasa Web Albums
Using the YouTube Data API
Catching Gdata Exceptions
Zend_Http
Introduction
Zend_Http_Client - Advanced Usage
Zend_Http_Client - Connection Adapters
Zend_Http_Cookie and Zend_Http_CookieJar
Zend_Http_Response
Zend_Http_UserAgent
The UserAgent Device Interface
The UserAgent Features Adapter
The WURFL UserAgent Features Adapter
The DeviceAtlas UserAgent Features Adapter
The TeraWurfl UserAgent Features Adapter
The UserAgent Storage Interface
The Session UserAgent Storage Adapter
Zend_InfoCard
Introduction
Zend_Json
Introduction
Basic Usage
Advanced Usage of Zend_Json
XML to JSON conversion
Zend_Json_Server - JSON-RPC server
Zend_Layout
Introduction
Zend_Layout Quick Start
Zend_Layout Configuration Options
Zend_Layout Advanced Usage
Zend_Ldap
Introduction
API overview
Usage Scenarios
Tools
Object oriented access to the LDAP tree using Zend_Ldap_Node
Getting information from the LDAP server
Serializing LDAP data to and from LDIF
Zend_Loader
Loading Files and Classes Dynamically
The Autoloader
Resource Autoloaders
Loading Plugins
Zend_Locale
Introduction
Using Zend_Locale
Normalization and Localization
Working with Dates and Times
Supported locales
Zend_Log
Overview
Writers
Formatters
Filters
Using the Factory to Create a Log
Zend_Mail
Introduction
Sending via SMTP
Sending Multiple Mails per SMTP Connection
Using Different Transports
HTML E-Mail
Attachments
Adding Recipients
Controlling the MIME Boundary
Additional Headers
Character Sets
Encoding
SMTP Authentication
Securing SMTP Transport
Reading Mail Messages
Zend_Markup
Introduction
Getting Started With Zend_Markup
Zend_Markup Parsers
Zend_Markup Renderers
Zend_Measure
Introduction
Creation of Measurements
Outputting measurements
Manipulating Measurements
Types of measurements
Zend_Memory
Overview
Memory Manager
Memory Objects
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_Navigation
Introduction
Pages
Containers
Zend_Oauth
Introduction to OAuth
Zend_OpenId
Introduction
Zend_OpenId_Consumer Basics
Zend_OpenId_Provider
Zend_Paginator
Introduction
Usage
Configuration
Advanced usage
Zend_Pdf
Introduction
Creating and Loading PDF Documents
Save Changes to PDF Documents
Working with Pages
Drawing
Interactive Features
Document Info and Metadata
Zend_Pdf module usage example
Zend_ProgressBar
Zend_ProgressBar
Zend_Queue
Introduction
Example usage
Framework
Adapters
Customizing Zend_Queue
Stomp
Zend_Reflection
Introduction
Zend_Reflection Examples
Zend_Reflection Reference
Zend_Registry
Using the Registry
Zend_Rest
Introduction
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Overview
Building Indexes
Searching an Index
Query Language
Query Construction API
Character Set
Extensibility
Interoperating with Java Lucene
Advanced
Best Practices
Zend_Serializer
Introduction
Zend_Serializer_Adapter
Zend_Server
Introduction
Zend_Server_Reflection
Zend_Service
Introduction
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Amazon_Ec2
Zend_Service_Amazon_Ec2: Instances
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Machine Images (AMI)
Zend_Service_Amazon_Ec2: Elastic Block Storage (EBS)
Zend_Service_Amazon_Ec2: Elastic IP Addresses
Zend_Service_Amazon_Ec2: Keypairs
Zend_Service_Amazon_Ec2: Regions and Availability Zones
Zend_Service_Amazon_Ec2: Security Groups
Zend_Service_Amazon_S3
Zend_Service_Amazon_Sqs
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_DeveloperGarden
Zend_Service_Ebay
Zend_Service_Ebay_Finding
Zend_Service_Flickr
Zend_Service_LiveDocx
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_ShortUrl
Zend_Service_Simpy
Zend_Service_SlideShare
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Bundled Services
Zend_Service_StrikeIron: Advanced Uses
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_WindowsAzure
Zend_Service_WindowsAzure_Storage_Blob
Zend_Service_WindowsAzure_Diagnostics_Manager
Zend_Service_WindowsAzure_Storage_Queue
Zend_Service_WindowsAzure_Storage_Table
Zend_Service_Yahoo
Zend_Session
Introduction
Basic Usage
Advanced Usage
Global Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Accessor
AutoDiscovery
Zend_Tag
Introduction
Zend_Tag_Cloud
Zend_Test
Introduction
Zend_Test_PHPUnit
Zend_Test_PHPUnit_Db
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Introduction
Working with Zend_TimeSync
Zend_Tool
Using Zend_Tool On The Command Line
Extending Zend_Tool
Zend_Tool_Framework
Introduction
Using the CLI Tool
Architecture
Creating Providers to use with Zend_Tool_Framework
Shipped System Providers
Extending and Configuring Zend_Tool_Framework
Zend_Tool_Project
Introduction
Create A Project
Zend_Tool Project Providers
Zend_Tool_Project Internals
Zend_Translate
Introduction
Adapters for Zend_Translate
Using Translation Adapters
Creating source files
Additional features for translation
Plural notations for Translation
Zend_Uri
Zend_Uri
Zend_Validate
Introduction
Standard Validation Classes
Validator Chains
Writing Validators
Validation Messages
Zend_Version
Getting the Zend Framework Version
Zend_View
Introduction
Controller Scripts
View Scripts
View Helpers
Zend_View_Abstract
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Introduction
Zend_XmlRpc_Client
Zend_XmlRpc_Server
ZendX_Console_Process_Unix
ZendX_Console_Process_Unix
ZendX_JQuery
Introduction
ZendX_JQuery View Helpers
ZendX_JQuery Form Elements and Decorators
Zend Framework Requirements
Introduction
Zend Framework Migration Notes
Zend Framework 1.10
Zend Framework 1.9
Zend Framework 1.8
Zend Framework 1.7
Zend Framework 1.6
Zend Framework 1.5
Zend Framework 1.0
Zend Framework 0.9
Zend Framework 0.8
Zend Framework 0.6
Zend Framework Coding Standard for PHP
Overview
PHP File Formatting
Naming Conventions
Coding Style
Zend Framework Documentation Standard
Overview
Documentation File Formatting
Recommendations
Recommended Project Structure for Zend Framework MVC Applications
Overview
Recommended Project Directory Structure
Module Structure
Rewrite Configuration Guide
Zend Framework Performance Guide
Introduction
Class Loading
Zend_Db Performance
Internationalization (i18n) and Localization (l10n)
View Rendering
Copyright Information