> >> 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>
> >
> >Cool!
> >
>
> thanks ... but not Xform conform - AFAIK XForm doesn't specify validation
> messages or error codes until now. Perhaps something similar will be
> integrated in future versions of the WD.
Well, as I stated in my last post maybe we can circumvent the XForm
conformance problem by using a different namespace for that.
But it is still not very nice...
(including the selector logicsheet [as follows] there would be 3 NS involved
for a simple form then!)
> >> 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.
> >
> >Why do you use xalan:evaluate() to fill in the data?
> >
>
> I need it to evaluate the XPath values of the ref attributes of the form
> controls.
> example:
>
> <form-descriptor>
> <instance>
> <person>
> <firstname>Paul</firstname>
> <lastname/>
> </person>
> </instance>
> <form>
> <textbox ref="person/firstname">
> <caption>First Name</caption>
> </textbox>
> ...
> </form>
> </form-descriptor>
>
> to transform this to HTML the following stylesheet may be used:
> ...
> <xsl:variable name="instance" select="/form-descriptor/instance"/>
>
> <xsl:template match="textfield">
> <xsl:value-of select="caption"/>
> <input type="text" value="{xalan:evaluate(concat('$instance/',
> @ref))}">
> </input>
> </xsl:template>
> ...
>
> AFAIK there is no possible solution with pure XSLT. An alternative would be
> a Transformer which fills in the data.
> I think there is also some kind of intermediate format necessary which
> represents the evaluated form.
Hm... damn! I do really propose not to use extensions! So this gonna be
tricky one then - back to the conformance problem :(
Christian - these are the problems I was thinking of...
> I think adding the evaluated values as
> elements to the form controls like you proposed in your last mail is a nice
> solution. So you get a simple and straight XML document which may be easily
> transformed to special presentations by user stylesheets. Easy if
Hm... yes of course but if we only add it as intermediate format extension
(even in a different ns) we will end up spitting out the form data twice.
Once in the instance and again in the elements themself.
> >> 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).
> >
> >Exactly...
> >
> >> 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).
> >
> >Hmm... we should get around without redirects...
> >
>
> You are right. Actions and maybe Selectors should do it.
If we use a taglib - it won't. But we could create another
taglib useful even for other things:
<sel:selector type="sitemap" parameter="page">
<sel:case name="fillin">
<xform:.../>
</sel:case>
<sel:case name="overview">
<xform:.../>
</sel:case>
<sel:case name="thanks">
<p>Thank you!</p>
</sel:case>
<sel:otherwise>
</sel:otherwise>
</sel:selector>
> >> 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 ;).
> >
> >I think that's great!
> >I'm really optimistic to have a standard sollution soon!
>
> Thank you.
> I think this could turn out in a very sophisticated project.
Yes.. sounds really good!
Greetings
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
