cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <tcu...@dff.st>
Subject RE: [RT] forms
Date Fri, 20 Jul 2001 08:38:22 GMT
> >> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message