Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

This page details information about how the HTML Form Entry Designer will be designed to work, as well as the architecture to support it.

Design Problems

  • The Designer should automatically integrate with the HTML Form Entry module, in order to provide default controls for new functionality.
  • The Designer should provide custom behavior for special use cases, in order to improve the user experience on common tasks of HTML Form Entry.
  • The Designer should provide WYSIWYG editing of the HTML Form Entry code

UI Mockups (Workflow)

1. HTML Form Entry Designer

The HTML Form Entry Designer module replaces the Textarea for entering a HTML Form with a customized version of the CKEditor WYSIWYG editor. This editor provides functionality for visually editing HTML tags, as well as the special tags supported by the HTML Form Entry module:

The user has palette of the most common elements, for fast entry (1). Alternately, it can choose to open the Add Element dialog (2), which shows all available elements provided by the designer.

2. Add Element Dialog

This dialog presents the user different elements (tools) to help the user build their HTML Forms. There are 2 types of tools:

  • Default tools, with default behavior, generated automatically for each TagHandler on the HTML Form Entry module
  • Custom tools, with custom behavior, defined in the designer. These tools improve the user experience by offering personalized dialogs for specific use cases.

Here's a mockup of how the Add Element Dialog should look like:

This dialog groups the various UI Elements into different sections. For each element, it's name and description are shown, and when the user clicks on one of them a dialog is shown, in order for the user to enter further attributes.

3. Element Attributes Dialog

Each element can specify how the dialog is rendered and how to process the user input. After processing the user input, this dialog should return a string of XML code, that should be entered in the editor. A simple scenario is the Encounter Date dialog. Basically, the designer would recognize the EncounterDateTagHandler from HTML Form Entry module and fetch their attributes, to generate the XML code:

This would generate a <encounterDate> </encounterDate> tag (or <encounterDate default="$VALUE" showTime="$VALUE" /> depending on the user input). It would also show a HTML Preview of that tag.

A custom dialog could be created by changing the attributes section in this dialog and by changing how the XML code is generated. For instance, for another simple case, where we want to add a simple label to the Encounter Date, the dialog could be customized to look like this:

This would also generate a custom XML code, for instance: <span class="label">Encounter Date: </span> <encounterDate />

By clicking on the Add button, the XML code would be inserted into the editor.

Architecture

This section details the architecture to support this design.

HTML Form Entry module

The HTML Form Entry module must be expanded in order to provide additional metadata, so the designer can "guess" what new features done in this module (tags) do automatically. The changes are trivial, in order to cause minimum impact.

TagHandler

  • Name
  • Description
  • AllowNested - true or false, basically allows for inserting other elements inside. For instance <obs> tags won't allow to insert elements inside, but <section> tag will.

AttributeDescriptor

  • Name - identifier
  • Label - to be shown on the add tag dialog (see section 2)
  • Required - true/false, if the attribute is required
  • Datatype - boolean would render a checkbox. Text would be a simple textbox. More can be specified in the future.
  • No labels