Konstantin,
> That's cool! Waiting result with impatience. If Cocoon will have all
> features needed for a form-based web application then a lot of people will
> move from Struts to Cocoon. And I hope to move all our projects to Cocoon.
Word up.
If good Form handling was available, I would have managed to push Cocoon vs
JSP & Struts in a big project we started recently.
> > then further in the pipeline:
> >
> > <selector
> > <when test="validationSuccess">
> > render next page
> > <otherwise> <!-- render the old page -->
> > <transformer type="castor" src="page-with-errors.xml"/>
> > <transformer src="xmlform2html.xsl/>
>
> This is the way Struts works (you know that, of course). Although Struts
has
> less verbose syntax for that:
> <forward name="success" path="/otherResource"/>
> <forward name="error" path="/errorResource"/>
>
> Maybe something like this can be added to sitemap syntax? What about a
> 'test' attribute for every pipeline component? So, only those components
> will be used whose 'test' expression will return true?
>
> This can be used also in action-sets to select actions to be performed.
Would this slight modification make you feel any better?
<selector
<when test="validationSuccess=success">
<call-resource next page>
<when test="validationSuccess=failure">
<transformer type="castor" src="page-with-errors.xml"/>
<transformer src="xmlform2html.xsl/>
> > where page-with-errors.xml is
> >
> > <xmlform xmlns:castor="castornamespace">
> > <insert bean="xmlform"/>
> > <insert bean="validationResult"/>
> > </xmlform>
> >
> >
> > How does that look?
>
> Looks fine, but in this case you'll have all your presentation logic in
XSL,
> which is not bad, but sometimes hard to customize and maintain. What about
> of using XPath expressions with included beans to bind them to form
elements
> like it's done in XForms?
That would be a good option.
>
> What about this:
> <xmlform xmlns:castor="castornamespace">
> <insert bean="xmlform" as="DOM"/> <!-- This will result in a DOM object
> placed in request (or session) -->
> <insert bean="validationResult" as="string"/> <!-- This will output SAX
> events and result in an XML string -->
> </xmlform>
>
> Then a logicsheet/transformer can be used for something like this to bind
> the data to form elements:
>
> <input ref="xmlform/field/value" .../>
If Torsten is on your wavelength, you must be up to something good.
I need to see a more complete example to understand your proposal though.
How does the <input ref=> above get resolved?
One of the reasons why I am not extremely hot about server side XForms, is
in agreement
with something Stefano said a while back. It may get too complex to
customize the look and feel of
your actual html input field, if you need to always transform an abstract
XML form <input> field into HTML field.
That is why I though to kept it simple and provide access to the XML form
model, but not dictate the presentation.
Maybe I just don't understand well enough your thoughts.
Ivelin
>
> --
> Konstantin Piroumian
> [EMAIL PROTECTED]
>
> > ----- Original Message -----
> > From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]>
> >
> > > It just might help a bit with forms stuff:
> > >
> > > http://www.infozone-group.org/schemoxDocs/html/ctwo.html
> > >
> > > --
> > > Nicola Ken Barozzi [EMAIL PROTECTED]
> > > - verba volant, scripta manent -
> > > (discussions get forgotten, just code remains)
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
