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.
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 isNULL
, 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 likeaddPrefixPath()
, you must specify a class prefix and a path.$type
, when specified, must be one of the plugin loader types specified byZend_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 likeaddPrefixPath()
, 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.
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:'));
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');
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();
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:
Przykład 442. 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');
Przykład 443. 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' ));
Przykład 444. 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 );
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.
Przykład 445. 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'));
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 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;
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.
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.
Przykład 446. 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');
Przykład 447. 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' ));
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.
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
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 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.
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' ));
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)
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);
Uwaga
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();
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:
<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:
$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:
// 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("<p>This is fieldset content</p>");
If the decorator does not exist, an exception is raised.
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();
Uwaga
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');
Uwaga
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.
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.
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);
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()
-
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.
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' )); } }