Creating Forms Using Zend_FormThe Zend_Form class is used to aggregate form elements, display groups, and subforms. It can then perform the following actions on those items:
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:
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:
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 LoadersZend_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:
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. ElementsZend_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:
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:
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:
Populating and Retrieving ValuesAfter 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:
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:
On the flip side, you may want to clear a form after populating or validating it; this can be done using the reset() method:
Global OperationsOccasionally 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:
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:
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: 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:
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: Methods For Interacting With ElementsThe following methods may be used to interact with elements:
Display GroupsDisplay 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 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: You can access display groups using the getDisplayGroup() method, or via overloading using the display group's name:
Global OperationsJust 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.
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):
Using Custom Display Group ClassesBy 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: 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:
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 GroupsThe following methods may be used to interact with display groups:
Zend_Form_DisplayGroup MethodsZend_Form_DisplayGroup has the following methods, grouped by type:
Sub FormsSub 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:
You can retrieve a sub form using either getSubForm($name) or overloading using the sub form name:
Sub forms are included in form iteration, although the elements they contain are not. Global OperationsLike 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):
Methods for Interacting With Sub FormsThe following methods may be used to interact with sub forms:
Metadata and AttributesWhile 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:
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:
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.
Zend_Form implements the Countable interface, allowing you to pass it as an argument to count: 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.
DecoratorsCreating 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: This creates output like the following:
Any attributes set on the form object will be used as HTML attributes of the <form> tag.
You may create your own decorators for generating the form. One common use case is if you know the exact HTML you wish to use; your decorator could create the exact HTML and simply return it, potentially using the decorators from individual elements or display groups. The following methods may be used to interact with decorators:
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: If the decorator does not exist, an exception is raised. ValidationA 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:
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):
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:
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:
You can retrieve codes and error messages for individual elements by simply passing the element name to each:
Custom Error MessagesAt 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.
All errors set in this fashion may be translated. Retrieving Valid Values OnlyThere 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:
MethodsThe following is a full list of methods available to Zend_Form, grouped by type:
ConfigurationZend_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:
As an example, here is a config file that passes configuration for every type of configurable data:
The above could easily be abstracted to an XML or PHP array-based configuration file. Custom formsAn 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:
This form can then be instantiated with simply:
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:
|
|