Form presentation logic

Logic used in OOTB form producing XSLT. Backward compat was attempted to be mantained with 2.3, while providing some needed functionality.

Short text

Determinators

string
(element/simpleType/restriction/@base='string') & (element/simpleType/restriction/maxLength =< 99)

integer
element/simpleType/restriction/@base='integer'
 

decimal
element/simpleType/restriction/@base='decimal'

Notes

string

• element/simpleType/restriction/maxLength value determines the maxLength  html attribute value
• same value is used in the title html attribute value to provide a tooltip hint (ie '50 characters maximum')

integer

• element/simpleType/restriction/maxLength value determines the maxLength  html attribute value
• same value is used in the title html attribute value to provide a tooltip hint (ie. '10 digit number')
• same value value determines the size  html attribute value

decimal

• element/simpleType/restriction/total/totalDigits/@value + element/simpleType/restriction/total/total fraction Digits/@value (+ 1 for the decimal marker) determines the maxLength html attribute value
• same values are used in the title html attribute value to provide a tooltip hint (ie. 'Format: 000.00')
• same value (+ 1 for the decimal marker) determines the size  html attribute value

Questions

Could be argued that the tooltip hint is too subtle for something as crucial as a size restriction - should a message be automatically appended to the value of the ospi.inlinedescription if present? And ospi.description?

Long text

Determinators 

(element/simpleType/restriction/@base='string') & (element/simpleType/restriction/maxLength > 99)

Notes

element/simpleType/restriction/maxLength value determines the rows  html attribute value - the default calculation is as follows:
 

1. maxLength 100-600: 3 rows
2. maxLength 600-800: 5 rows
3. maxLength 800-1000: 7 rows
4. maxLength > 1000: 9 rows

same value is used in the title html attribute value to provide a tooltip hint (ie '150 characters maximum')

Questions

is the row height variability a good thing?

Date

Determinators

element/simpleType/restriction/@base='date'

Notes

date format xslt template driven - will need to make it depend more on locale settings

Questions

aware that there are some inner settings to this element that need to be addressed - what are these? Date ranges?

Boolean

Determinators

element/simpleType/restriction/@base='boolean'

Notes

single checkbox with a default value of unchecked, the end?

Select

Determinators 

element/simpleType/restriction/@base='string' & (element/simpleType/restriction/enumeration)

Notes

Propose that:

• maxOccurs="1" & enumeration children < 4: radiogroup input
• maxOccurs="1" & enumeration children > 4: single select listbox
• maxOccurs="unbounded" & enumeration children < 4: checkbox group
• maxOccurs="unbounded" & enumeration children > 4: multiple select listbox

Questions

Most reluctant to make any of these required (minOccurs='1'). Need to provide a default that is checked or selected. Need a mechanism for this. Use case to the contrary?

Rich text

Determinators

(element/simpleType/restriction/@base='string') & (element/annotation/documentation/@source='ospi.isRichText'=true)

Notes

Not enabled for repetition at this time (Feb 06/07)

File

Determinators

element/simpleType/restriction/@base='anyURI'

Notes

maxOccurs has a differen meaning here - it is the number of attachments that can be added, not the number of widgets (as in short text, for example) that can be cloned

Subform

Determinators

element/type  with a matching named complexType

Notes

maxOccurs has a differen meaning here - it is the number of times a subform that can be filled, not the number of widgets (as in short text, for example) that can be cloned

Questions

Filled subforms are listed in the parent form. As of (Aug  07) only the first element in the node set is used in the listing. After that for 2.5 there is a new decorator:

xs:annotation/xs:documentation[@source='ospi.key']

if the subform element has an annotation of "ospi.key" then the value of that will contain the name of the field to use in the table:

<xsl:variable name="keyField" select="$currentSchemaNode/xs:annotation/xs:documentation[@source='ospi.key']/text()"/>
<xsl:value-of select="$dataNode/node()[$keyField=name()]"/>

Alternately, the form designer can put ospi.key on subform elements that the designer wants to have show up in the parent table. These value of the field should be a number indicating the order the fields should be displayed with in the parent table.

<xsl:for-each select="$currentSchemaNode/children/element[xs:annotation/xs:documentation[@source='ospi.key']/text()]">
   <xsl:sort select="xs:annotation/xs:documentation[@source='ospi.key']/text()" data-type="number"/>
   <th>
      <xsl:call-template name="produce-label">
         <xsl:with-param name="currentSchemaNode" select="." />
      </xsl:call-template>
   </th>
</xsl:for-each>