paulb@141 | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
paulb@141 | 2 | <html xmlns="http://www.w3.org/1999/xhtml"> |
paulb@141 | 3 | <head> |
paulb@141 | 4 | <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type" /> |
paulb@141 | 5 | <title>Creating Applications: Adding Multiple-Choice Fields and Values</title> |
paulb@141 | 6 | <meta name="generator" |
paulb@141 | 7 | content="amaya 8.1a, see http://www.w3.org/Amaya/" /> |
paulb@141 | 8 | <link href="styles.css" rel="stylesheet" type="text/css" /> |
paulb@141 | 9 | </head> |
paulb@141 | 10 | <body> |
paulb@141 | 11 | <h1>Creating Applications: Adding Multiple-Choice Fields and Values</h1> |
paulb@141 | 12 | <p>Up to this point, we have only considered two kinds of Web form |
paulb@141 | 13 | fields: text entry fields and action buttons. Since most Web forms |
paulb@141 | 14 | offer more convenient ways of entering certain kinds of data, we shall |
paulb@141 | 15 | now investigate multiple-choice fields as an example of how XSLForms |
paulb@141 | 16 | handles more complicated types of fields.</p> |
paulb@141 | 17 | <p>We shall revise our <a href="data.html">form data structure</a> to |
paulb@141 | 18 | be the following:</p> |
paulb@141 | 19 | <pre><?xml version="1.0"?><br /><structure><br /> <item value="some value"><br /> <type value="some type"/><br /> <subitem subvalue="some other value"/><br /> </item><br /></structure></pre> |
paulb@141 | 20 | <h2>Single-Valued Fields</h2> |
paulb@141 | 21 | <p>Whilst HTML offers types of form fields where users can select one |
paulb@141 | 22 | or many values presented in a list or menu, we shall first consider the |
paulb@141 | 23 | case where only a single value can be chosen from such a selection.</p> |
paulb@143 | 24 | <form method="post" action="none" name="single"> |
paulb@141 | 25 | <p>Some item: <input name="value" value="some value" /><input |
paulb@141 | 26 | name="remove" value="Remove" type="submit" /></p> |
paulb@141 | 27 | <p>Item type: |
paulb@141 | 28 | <select name="type"> |
paulb@141 | 29 | <option>(Not selected)</option> |
paulb@141 | 30 | <option>Important</option> |
paulb@141 | 31 | <option>Not important</option> |
paulb@141 | 32 | <option>Personal</option> |
paulb@141 | 33 | </select> |
paulb@141 | 34 | </p> |
paulb@141 | 35 | <p>Itself containing more items:</p> |
paulb@141 | 36 | <p>Sub-item: <input name="subvalue" value="some other value" /><input |
paulb@141 | 37 | name="remove2" value="Remove" type="submit" /></p> |
paulb@141 | 38 | </form> |
paulb@141 | 39 | From the item type list only one value may be selected. |
paulb@141 | 40 | <p>Taking the example HTML code from before, we can add a |
paulb@141 | 41 | definition of this new list to the template to produce something |
paulb@141 | 42 | like this:</p> |
paulb@144 | 43 | <pre><html xmlns="http://www.w3.org/1999/xhtml"<br /> xmlns:template="http://www.boddie.org.uk/ns/xmltools/template"><br /><head><br /> <title>Example</title><br /></head><br /><body template:element="structure"><br /><form action="" method="POST"><br /><br /><!-- Template text between the start and the interesting part. --><br /><br /><div template:element="item"><br /> <p><br /> Some item: <input template:attribute="value" name="{template:this-attribute()}" type="text" value="{$this-value}" /><br /> <input name="remove={template:this-element()}" type="submit" value="Remove" /><br /> </p><br /> <span |
paulb@141 | 44 | style="font-weight: bold;"><p></span><br |
paulb@141 | 45 | style="font-weight: bold;" /><span style="font-weight: bold;"> Item type:</span><br |
paulb@144 | 46 | style="font-weight: bold;" /><span style="font-weight: bold;"> <select template:element="type" name="{template:new-attribute('value')}"></span><br |
paulb@143 | 47 | style="font-weight: bold;" /><span style="font-weight: bold;"> <option template:element="type-enum" template:expr="@value = ../@value" template:expr-attr="selected"</span><br |
paulb@143 | 48 | style="font-weight: bold;" /><span style="font-weight: bold;"> template:value="@value" value="{@value}" /></span><br |
paulb@141 | 49 | style="font-weight: bold;" /><span style="font-weight: bold;"> </select></span><br |
paulb@144 | 50 | style="font-weight: bold;" /><span style="font-weight: bold;"> </p></span><br /> <p><br /> Itself containing more items:<br /> </p><br /> <p template:element="subitem"><br /> Sub-item: <input template:attribute="subvalue" name="{template:this-attribute()}" type="text" value="{$this-value}" /><br /> <input name="remove2={template:this-element()}" type="submit" value="Remove" /><br /> </p><br /> <p><br /> <input name="add2={template:this-element()}" type="submit" value="Add subitem" /><br /> </p><br /></div><br /><p><br /> <input name="add={template:this-element()}" type="submit" value="Add item" /><br /></p><span |
paulb@141 | 51 | style="font-weight: bold;"><br /><br /></span><!-- Template text between the interesting part and the end. --><br /><br /></form><br /></body><br /></html></pre> |
paulb@141 | 52 | <p>There are a lot of details here that need to be explained. Here is |
paulb@141 | 53 | what was done:</p> |
paulb@141 | 54 | <ol> |
paulb@141 | 55 | <li>A paragraph was added to provide some space on the page for the |
paulb@141 | 56 | field.</li> |
paulb@141 | 57 | <li>Inside the paragraph, next to the label text, an HTML <code>select</code> |
paulb@141 | 58 | element was added.</li> |
paulb@141 | 59 | <li>The <code>select</code> element is mapped onto the <code>type</code> |
paulb@141 | 60 | element in the form data structure. However, HTML fields must produce |
paulb@141 | 61 | values and it makes no sense to interpret a textual value as an |
paulb@141 | 62 | element. Therefore, we indicate in the name of the <code>select</code> |
paulb@141 | 63 | element that the value submitted maps onto the <code>value</code> |
paulb@141 | 64 | attribute of the <code>type</code> element in the form data |
paulb@141 | 65 | structure.</li> |
paulb@141 | 66 | <li>Inside the <code>select</code> element, we include an <code>option</code> |
paulb@141 | 67 | element which defines the values which will be presented to users |
paulb@141 | 68 | of the form. Note that the <code>option</code> element maps onto |
paulb@141 | 69 | a <code>type-enum</code> element which is not mentioned in our |
paulb@141 | 70 | revised form data structure above; this will be discussed below.</li> |
paulb@141 | 71 | </ol> |
paulb@141 | 72 | <h2>Output Structures</h2> |
paulb@141 | 73 | <p>Although we revised the form data structure above, and whilst the |
paulb@141 | 74 | revised structure can describe form data submitted by users of our |
paulb@141 | 75 | application, it is unfortunately not sufficient to define the form data |
paulb@141 | 76 | that is to be presented. Consider the multiple-choice values that shall |
paulb@141 | 77 | be presented to users: such values are not defined in our revised |
paulb@141 | 78 | structure. Therefore, we shall define an output form data structure as |
paulb@141 | 79 | follows:</p> |
paulb@141 | 80 | <pre><?xml version="1.0"?><br /><structure><br /> <item value="some value"><br /> <type value="some type"><br /> <type-enum value="choice #n"/><br /> </type><br /> <subitem subvalue="some other value"/><br /> </item><br /></structure></pre> |
paulb@141 | 81 | <p>But since we will receive a structure resembling that defined |
paulb@141 | 82 | earlier, yet need to present a structure like the one above, we will |
paulb@141 | 83 | need to find a way of merging the range of allowed values into the |
paulb@141 | 84 | user-edited form data before presenting that data using our template.</p> |
paulb@141 | 85 | </body> |
paulb@141 | 86 | </html> |