burkeware.com

After clicking on the create GroovyForm link, the user would be presented with a form looking something like this:

You can reset the form if you like. NOTE: the Update GroovyForm button is for illustration and doesn’t do anything on this page.

The user lists out some “fields” or “items” they want on their form within a simple Groovy class construct. While a wizard can help with this in future versions, access to the class construct allows for custom behavior to be added to the form’s model by adding Groovy methods to this class.

We interrogate the class and generate a view and controller for them, allowing the user to modify these as needed (clean up or rearrange the layout in the view and add some API calls to the controller). The only data needed within the form model are those bits of information needed to make a successful API call within the controller. In the example above, the “createObs” method is fake, but the idea is that the “NOTE” concept would be hardcoded into the controller, so the end-user only needs to pick a patient, type a note, and submit the Groovy form to begin adding notes to the system.

The preview behavior is just for demonstration purposes here, but we would want some way of allowing the user to preview their work as they make changes. Eventually (in a later version), you could imagine that the view could be a WYSIWYG editor.

The first pass would be to simply support the traditional validate-on-submit pattern, where the user completes the entire form and submits before receiving any validation errors. In subsequent versions, we could consider adding AJAX hooks to provide inline errors and more immediate feedback to the user.