Hi,

I am Bharadwaj, final year student at the Indian Institute of Technology, Madras. I have been using dojo for the past 4 months on a project for the front end of a business system software, and I have found answers for almost all of my UI requirements within dojo; hats off to you guys. This post contains my idea for the GSoC 2008 for dojo.

I am interested in contributing to the dojo project as a part of GSoC. In particular, I would like to work on a problem that I faced during the development of the front end in the project I mentioned before. This required dynamically generated forms based on certain criteria. My idea therefore is to draw up a JSON representation of a form that needs to be displayed to the user, and have it parsed by a form generator, existing as a part of dojo, to dynamically create the required form elements at the respective places with the intended functionality.

For example, consider a page for creating a profile with different form elements such as a textbox, a radio button etc. Now, for editing the profile, we require the same form, but with the addition of the different form element being already set. In other cases, there may be a few elements which are not editable, but need to be visible. Or, maybe, we want to hold the same profile form, but with an additional few elements for user with higher privileges. Or, finally, there might be two totally different forms, both of which, however, relate to profile creation.

What we see here is a variation of a common theme. It would be a terrible waste to duplicate the functionality in order to reflect the small variations in an otherwise single unit. If, in this particular example, there was a way of collecting all these variations in functionality in a consistent manner and implementing these changes into a common baseline HTML markup using dojo, then it would reduce the unnecessary duplication described above.

The idea I have just described has the following advantages:

1.The server is free to specify the form elements and functionality required from the page, independent of the layout of the page. All the server needs to provide is a JSON representation of the form elements that need to be present, along with their intended behavior. It is up to the form generator to create plain-vanilla or dijit form elements and place them in the appropriate locations with the intended functionality.

2.Since the JSON representation is available in the browser, it can be modified to reflect any changes to a form’s design and immediately refreshed to visualize the changes, without requiring any trip to the server or any fancy DOM manipulation. An immediate application of this capability would be in a dojo IDE. Another possible application could be in a situation where the number of form elements required is unknown, and is set by the user.

3.As mentioned earlier, small variations to an otherwise uniform form is captured in the JSON representation, thereby allowing for these variations come under a single logical unit.

The dojo toolkit provides various enhanced form elements which incorporate features that go beyond plain-vanilla form elements – in particular, validation and event handling. Furthermore, there are complex elements which are not a part of the traditional form element set – such as Trees and Grids. Since the Form Generator will be a part of dojo itself, the generation of the form will be a simple matter of making use of these existing form elements and constructing the form required. However, before this can be done, it is necessary to come up with a JSON representation of the possible complexities in a form which can eventually be used by the Form Generator to generate any form. This would be similar to constructing a Tree from a JSON representation of a tree. Taking the Tree analogy further, it might also be possible to construct subforms within forms which communicate a subset of the user’s input to the server without the parent form being submitted in it entirety (think country-state-city drop down boxes), and yet forms a part of the whole parent form.

Furthermore, validation parameters can be specified in the JSON representation and can be converted into the corresponding dojo validation attributes, which would result in automated validation for the corresponding form elements. Also, we can allow for a form to have its elements in different sections of the same page (say a textbox in a left column, a radio in a right column and a submit button in the center) and still function as a coherent whole – thereby allowing for the layout of the form to be completely separate from the functionality or organization of the form. This adds a lot of flexibility for both the developer and the user in designing the forms. Finally, submission of the forms can also be handled by the dojo AJAX methods or, if the user requires, in the traditional fashion.

This is a rough overview of the idea I have come up with. I am in the process of preparing a small example of how I would go about doing this for, say, two or three widgets as a part of the full proposal. I would like to know your suggestions and ideas regarding this so that the idea can be fine-tuned.

Thanks in advance for your contributions.

Bharadwaj