Navigation:  Managing Forms >

Form Definitions

Previous page Next page
  rev. 26/03/2009        

A major criteria in choosing a format for form definitions was that it be easy for users to develop forms while at the same time not limiting what the user can do.

Survey Form Structure

In attempting to meet these goals a common form structure was defined. Identified within this structure are the basic building blocks which all forms must utilize. All survey form definitions must contain one form element.

Form

<?xml version="1.0"?>

<form id="ChairForm" name="My Chair Survey Form">

</form>

Each form element must contain an id attribute which uniquely identifies the survey form from those that already exist. In addition, we can also give a name to the form by specifying the name attribute. In the previous example it was decided the form should be called “My Chair Survey Form”.

Form Description

In addition form elements may contain a description which provides the user with additional information about the survey form. Expanding on the previous example and adding a description to the form results in the following.

 

<?xml version="1.0"?>

<form id="ChairForm" name="My Chair Survey Form">

<description>A survey form to collect information on chairs.</description>

</form>

Sections

Within each form are sections. In most cases the survey form will contain just one section. However, sections can be used to break a form up into logical parts. For example a survey form which collects information on a building envelope might contain one section for doors, one section for windows, and finally one section for roof and exterior walls intersections.

In regards to the sample chair survey form one section should suffice. Building on the chair form example and adding a section results in the following.

 

<?xml version="1.0"?>

<form id="ChairForm" name="My New Chair Survey Form">

 <description>A survey form to collect information on chairs.</description>

<sections>

  <section id="main" name="Chair Details">      

  </section>    

</sections>

</form>

Section Description

The section element can also contain a description to provide users with additional information about that specific section. Here is the updated example with a description added to the section.

 

<?xml version="1.0"?>

<form id="ChairForm" name="My New Chair Survey Form">

 <description>A survey form to collect information on chairs.</description>

 <sections>

   <section id="main" name="Chair Details">

    <description>A section for chair details.</description>

   </section>  

 </sections>

</form>

Section Content

Now that a section has been created, it is now time to define the section content. In collecting data on chairs we might for example identify areas of interest, such as the chair location, manufacturer, warranty details, features and so on. These areas of interest typically represent groups of fields that would appear on the form. We can define these logical divisions within the section as group elements.

 

<?xml version="1.0"?>

<form id="ChairForm" name="My New Chair Survey Form">

 <description>A survey form to collect information on chairs</description>

 <sections>

   <section id="main" name="Chair Details">

     <description>A section for chair details.</description>

    <content>

      <group name="Identification">

      </group>

      <group name="Location">

      </group>

      <group name="Manufacturer Information">          

      </group>

      <group name=" Warranty Information">          

      </group>

      <group name="Features">          

      </group>

    </content>

   </section>  

 </sections>

</form>

 

Fields

Now that groups have been created we can define the fields to collect the relevant data. All fields must have an id which is unique to that section. In addition we can also specify a number of other details such as the name, description and its type. The type of the field indicates how it should be displayed within the form. The following list shows the various types which can be specified.

Type

How the field is displayed.

TextBox        

Displayed as a single line text entry field

TextArea        

Displayed as a multi-line text entry field

CheckBox        

Displayed as a check box indicating true or false

DropDown        

Displayed as a drop down list allowing the user to select from a list of predefined values

ComboBox        

Displayed as a drop down list however the user can enter custom values.

Date        

Displayed as a date

Lets assume in the previous example were only wanted to store the building and room information where each chair could be found. This would require two fields, one to store the building name and one to store the room number. We can also specify a description for the fields as was done with the previous elements.

 

<group name="Location">

<field id ="Building" name="Building" type="TextBox"></field>

<field id="Room" name="Room #" type="TextBox">

    <description>The room where the chair is located.</description>

</field>

</group>

Notice that these fields are text boxes. In some cases, especially where the values of a particular field are known in advance, it might be more convenient to provide the user with a list of options. This can be accommodated with a drop down list which allows the user to select one value from a predefined list. Simply change the type from TextBox to DropDown and specify the items the list should contain.

 

<group name="Location">

 <field id ="Building" name="Building" type="DropDown">

  <items>

    <item>Office A</item>

    <item>Office B</item>

    <item>Office C</item>

  </items>

 </field>

 <field id="Room" name="Room #" type="TextBox">

    <description>The room where the chair is located</description>

 </field>

</group>

What if the all possible values of a particular field are not fully known in advance? The combo box addresses this issue and allows the user to either select from a list or enter a custom value. Changing the above example again such that the building field behaves as a combo box requires only one modification.

 

<group name="Location">

 <field id ="Building" name="Building" type="ComboBox">

   <items>

     <item>Office A</item>

     <item>Office B</item>

     <item>Office C</item>

   </items>

 </field>

 <field id="Room" name="Room #" type="TextBox">

    <description>The room where the chair is located</description>

 </field>

</group>

 

Default Values

It is also possible to specify default values for the fields within the form. This is useful when you would like to pre-populate a blank form. Building on the last example suppose due to factors outside of our control chairs tend to be moved around within a building quite frequently. Therefore it might known what building a chair resides but not necessarily in which room. To address this uncertainty it might be beneficial to pre-populate the Room field on the blank form with “Unknown”. This can be accomplished by specifying the value attribute of the particular field.

 

<field id="Room" name="Room #" type="TextBox" value="Unknown">

 <description>The room where the chair is located</description>

</field>

Identity Fields

An identity field is a user defined field which is used to uniquely identify the completed form from others. More specifically, the identity field is used as the label on completed forms. To demonstrate this lets assume each chair in the example is coded with an ID sticker placed underneath each seat. This unique ID is a prime candidate to serve as the identity field within the form. We can add a new field to the existing identification group as shown below.

 

<group name="Identification">

<field id="ChairID" name="ID" type="TextBox"></field>

</group>

We now need to indicate that this field should be used as the identify for any completed forms. This is done by setting the identityField attribute on the parent form section equal to the id of the target field.

 

<section id="main" name="Chair Details" identityField="ChairID">

 <description>A section for chair details.</description>

 <content>

   <group name="Identification">

     <field id="ChairID" name="ID" type="TextBox"></field>

   </group>

   .

   .

   .

 </content>

</section>

Required Fields

In some cases you as a form designer might want to enforce that certain fields within the form are populated. The identity field just discussed is likely one of those fields. Referring back to our example form, we can force users to provide a chair ID when populating the form setting the required attribute equal to true as shown below.

<group name="Identification">

 <field id="ChairID" name="ID" type="TextBox" required="true"></field>

</group>

With this attribute specified the user will not be able to save a completed form until they have entered a value for the ChairID.

 

Field Visibility

As survey forms evolve the form designer may decide that an existing field is no longer relevant. One option is to simply remove the field from the form definition. However, removing a field from the form definition will result in a permanent loss of that particular fields data. An alternative solution is to simply alter the visibility of the field in question. By setting the field's visible attribute to false you as a form designer can hide a field from being displayed to the user.

 

<field id="LagacyFieldID" name="Lagacy Field" type="TextBox" visible="false"></field>

The end result is the field is hidden while at the same time preserving data previously entered into that field.



xxx_Form_Definitions         ©2011 Managing Energy Inc.