See also: DesignConsiderations

Current Implementation

The current form mechanism is our own created solution. It is possible to create .far bundles that provide a form implementation. The form implementation gives a wicket based form based on an XML definition.

This definition contains the datamodel (xml based) that is used to store the form instance data for the patient. The instance data is stored in the xml database side of the Patient storage services.

Forms Design Considerations

The investigated alternatives are:

  • XForms
  • QTI
  • Build ourselves

Thoughts

XForms

  • + XForms is very complete, it can probably support everything we need.
  • + There are multiple
  • - XForms is ugly, it mixes data definition, form logic and layout.
  • - XForms, given some complexity are hard to write, and like in the old JSP day, hard to keep consistent.
  • + XForms has multiple complete implementations (Orbeon and Chiba).
  • - Both Orbeon and Chiba are hard to embed in another site. They both need their own servlet to handle ajax calls. Not sure how you do markup things.

QTI

  • - QTI is a standard targeted towards representing exam questions. Although it is very rich, its focus makes it less suitable for form applications.

Building ourselves

  • + 'Building ourselves' gives exactly what we need. We can separate data definition, form logic and form layout. In addition we can probably create form editors that are usable by medical personal (if this is a requirement anyway).
  • 'Building ourselves' will cost some time which (for the first iteration) needs to be weighted against learning XForms. For the longer term I can not predict which will cost more.