Home

h1. jzForm: A form builder for dynamic data acquisition – Initial Release

I am pleased to formally announce that a project I have been working on for the last couple of weeks is now getting its first official release. JZForms is a framework agnostic library for describing data that an application need to acquire from the user. In particular, this library targets web applications that use forms for data acquisition.

This is a first release and the library is not production ready. I am releasing under the theory of release early, release often with the hope that other who might find this project interesting will contribute to it. For a more complete description please read on.

There are a number of projects that target the design and construction of forms. Most fall into two categories: 1) Developer tools and 2) Scaffold builders. The first depend on the developer to understand what data is needed help him or her to create a form that will best acquire that data from the user. The second make assumptions about what data to acquire based on the properties of a model class. Neither of these solutions is satisfying. One requires a designer to keep views and models aligned, does not easily lend itself to dynamic modification of the form by the model. The other makes an invalid assumption that the structure of the model is synomous with with data is needed. Usually that structure lacks sufficient inspectable information to create a user friendly form, and also requires that the form exactly match the fields in the model.

As the model space of an application becomes more dynamic and complex, the logic of form creation and representation get spread further and further throughout the code. The goal of jzForm is to consolidate all the logic of form creation into a single library. In particular, the aim is to seperate the content of the form (a descreption of what data is needed) from the presentation (a well structured (x)html form). The model knows what data it need to get from the user. The view knows how to display requests for data to the user. JzForms act a a bridge between the model and view layers. The view no longer has to guess what data to ask for by inspecting the internal structure of a model nor does it rely on programmer time to repeatedly construct forms for every circumstance.

JZForm has 3 related pieces: a platform agnostic language for describing what kind of data the application would like, a template system in Ruby and eventually JavaScript that will turn these descriptions into forms for a user, and a data validation system that takes care of sanitizing the data so that the data the application gets back is always what it asked for.

A typical use case might look like this:
A request comes in to a web application to add a new cog to a widget.
The controller find the widget instance in question and asked what data it needs to add a cog
The widget model uses data about the instance as well as other global data to decide what kind of cog can be added and uses jzForm to describe the choice the user has regarding their new cog.
The controller passes this jzForm instance on to the view which renders it onto a html page, or embeds the form as JSON and uses javascript to dynamically create the form.
The user fills out the form and returns it to the server.
Before the form is submitted, the browser can use the JSON representation of the form to ensure that all the data is acceptable
Once back at the controller, the data can be checked by the using its internal copy of the the jzForm. String data is converted into booleans, integers, real numbers and arrays, and the data is passed on to the model.
If the controller finds that the returned data is not acceptable it can rerender the jzForm view and the new view will automatically include error messages.
Once the model gets the jzForm, it can extract data that is known to match the request and be safe for further use in the application. It uses that data to create a new cog and associate it with the widget instance.

Some things to note:
Validation can happen at every level and invalid entries can be flagged quickly and with as few resources as possible. Only valid data is returned by a jzForm ensuring that the back end never sees data it was not expecting, a significant source of bugs and security vonerabilities.
The Model can describe what data it needs without needing to know how or where it will be displayed.
If the information that is needed to create a new cog changes either because of a design decision or because the widget has changed, there is no need to redesign the form or put lots of logic in view helpers.
No one had to guess what types of data was needed or what format it was going to be in.
jzForms are machine readable therefore part or all of the form can be filled out either by the server or the client’s machine.

At the moment not all of this is working. There has not been any work done with javascritp yet, and the template shipped with jzFrom is primitive at best. Validation is in its infancy. The code needs cleanup and documenting. I could also really use help refining the structure of a jzForm and smoothing out the interface. If anyone can thing of a better name I’m all ears. All help and feed back is appreciated.

I am driving development of jzForm based on what I need in AntaresTrader. Near term I am looking at pushing validations beyond rudimentary, getting subforms and multi-part forms working, and working with the JavaScript render/validater. You can follow development on github or twitter.