Planet SoC

No, not the cleaning product! The “Web 2.0” kind of AJAX! Now where will this goodness be placed? The pages for creating the forms and managing the forms.

First off, I used Direct Web Remoting (DWR) to provide a link between my backend java codebase and the front-end javascript! It’s quite amazing. You can choose to publish/unpublish the forms with the tick of a checkbox and DWR will magically set the published attribute on the form to the proper state. I then decided to go one step furthur, and provide a mechanism to backup the forms via xstream to XML. Now, with the XML files, two files are maintained, one individual XML file for each form, and one global one, which makes up the model for the entire system. The rationale for having the XML file for each form is that you can just zip up the form folder, and unzip it into another OpenMRS install and you’re good to go. Adding the ability to re-generate the XML files via the management interface is especially handle so that if you make a quick change on one system, then want to install it onto another you can.

Now, DWR will be used for creating the forms as well. This will be done mostly to easily relay errors, such as syntax errors in the Controller and the Model of the groovy form. Don’t fear, I’m going to go overboard with AJAX! It’ll only be used up until the point of where templates are generated. After that point, a Servlet will take over the bulk of the work (I am undecided on the Servlet bit.).

Now what’s next? Several things need to happen.

First, creating the form:

1. We need to validate that form fields are not empty; also the input must be checked for validity.
2. The model’s syntax needs to be compiled and syntax errors need to be relayed to the user.
3. We need to get the fields of the class and store them.
4. We need to generate templates like: <%= textArea(…); %> — They will not be run it through the template engine immediately until the user has confirmed what they want,
5. After the view has been tweaked — it is run through the template engine; at this point we will also run the controller through and generate that and present it at the same time the final view is presented.
6. The user will be presented with the HTML of the view and Groovy controller and given a final opportunity to tweak it before it is saved to the system.
7. The form is added to the system — by default the form is not published.
8. Finally, to publish the form so that it can be used to enter data, they go to the management screen and tick the checkbox.
9. The form is now ready to be used for data entry.

Pictures are worth a thousand words so here we go: One and Two.

First one contains one form which is published, the rest are not. The second, no forms are published.

The user interface is intuitive and easy to use. It’s a great design, of course I’m biased since It was was me who designed it.