Editing XML Data Using XUpdate and HTML Forms
by Chimezie Ogbuji
|
Pages: 1, 2
The stylesheet
The stylesheet will take an instance of our editable XML schema and generate forms for editing the data. It uses the form elements (from our list above) where appropriate, with labels to identify each data entry.
Let's take a look at the top level templates to see how the form is setup:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:edXml="http://chimezie.ogbuji.net/xml/EditableData/">
<xsl:output method="xml" version="1.0"
encoding="UTF-8" indent="yes"/>
<xsl:template match="edXml:Object">
<table>
<caption>Editing: <i>
<xsl:value-of select="@name"/></i></caption>
<xsl:apply-templates select="edXml:Entry |
edXml:Boolean | edXml:List | edXml:LargeEntry"/>
<tr>
<td/>
<th align="center">
<input type="submit" value="Change {@name}"/>
</th>
</tr>
</table>
</xsl:template>
.... snip ...
</xsl:stylesheet>
The Object element is matched and the HTML for a
table is created in the result tree. The table has a caption
identifying the object being edited by name. The stylesheet then
instructs the processor to matches the elements for the 4 data
types (as defined previously in our schema).
There will be templates for each data type in order to render them appropriately. A submit button is created at the bottom of the table.
The data templates
We'll now take a closer look at one of the matching templates. In particular,
we will pay close attention to the template that matches List
elements. These are the more involved data structures which are rendered using
SELECT and OPTION form elements.
<xsl:template match="edXml:List">
<tr>
<th align="right">
<xsl:value-of select="@name"/>
</th>
<td>
<select name="input-{@name}">
<xsl:for-each select="edXml:Option">
<xsl:element name="option">
<xsl:attribute name="value">
<xsl:value-of select="."/>
</xsl:attribute>
<xsl:attribute name="name">
<xsl:text>input-</xsl:text>
<xsl:value-of select="@name"/>
</xsl:attribute>
<xsl:if test="boolean(number(@selected))">
<xsl:attribute name="selected">on</xsl:attribute>
</xsl:if>
<xsl:value-of select="@label"/>
</xsl:element>
</xsl:for-each>
</select>
</td>
</tr>
</xsl:template>
First, notice we put a header cell with the name of the data in the result tree. Then we create the SELECT and OPTION elements, using the structure of the source document to determine how they are rendered. We use an arbitrary convention for the input names: we append 'input-' to their names (as specified in the source instance).
The resulting form
The template only generates the HTML for the table and the form inputs. The idea is for the form body itself (as well as the rest of whatever is to be displayed in addition to the automatically generated forms) to be provided previously. The template is evoked to fill the remaining HTML. The resulting transformation results in HTML like the following.
Transforming form data to XUpdate documents
Finally, we need to discuss how a template can be fashioned to take the generated names of the form inputs as top-level parameters and generate an XUpdate document. This XUpdate document can be applied against the original instance of the editable XML schema in order to reflect the modifications specified by the agent.
Routing form data to the stylesheet.
Depending on the application, the POSTed form data can be redirected to a stylesheet in many ways. If an application server is being used, it can pass the form data as the source for the transformation or through some other external means (top-level parameters or extension functions/elements).
The latter option is the way 4Suite works. We leave this detail to the application developer and simply outline examples of XUpdate documents that are generated from various scenarios.
XUpdates per data type
Consider the following scenarios:
- The user agent changes the biography entry only.
- The user agent changes the biography and age entries.
- The user agent changes the administrator entry value to "true"
In the first case, assuming the user agent removes the last name of the user (Ogbuji, in this case) from the biography, the resulting XUpdate document would be
<xupdate:modifications
version="1.0"
xmlns:xupdate="http://www.xmldb.org/xupdate"
xmlns:edXml="http://chimezie.ogbuji.net/xml/EditableData/">
<xupdate:update
select="//edXml:Object/edXml:LargeEntry[@name = 'biography']">
Chimezie is software developer with a bachelors degree
in Computer Engineering. He is currently a contractor
for Fourthought Inc.
</xupdate:update>
</xupdate:modifications>
In the second scenario, we will assume the biography is changed in the same way and the age entry is changed to the third option (Middle aged adult). The corresponding XUpdate document would look like
<xupdate:modifications
version="1.0"
xmlns:xupdate="http://www.xmldb.org/xupdate"
xmlns:edXml="http://chimezie.ogbuji.net/xml/EditableData/">
<xupdate:update
select="//edXml:Object/edXml:LargeEntry[@name = 'biography']">
Chimezie is software developer with a bachelors degree
in Computer Engineering. He is currently a contractor
for Fourthought Inc.
</xupdate:update>
<xupdate:remove
select="//edXml:Object/edXml:List[@name = 'age']/
edXml:Option[@label = 'Young adult']/@select"/>
<xupdate:update
select="//edXml:Object/edXml:List[@name = 'age']/
edXml:Option[@label = 'Middle aged adult']/@select">
1
</xupdate:update>
</xupdate:modifications>
This document starts off like the previous once because the same change is
applied to the biography entry. However, there are two new xupdate
elements. The first matches the Option element (in the instance of
our schema), which represented the old selection, and removes the "select"
attribute. It then adds a "select" attribute (with a value of 1) to the
Option element representing the new selection, essentially toggling
the selection from the old value to the new.
Finally, the last scenario involves the modification of a Boolean data-type
(rendered as radio inputs with values of "true" or "false"). This involves a
simple modification of the "value" attribute on the corresponding
Boolean element. The XUpdate document generated would look like
<xupdate:modifications
version="1.0"
xmlns:xupdate="http://www.xmldb.org/xupdate"
xmlns:edXml="http://chimezie.ogbuji.net/xml/EditableData/">
<xupdate:update
select="//edXml:Object/edXml:Boolean[@key = 'biography']/@value">
1
</xupdate:update>
</xupdate:modifications>
Conclusion
|
Related Reading 
XML Schema |
The editable data XML schema we have defined here is abstract enough to be a sufficient representation of arbitrary application data. However, it isn't practical to assume that it will be the best XML schema for any given situation. In most cases, the application developer would want to transform XML data from a specific format to this editable data XML schema, generate form HTML, collect the modifications, and transform the instance back to the original format.
These two very simple stylesheets can save a significant amount of work to create repetitive HTML for forms. For other tangential considerations, the user should take a look at the W3C's XForms 1.0 Working Draft: http://www.w3.org/TR/xforms/, which proposes a platform-independent way to specify user interface forms by separating the data model from presentation information.
Resources
- XUpdate Working Draft: http://www.xmldb.org/xupdate/xupdate-wd.html
- chime.xml -- The example instance of our editable data XML schema.
- generate-forms.xslt -- The stylesheet responsible for transforming an instance of the schema into HTML form elements.
- EditableData.xsd -- The schema definition of the our editable data XML format.
- can't get chime.xml
2002-06-19 22:08:53 Thomas Green - RE: can't get chime.xml
2002-06-19 23:50:20 Thomas Green - Redundency of data in selection list
2002-06-16 00:23:01 Bala Chandran - Question
2002-06-14 06:57:55 Ian Sharpe
