Day 3 - Session 5 - Zend_Form

OK, You'll probably (or not) notice I skipped Session 4... I was actually present during it, but mentally it wasn't challenging or really anything worth noting.

Matthew Weier O'Phinney is giving a speech on Zend_Form, and if we're lucky Zend_Layout.

DOH! We're NOT lucky apparently.

LOL, and NO talk about Dojo.

The Problem (and the solution):
The downsides (problems):

• A form is HTML markup, with input filtering (sanitization and validation), error reporting.
• Even though forms can look simple, the markup isn't really all that simple.
• You also have to do your own validation, and other logic that mucks up your code. Not to mention it's not standardized.
  
• Even though ZF has validators and filter chains, it's still a lot of work.
• Your tests are specific to the input [types].
• Repetition of code.
  

The upsides (you guessed it, solutions):

• Enter Zend_Form.
• Completely configurable!
• Multiple filters
• Multiple Validators
• Required
• Labels
• Pass the form right to the view, and echo the object for the entire form (say it with me, "One Line of Code").
• Automatic errors for validation and required elements.
• i18n is easy to localize!!!
• Decorators!
• Break forms into logical groups.

Base classes:

• Forms
• Elements
• Display Groups
• Sub Forms

Plugins:

• Filters
• Validators
• Decorators
• Elements; you can create custom elements (like a calendar element or something)

Zend_Form_Element:
These store and manipulate element metadata, validator chains, filter chains, and decorators.
There are tons of element types for your typical form-based input types (i.e., checkbox, captcha, select, etc).
Elements are plugins, and loaded by Zend_Form AS plugins, so you can overload their functionality.

But makes an element?

• Metadata - stored as properties of the element, via overloading; anything that can qualify an element. Typically, it's used for rendering, such as with CSS classes or JS events, explicit IDs, or any other HTML attributes.
• Filters - normalizing input prior to validation (such as proper casing, etc). They attach to elements using addFilter[s](), setFilters(). You can even use Zend_Form::setElementFilters() to filter all elements.
• Validators - much like Filters, but (obviously) validate.
• Decorators - ditto of Validators

Another cool thing about elements, is you can specify order format. The default action is to set the order based on how it's added to the form.

Zend_Form_DisplayGroup:
These are for visually grouping elements when rendering.

Zend_Form_SubForm:
This is for grouping items together LOGICALLY. Usually for validation purposes, but can also be used for display purposes if desired.

When to use them?

• Multi-page forms are a good example of why to use them.
• Dynamic forms as well (multiple records of the same type).

Plugins:
You can specify alternate class prefixes to load new plugins, or overload existing plugins.
Filter plugins allow you to normalize or filter input, which you create your own kinds of. Many already exist for Alpha, digits, StripTags, etc.
Validators as well are nice in the plugin section so that you can make sure the user input meets your input criteria, such as EmailAddress, StringLength, etc.

Decorators:
These are difficult to understand, but can be very powerful.
Each decorator decorates the content passed to it, and iteravely you get your finalized output.
Each decorator also has awareness of the element/form/etc. When building a decorator, you can pull pertinent info and de specific things you want.

• Callback - delegate to a specified [sic] valid PHP callback
  
• Description - render from getDescription()
  
• Errors - render from getMessages
  
• Fieldset - puts in a legend if necessary, and wraps in a fieldset
  
• FormElements - Iterate through elements, groups and subforms
• Form - wrap into an HTML form
  
• HtmlTag - wraps in specified HTML tag (default
  )
  
• Label - render from getLabel() (default
  )
  
• ViewHelper - render using a view helper
  
• ViewScript - render using a view script

-- Italicized decorators are default for elements.

Form validation:

• isValid() = validate entire form (except optional fields which can be empty)
• isValidPartial() - validate fields submitted
• getErrors() - return fields with errors
• getMessages() - return error messages

Personal Thoughts:
A lot of these elements work almost identical, considering they're all plugins to Zend_Form.
Good talk.. good talk...