Feed items

As an example of the powerful data-driven dynamism available in Lotus Forms due to features of XForms, I'd like to take you through a brief conceptual tour on the focused example of creating a Lotus Form template for a Questionnaire or Survey. This template is able to handle not just any number of questions and any amount of question text, but also any kind of answer type.  And all of this would be controlled by the data so that the actual design of the Lotus Form template is the same.

The power of being purely data-driven should not be glossed over. You can easily have web application servlet code that obtains the questionnaire template and then prepopulates it with specific questionnaire data so that the client side receives a specific questionnaire selected in a previous step of the web application. But, XForms-based Lotus Forms also have that AJAX property of being responsive during run-time to new data obtained by a form via web services or other http submissions.  So, you could even have a Lotus Form that obtains and adds new questions on the fly in response to answers provided to initial questions.

This post will focus on the main repeating template that provides the dynamic presentation layer for each question of a questionnaire or survey.  As this is an example of a purely data-driven questionnaire, let's start by looking at a sample data format.  Suppose you have a survey consisting of any number of items, each of which can contain a question text, an indication of the type of question being asked, a place for an answer, and optionally some possible choices for those answers.  Something like this:

In the XFDL presentational language that Lotus Forms combines with the XForms data processing layer, every XForms user interface element has a container XFDL element
for presentation.  The survey format consists of a number of <item> elements, so an XFDL <table> containing an <xforms:repeat> is the correct top-level presentation element:

<table sid="survey">
   <xforms:repeat nodeset="/survey/item">
  
      ... <!-- UI for showing one item of data -->
     
   </xforms:repeat>
  
   ... <!-- More XFDL options for styling the whole table -->
  
</table>

The table has a scope identifier (sid) attribute that allows the table to be programmatically referenced, but we won't be using that feature in this example.  The table can also have XFDL options outside of the <xforms:repeat> to control presentational aspects like borders and background colors, and we aren't focusing on that either.

The <xforms:repeat> has an attribute called "nodeset" which uses an XPath expression to make a reference to however many <item> elements are in the <survey>.  This is an automatic or "declarative" loop construct.  For each <item> node in the data, no matter how many there are, the template content of the <xforms:repeat> is generated to present that <item> to the user. Even if new <item> elements are added at run-time, e.g. by a web service or an <xforms:insert> action, the XFDL table in the Lotus Form will dynamically grow to present the new <item> elements.  And even if some <item> elements are removed from the data, e.g. by an <xforms:delete> action associated with an XFDL <button> by an <xforms:trigger>, the XFDL table will dynamically and automatically remove the corresponding user interface elements that were presenting those removed <item> elements.

So, the magic really happens in the template inside the <xforms:repeat>. In Lotus Forms, you can put any and all kinds of XFDL items in the <xforms:repeat>, including more XFDL table items.  In this example, we will be showing a few variations that present different kinds of user interface controls for collecting a few different kinds of answers to questions.

First off, though, presenting the actual question text for an <item> is a simple matter of using an XFDL label item with an <xforms:output>, like this:

<xforms:repeat nodeset="/survey/item">
   <label sid="QuestionText">
      <xforms:output ref="question"/>
      ... <!-- more XFDL options for presentational styling -->
   </label>
  
   <layoutflow>block</layoutflow>
  
   ... <!-- more XFDL items for collecting answers -->
</xforms:repeat>

For each survey <item>, an XFDL <label> item is generated, and it binds to the <question> child element of that associated <item> using the "ref" attribute. The XFDL label item presents the text of the bound <question> node, and other XFDL options can be used to provide styling such as the block layout flow as well as alternative font color, background color, font selection and so forth.

More XFDL items can be added to the <xforms:repeat> to collect the answer for the given question.  In many cases of XFDL tables, each XFDL item within the <xforms:repeat> template is actually presented to the user.  An example would be using each XFDL item in the <xforms:repeat> to represent one column of a purchase order table.  However, it is not necessary to show all of the XFDL items within the <xforms:repeat> template.  In fact, XForms user interface controls have a selective binding feature that XFDL items support, since the XFDL items are wrappers for the XForms user interface elements. 

