- Retrieving data from the form and creating flat or nested objects according to the form element’s naming. For the mapping of form element’s names and the object’s properties refer to the Documentation.
The creation of this plugin seemed to be necessary since except some new html5 form elements there is nearly no progress in the native implementation of forms for the last twenty years and it is a boring and sometimes complicated job to implement some up-to-date capabilities by hand every time you want to create a good form.
In this article I want to talk a little bit about my motivation to create this plugin and the basic concept behind it rather than showing examples or details of the plugin’s API. Please refer to “Documentation” and “Examples” for these topics.
So the basic thing is:
Creating forms sucks!
And the basic question is:
What makes creating forms suck?
To get aware of this it is a good idea to identify the most wanted requirements that a form should be able to handle.
I think these requirements are:
- Submitting forms with no page reload.
- Keeping track of modifications / modification-states of the form and it’s form elements.
- Keeping track of valid-states of the form and it’s form elements.
- Adding notifications to get informed whenever something interesting happens with the form.
So let us walk through these two issues:
var firstname = document.getElementById("firstname").value;
As a first rule of thumb it can be said that whenever you have more than one form element that belong to a single property than the value is a complex one. But this is much too simple and is not true for a set of radio buttons that consists of multiple form elements but generates only one primitive value. It is also not true for select boxes with attribute multiple=”multiple” as this is only one form element that generates a complex value. So you cannot identify primitive or complex values just by counting the number of corresponding form elements. You definitely have to take some more properties of the involved form elements into account.
You want to assign and retrieve values to and from properties!
When you are dealing with nested object structures the naming syntax convention for the form element’s names follows the concept of mapping form element values to variables or object’s properties in php. This is a very common backend for websites and the concept is very reasonable and intuitive. You will find more information on this topic in the Documentation and the Examples.
2. Adding notifications to get informed whenever something interesting happens with the form
To give the user a good experience while dealing with your form you might want to give him information about the state of the form. For example it might be a good idea to let the user know if the form contains only saved data or if some data is unsaved. This can especially be very helpful when the user edits a data set rather than creating a new one because then all fields might contain some data and it is not obvious which field he already has touched. Furthermore you probably want the user to be informed if the data he sent to the server is valid or not. To do so the form must process the server-response, identify the fields with rejected values and generate a visual output.
So what you want is notification from the form. As we all know html form elements do fire some events on certain actions. There is for example a “change” event that fires when the content of a form field changes. That works fine but it turns out that on text field or textarea it only fires when the element loses focus after having been edited. That is not very intuitive. I would say a change should occur immediately when the user changes the content of such a field what means it should fire on “keydown”. Ok, this is not the whole truth as there are keydowns that do not change the content of a text field as “shift”, “command”, “control” etc. In addition technically the content of a form element is still unchanged at the time of the keydown but changes immediately after that event is fired. For this reason modern browsers have an “input” event implemented that does all we expect from such kind of event. For the not so modern browsers we can work around with a “keyup” event that does not fire as immediately as the “keydown” event but allows to detect if something happened with the content of the form element’s value.
So, no matter if you only use a small functionality of uicForm3 or if you make heavy use of if, this plugIn will do nothing more then extending your form with up-to-date capabilities.
This approach ensures that uicForm3 is compatible with all needs and all kind of forms no matter how complex or sophisticated your html structure is and it allows you to realize any behavior of your form you can imagine even if it is not covered by uicForm3 because this plugin does not prevent you to extend your native form in any way you want.
Please have a look at the examples and read the API documentation if you like to use this plugin. I am sure that it can do even more for you as you think about it after having read this article. I would love to get your feedback and see some forms that you created using uicForm3.