HTML5 forms in Zend Framework
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:
- url
- number
- range
- Date pickers (date, month, week, time, datetime, datetime-local)
- search
- color
The email attribute to start with isn’t much of a help in a basic browser that runs on your pc/laptop. It is handy though on a mobile platform as the keyboard changes to a type where the @ sign is not tucked away in some dark corner. The one major advantage in browsers that support this new feature is that they trigger a validation process (client sided!). No more tedious javascripting of your own to pre-validate email addresses. The same goes for the other fields. Each input type triggers a certain validation (which, unfortunately, is browser dependent!) so the user is aware of what is expected.
Besides the new input-types, HTML5 also provides some other tags that are interessing when dealing with our forms:
- datalist
- keygen
- output
I won’t go into detail on these elements but I have them prepared in the codebase. First the datalist is a mixture of the input and select elements. With “basic” HTML it required some javascript to generate such a feature and even then it wasn’t flawless. The keygen is a client sided keygen generator for authentication purposes. I’ve tested it with Firefox 3.6.10 and Opera 10.60 and both generate a bit of a different element with different results. I quote from the w3schools site: “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.
An example:
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
These lines render the entire form and add some javascript code to calculate the sum of the 2 form input fields.
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.
Conclusion
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
Recommend on Facebook- Buzz it up
- Share on Linkedin
- Tweet about it
- Tell a friend
About David Papadogiannakis
David is begonnen als stagiair bij 4worx en is daardoor in het bedrijf gegroeid en door het bedrijf gevormd. Het is een harde werker die met passie zijn positie als (Zend Framework) developer bezet en daardoor elke opdracht als een persoonlijke uitdaging beschouwd.
16 Responses to HTML5 forms in Zend Framework
I can’t get your solution to work. I have set the doctype to HTML5, and it shows as such in my final html output, however, none of the elements are coming out as HTML5 elements, instead they are coming out as input type=text.
Elements.php
public function getColorField(){
$element = new Glitch_Form_Element_Text_Color(‘color’);
return $element;
}
Form.php
public function getColorForm(){
$form = new Zend_Form();
$form->setAction(”);
require ‘Element.php’;
$element = new Element();
$form->addElement($element->getColorField());
return $form;
}
SomeController.php
$this->view-form = $colorForm;
the view script
echo $this->form;
result
Help?
*the result is
input type=”text” name=”orderdate” id=”orderdate” value=”"
(the blog blocked this )
Based on the information given, I would say that your application is not aware that it should also look for view helpers in the Glitch namespace.
Could you try the following things to see if you get any result.
If you are using resources based config
resources.view.helperPath.Glitch_View_Helper = "Glitch/View/Helper/"
Else the following should work in your controller:
$this->view->addHelperPath('/Glitch/View/Helper', 'Glitch_View_Helper_');
Or more general to be called from anywhere
Zend_Layout::getMvcInstance()->getView()->addHelperPath('/Glitch/View/Helper', 'Glitch_View_Helper_');
Also make sure that your doctype view helper is set to HTML5 else the Glitch_Form_Element_Text and the Gltich_View_Helper_FormText will ignore all new types and by default fall back to text.
Let me know if the above suggestions worked out for you.
Thanks so much for your quick reply!
I added the Glitch namespace to my Bootstrap like this:
protected function _iniAutoload(){
$autoLoader = Zend_Loader_Autoloader::getInstance();
$autoLoader->registerNamespace(‘Glitch_’);
$resourceLoader = new Zend_Loader_Autoloader_Resource(array(
‘basePath’ => APPLICATION_PATH . ‘library/’,
‘namespace’ => ‘Glitch’
)
);
$resourceLoader->addResourceType(‘form’,'Form’,'Form’)
->addResourceType(‘element’,'Form/Element’,'Element’)
->addResourceType(‘text’,'Form/Element/Text’,'Text’)
->addResourceType(‘view’,'View’,'View’)
->addResourceType(‘helper’,'View/Helper’,'Helper’);
return $autoLoader;
}
When I delete this code I get an error that Glitch-yada-yada cannot be found.
Also, I echo $this->doctype()->isHTML5(); in my View and it returns 1
After reading your suggestions, I tried them anyway and it still does not work.
Also, I’m using ZendFramework 1.11
I resorted to
$element->setAttrib(“type”,”date”);
Easy solution.
Thanks for your help!
Might be an easy solution but not really the way you want to go. Now you have to add that piece of code to every kind of element you want. And you’ll have to change that piece of code for every element once you switch from HTML5 back to something older.
Did none of the 3 suggestions I gave work for you?
Could you provide me with the error message you got with the code you posted?
I agree with you there, my solution isn’t the best, but it’s working…
I’m not getting an error, I wish I was! I used Zend_Debug::dump($text) inside of FormText.php and no matter what I do it always returns “text”.
I can tell that your helper is being called because the Zend_Debug tool is giving an output.
I know it isn’t working because my html renders all HTML5 inputs as ‘input type=text’ as opposed to type=date, type=color, and etc.
I also noticed that your view helpers work with regular Zend_Form_Element. So what I’m doing now is:
$element=new Zend_Form_Element(‘datepicker’);
$element->setAttrib(‘type’,'date’);
//validators
//filters
//decorators
return $element;
then in my Controller I add:
$this->view->addHelperPath(‘Glitch/View/Helper’, ‘Glitch_View_Helper_’);
which works.
If I were to make a guess, I’d say that none of the Glitch_Form_Element_ elements are passing their type attributes to the viewer, which may be way setting them manually is working.
Also, another weird thing happens with Glitch_Form_Element_Text_Number, this element echoes “array{0}” on the screen for every instance of itself. I’m not sure if these problems are related, but I was going to ask you about this later.
Could you provide me with a sample code of that? I can’t seem to reproduce the problem you are describing.
As for setting the helper that is done in Glitch_Form_Element_Text based on their name if the option ‘type’ is not given. Maybe I’ll change this to being set by the elements instead of setting it magicly.
I had a few problems getting this to work.
I tried addHelperPath in both my bootstrap and controller and neither worked. I got the following error message: Fatal error: Class ‘Glitch_Form_Element_Text_Email’
I then added registerNamespace(‘Glitch_’) to my bootstrap and received the following error message: Warning: include_once(Glitch\Form\Element\Text\Email.php) [function.include-once]: failed to open stream: No such file or directory
As this path is different to the one in your library, I moved the Glitch/Form/Text directory to Glitch/Form/Element/Text and this has resolved the problem.
Am I doing something wrong or is your directory structure in the library wrong?
Hi Polo,
yeah it seems to be missing the Element sub directory.
Thanks for the notification!
No problem.
Is it right that I needed to add registerNamespace(‘Glitch_’) in my bootstrap or have I done something wrong?
Thanks for the plugin btw, it’s great! :-)
Pingback: Zend Framework HTML5 Form Elements « Moose Droppings
Pingback: Zend Framework HTML5 Form Elements | Moose Droppings
Thanks for this library-it’s working great for me. One thing that would improve it for me though would be if the view helper would automatically add the ‘required’ attribute if the element has been marked as required. I’ve sent you a pull request on GitHub with code that I think will achieve this.