The selective binding feature of XForms will be used to help easily choose one XFDL item from among many to collect the user's answer to the question. Each question can have a different type of answer, so each "row" of the table can make a different choice of user interface control used to collect the answer. The selective binding feature uses an XPath predicate to decide whether or not the XForms user interface element binds to a node of data or not, and the control is invisible if it is not bound to a data node.

In the example survey data above, the first <item> contains a <question> whose type attribute indicates it is a "yes/no" question.  Inside the <xforms:repeat> we can create a checkbox item that can collect a (schema valid boolean) true/false answer, as follows:

<check sid="Answer_yesno">
   <xforms:input ref="answer[../question/@type='yesno']">
      <xforms:label/>
   </xforms:input>
   ...
</check>

The above checkbox widget only binds to <answer>, and therefore is only visible, if the corresponding question type is 'yesno'.  Otherwise, the XPath in the ref attribute of the <xforms:input> does not select any nodes, so the XFDL <check> item is not visible.

The second <item> of sample data above has a type of 'likertscale', so we would like to show a 5-point radio button group rather than a checkbox.  As explained above, the check box on the second row of the survey table automatically hides itself due to selective binding, so all we have to do is add an XFDL <radiogroup> item to the <xforms:repeat> to provide the interface for collecting the 'likertscale' type of answer, as follows:

<radiogroup sid="Answer_likertscale">
   <xforms:select1 ref="answer[../question/@type='likertscale']" appearance="full">
      <xforms:label/>
      <xforms:item>
         <xforms:label>Strongly agree</xforms:label>
         <xforms:value>1</xforms:value>
      </xforms:item>
      <xforms:item>
         <xforms:label>Agree</xforms:label>
         <xforms:value>2</xforms:value>
      </xforms:item>
      <xforms:item>
         <xforms:label>Neither agree nor disagree</xforms:label>
         <xforms:value>3</xforms:value>
      </xforms:item>
      <xforms:item>
         <xforms:label>Disagree</xforms:label>
         <xforms:value>4</xforms:value>
      </xforms:item>
      <xforms:item>
         <xforms:label>Strongly disagree</xforms:label>
         <xforms:value>5</xforms:value>
      </xforms:item>
   </xforms:select1>
   ...
</radiogroup>

The third survey <item> in the sample data above provides a closed selection of choices.  That could be styled using a pair of radio buttons, a pair of mutually exclusive checkboxes, a list box, or a popup control that provides a simple dropdown list.  The answer types in the survey format could be made to distinguish these possibilities using more keywords, but for this example we'll just assume that a <popup> control is the desired presentation for a closed selection. The XFDL markup below shows how this can be done, and it is also interesting because it is shows that the data can also dynamically control the choices, rather than having only static choices as shown in the <radiogroup> above.

<popup sid="Answer_closedselection">
   <xforms:select1 ref="answer[../question/@type='closedselection']" appearance="minimal">
      <xforms:label/>
      <xforms:itemset nodeset="../choices/choice">
         <xforms:label ref="@label"/>
         <xforms:value ref="@code"/>
      </xforms:itemset>
   </xforms:select1>
   ...
</popup>

It seems a useful, now, to round out this blog post by presenting a few more examples for other common types of input, such as single-line strings, multiline text, and dates.  Here's what the data would look like:

<survey>
  ...
  <item>
     <question type="oneline">What's your name?</question>
     <answer></answer>
  </item>
  <item>
     <question type="multiline">Do you have any other comments?</question>
     <answer></answer>
  </item>
  <item>
     <question type="date">What is your date of birth?</question>
     <answer></answer>
  </item>
  ...
</survey>

The corresponding XFDL items that would be added to the <xforms:repeat> content template for these types of questions would be:

<field sid="Answer_oneline">
   <xforms:input ref="answer[../question/@type='oneline']">
      <xforms:label/>
   </xforms:input>
   ...
</field>  

<field sid="Answer_multiline">
   <xforms:textarea ref="answer[../question/@type='multiline']">
      <xforms:label/>
   </xforms:textarea>
   <size>
      <height>5</height>
   </size>
   ...
</field>  

<combobox sid="Answer_date">
   <xforms:input ref="answer[../question/@type='date']">
      <xforms:label/>
   </xforms:input>
   <format>
      <datatype>date</datatype>
   </format>
   ...
</combobox>