> -----Original Message-----
> From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, March 20, 2002 5:39 PM
> To: [EMAIL PROTECTED]
> Subject: Re: SchemoX forms
> 
> 
> 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.
> 

More Cocoon Webapps to the people! ;)))

> > > 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/>

In this case I'd rename 'validationSuccess' to 'validationResult' or simply
'result'. And yes, this one is a little closer to what I an thinking, but my
thoughts are really random now about that. I am thinking about some hybrid
selector/matcher syntax that would allow expressions like:

<if test="xpath:eval({1}, /myform/value='a') and bean:errorList.count=0" />

But this is against KISS concept ;)

> 
> > > 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.

This can be implemented like an XFormsTransformer, f.e.

> 
> >
> > 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.

As you could already notice, he's working on this.

> 
> 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.

Just look at the sample XForms example that I've sent a while ago and
imagine that initialization of field values where performed on the server
side. Error messages also can be assigned to fields.

Looking forward to see yours and Torsten's work in CVS to start
experimenting with. Then will try to demonstrate with an example what I want
to achieve.

Konstantin

> 
> 
> Ivelin

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to