Since W3C published its HTML5 specs in January 2008 many browsers have started their implementation of the improved XML structure and its new attributes. But what does this mean and how can we as developers benefit from all this on a form level? This talk is about implementing HTML5 specific tags in your forms created with Zend_Form.
New features HTML5 for forms and validation
First of all to clarify the meaning of all these new goodies, we first look at what’s available. HTML4 had a few different input elements that could be added to your form : text, password, hidden, checkboxes etc. HTML5 brings even more types that can be added to your <input> tag. For instance:
- Date pickers (date, month, week, time, datetime, datetime-local)
Besides the new input-types, HTML5 also provides some other tags that are interessing when dealing with our forms:
“Currently, the browser support for this element is not good enough to be a useful security standard.”
The last element that is new is the output element, which well does nothing except that it is reserved for output. It’s just a container for different types of output, like calculations or script output.
That’s about it on the introduction to HTML5 and forms. Let’s proceed to the awesome part!
Applying HTML5 to your Zend_Form
(Note: all code can be found on GitHub)
Basically all that we need is an extended Zend_Form_Element_Text and some view helpers that do the rendering. In this case I’ve used Glitch as the namespace for the classes.
As you can see I’ve provided a basic set of key value pairs that are represented by constants to deliver the basics. Further down the I’ve used the constructor to decide to get the type of the element based on the name of the element if the type key is not given in the options argument. The type of the element points directly to the “type” attribute of the element. I’ve made the _getType method to map the element name to its matching type attribute. So far nothing exceptional, just some matching of keys and returning their values. As a treat I’ve build in get/set methods that allows us to disable automated filters and validators for our new elements. Next up is the actual element and for this example lets use the number field where I’ve implemented automated filters and validation based on the settings given to the element upon constructing it.
The init() method does a check for the attributes that are used in HTML5 (see specs) for the number type and adds a logical validator to the element. In this case the min and max attributes are used.
Now let’s take a crack at a view helper for the new types (yes, just 1 view helper!)
Now let’s build our form and add all the new elements.
As you can see, nothing special going on. With the small exception of the range and number fields where we have provided specs for the attributes and more important, specs for our server sided validation. For the range element I’ve disabled the automated filtering and validation with the keys ‘autoloadValidators’ and ‘autoloadValidators’ set to false.
(Note the onforminput attribute on the output element, there is code for that in the view layer)
The datalist, output and keygen elements do require some more code as they rely on their own new view helpers which renders the right tags but this is nothing you should be worried about as it all included in the download package.
So now that we have our HTML5 form filled with elements and just 1 step away from yes, RESULT! Paste this in your view
Now to see the new form in all its glory I recommend Opera for viewing the beauty of your newly generated elements and take it for a test run. (Opera has the best support for the new input types)
(Reminder: there is client sided validation but that does not take away that you still are responsible for the data that comes in! Read: write your own validation chain.)
Now let’s see what happens when we don’t want the (still experimental) HTML5 elements. Just replace this code in your application.ini:
resources.view.doctype = "HTML5" with
resources.view.doctype = "XHTML1_STRICT"
Now refresh your page and see how everything just falls back to input elements with the attribute text instead of the funky HTML5 attributes.
One of the great joys (for me at least) of working with Zend and specific Zend_Form and Zend_Form_Element is that it so extendible!
With a few classes of your own you can create almost any kind of element you want, it’s all up to your imagination.
I hope that you will agree that we extend to support the future 😉
All code can be found on GitHub