PHP5

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:

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

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.

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:

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

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:

<?php
// 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:

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

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

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

<?php
$form->setDefaults($data);
$form->populate($data);
?>

15.4.2.2. 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:

Пример 15.2. Setting Prefix Paths for All Elements

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

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

Пример 15.3. 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:

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

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 label, errors, and hint from being rendered; the example above would duplicate some content (the label). So, use this method wisely, and realize that you may need to manually change some elements' decorators to prevent unwanted output.

Пример 15.4. 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:

<?php
$form->setElementFilters(array('StringTrim'));
?>

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:

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

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

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

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

	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: <?php $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.

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

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

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

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

Sub forms serve several purposes:

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:

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

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

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

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

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

<?php
$form->setSubFormsDecorators(array(
    'FormElements',
    'Fieldset'
));
?>

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:

<?php
// 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:

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

	Замечание
	The method and action 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:

<?php
$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.

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

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:

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

This creates output like the following:

<form action="/form/action" method="post">
<dl>
...
</dl>
</form>

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

	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: <?php $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.

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: <?php // 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: <?php // 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:

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:

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

<?php
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:

<?php
$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:

<?php
$codes = $form->getErrors();
$messages = $form->getMessage();
?>

	Замечание
	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:

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

Замечание

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.

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

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:

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

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"
?>

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

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

The most typical use case would be to use the init() method to setup specific form elements and configuration:

<?php 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('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'
        ));
    }
}
?>

This form can then be instantiated with simply:

<?php
$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:

<?php class My_Form_Login extends Zend_Form
{
    public function loadDefaultDecorators()
    {
        $this->setDecorators(array(
            'FormElements',
            'Fieldset',
            'Form'
        ));
    }
}