I have had a look on the updated XForm specification.
And here are some more RT:
Unfortunately there is only little information on subpages
in the spec. But this is what I understood from spec a
multipage form could look like:
<xform:pages>
<xform:subpage name="name">
<xform:xform id="orderForm">
<xform:instance>
<order>
<firstname/>
<lastname/>
<email/>
<city/>
<country/>
</order>
</xform:instance>
<xform:textbox ref="order/firstname">
<caption>Firstname</caption>
</xform:textbox>
<xform:textbox ref="order/lastname">
<caption>Lastname</caption>
</xform:textbox>
<xform:textbox ref="order/email" validate="???">
<caption>Email</caption>
</xform:textbox>
</xform:xform>
</xform:subpage>
<xform:subpage name="address">
<xform:xform id="orderForm">
<xform:textbox ref="order/city">
<caption>City</caption>
</xform:textbox>
<xform:selectOne ref="order/country">
<caption>Country</caption>
<choices>
<item value="DE">Germany</item>
<item value="US">USA</item>
<item value="UK">United Kingdom</item>
</choices>
</xform:selectOne>
</xform:xform>
</xform:subpage>
<xform:subpage name="overview">
<xform:xform id="orderForm">
<xform:output ref="order/firstname"/>
<xform:output ref="order/lastname"/>
<xform:output ref="order/city"/>
<xform:output ref="order/country"/>
</xform:xform>
</xform:subpage>
<xform:subpage name="thanks">
<p>Thanks, we accepted your order</p>
</xform:subpage>
</xform:pages>
So how could we tackle things now. I think it is quite
natural on such approach to have a DOMObject that will
hold the instance data of the xform. The most simplyfied
definition of such an interface would probably be:
interface DOMObject extends XMLFragment, XMLConsumer, XMLProducer {
public void setValue( String XPath );
public String getValue( String XPath );
}
When a subpage is chosen to be viewed an intance of
an DOMObject referring to the xform id needs to be
looked up. If there is none, one needs to be created
and registered. (Just like the Components in the ComponentManager)
Creation means also passing the SAX events from the
xform:instance data to the DOMObject. Now the DOMObject
holds the expected XForm structure.
Now we have an XFormAction that will do:
* Population of values into the DOMObjects
* Validation of the populated values in the DOMObjects
* Selection of the subpage based on the validation results
Then I would propose a XFormTransformer that will
extract the selected subpage fragment and add the
value to the xform elements. Here is an example of
what should come out of the transformer:
<xform:pages>
<xform:subpage name="name">
<xform:xform id="orderForm">
<xform:instance>
<order>
<firstname/>
<lastname/>
<email/>
<city/>
<country/>
</order>
</xform:instance>
<xform:textbox ref="order/firstname">
<caption>Firstname</caption>
<value>Torsten</value>
</xform:textbox>
<xform:textbox ref="order/lastname">
<caption>Lastname</caption>
<value>Curdt</value>
</xform:textbox>
<xform:textbox ref="order/email" validate="???">
<caption>Email</caption>
<value>dsff</value>
</xform:textbox>
</xform:xform>
</xform:subpage>
<xform:/pages>
Or maybe to the instance data structure:
<xform:pages>
<xform:subpage name="name">
<xform:xform id="orderForm">
<xform:instance>
<order>
<firstname>Torsten</firstname>
<lastname>Curdt</lastname>
<email>dfds</email>
<city/>
<country/>
</order>
</xform:instance>
<xform:textbox ref="order/firstname">
<caption>Firstname</caption>
</xform:textbox>
<xform:textbox ref="order/lastname">
<caption>Lastname</caption>
</xform:textbox>
<xform:textbox ref="order/email" validate="???">
<caption>Email</caption>
</xform:textbox>
</xform:xform>
</xform:subpage>
<xform:/pages>
This would probably make the XSLT stylesheet a lot more
complicated but would be even more consistent.
A Transformer will have different consderable advantages:
* the form does not usually have to be an XSP page
* at least the describtor XML can be cached then
* the form can be filled from esql or other taglibs easily
* taglib would mean to but multiple (sub)pages into
one XSP page - I'm always afraid of the 64k limitation
of XSP pages
--
This presented concept leaves even room for the business
object mapping that I want. A "class" attribute could be
added easily to the xform:instance tag that will specify
the actual class to use. The business objects only have
to implement DOMObject or be an intance of an AbstractDOMObject.
Still there are some issues left.
* error reporting
The validator could set an errorcode attribute in
the DOMObject. But somewhere there must happen
a translation into a full message. Maybe we could
reuse the i18n transformer for this? So what comes
out is something like:
<xform:textbox ref="/order/firstname">
<error><i18n:translate>firstnameERR001</i18n:translate></error>
</xform:textbox>
So the correct error messages only have to be
specified in the dictionary. voila!
* DBMS comboboxes
(just peeked into your answer on the list ;)
Of course this shouln't be an issue because
of DBMS caching of queries - but unfortunately it is.
In real world it turns out that still the DBMS part
is the slow one. Especially because usually form pages
cannot be cached. We had a couple of case where
there where up to 100 items. And multiple comboboxes
per page!
DBMS changes aren't a problem for the applications
we wrote so far. If so - well then use esql to
fill the combobox... But I would consider this
need as unusual.
* output definition
I think what is not quite clear (at least for me)
from the XForms spec is what "output" means
on selections aka choices. Is it the value
or the text? Both is needed! So how do you specify
what you want on output. This also another
pro for the DBMS comboboxes. The only way
to get text from the value or the value from
the text would be another query - not good!
* subpage navigation
A subpage is only a part of a xform. So submit
would not be the right term to goto the next
subpage. I haven't any spec for that. I would
propose somthing like:
<xform:popup name="subpagename"/> or
<xform:goto name="subpagename"/>
* datatypes
How can we integrate datatypes?
* binding
How can we integrate binding?
Again, comments please :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
