Hi,
I've implemented something similar:
My form descriptor is similar to the XForms WD. I've made some
simplifications and some enhancements to allow simple processing and
validation definitions.
example form control:
<textbox ref="person/user-id">
<caption>User ID</caption>
<validate type="null">User ID must be specified.</validate>
<validate type="string" minlen="5" maxlen="20">The User ID must
have 5 to 20 characters</validate>
<validate type="unique">The User ID is already used. Please enter
an other.</validate>
</textbox>
For presentation the form descriptor is transformed by a special XSLT
sheet. I make heavy use of the xalan:evaluate() extension to fill the
instance data in the form (dont know a XSLT conform solution to resolve the
ref attributes). Then the evaluated form page is transformed to HTML Forms
and sent to the client. I use the values of the ref attributes as HTML form
control names.
The response from the client (ServletRequest) is evaluated by an Action. On
the first request of the form an XMLFragment (Node, DocumentFragment) is
created from the default instance data in the form descriptor or the
referenced XML data (using XLink). The request values from the HTML form
are validated and written to the DOM Node. The DOM Node is saved as request
attribute or in the session if needed over more requests (multipage forms).
If the submitted form data is not valid according to the information in the
form descriptor the Action redirects the user request to the form
presentation again. There I use an extented TraxTransformer to pass the
updated DOM Node (instance data) and the validation result to the XSLT
sheet as parameters (as XPath node-set).
Currently I operate only on XML files - no database or business objects
involved.
My multipage solution is very simple. I define a total number of pages in
my form descriptor and the same amount of form elements with corresponding
page attributes:
<form-descriptor pages="3">
<instance/>
<form page="1"/>
<form page="2"/>
<form page="3"/>
</form-descriptor>
The disadvantage of this solution is that only multi page forms with a
sequential process can be declared. But I dont need other ;-)
I would like to donate my stuff. But I must admit its a very raw hack and
needs lots of refactoring. And I've only implemented the things I really
needed for my project (of course ;).
best regards - Peter
-----Ursprüngliche Nachricht-----
Von: Torsten Curdt <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Datum: Donnerstag, 19. Juli 2001 15:13
Betreff: Re: [RT] forms
>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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
