cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: Server-side XForms (was Re: Disappointed about avalon usage)
Date Thu, 02 Oct 2003 11:37:44 GMT
On 01.Oct.2003 -- 02:07 PM, Michael Lipp wrote:
> And here is where XForms fits 100%. We simply use the (X)HTML with 
> XForms UI-elements for the form as one of the parameters in the tool 
> definition (i.e. you define a tool by combining the one generic 
> implementation class with a specific HTML fragment). Into the HTML, the 
> tool - when called - inserts the actual data and OUT parameters as a 
> XForms model and then hands this to the XForms processor (at least 
> that's the targeted scenario). Currently, we have a very, very small 
> subset of the functionallity by simply applying a stylesheet with 
> non-standard dynamic evaluations (to resolve the references to the model 
> elements) to the mixture of HTML, XForms UI elements and XForms model, 
> thus producing a displayable HTML form.
> So, I do not favour XForms in particular. But it is the only starting 
> point that I have found that supports this scenario with runtime form 
> definition. Maybe I have simply not understood XMLForms in Cocoon, but I 
> have tried. And I am sure to have understood that you need JavaBeans 
> corresponding to your forms and this rules out XMLForms for our 
> scenario, because we must be able to create the form completely at run 
> time (from the workflow description). And though maybe possible, I do 
> not want to do something with dynamic code generation (for the 
> JavaBeans), I need a fully interpreted solution for form creation.
> OK, this was a fast walkthrough and I hope I have made the problem 
> clear. If you know of another approach to this, I would, of course, like 
>  to know about it.

Well, couldn't resist to mention the "simple" forms solution in Cocoon: 
FormValidatorAction, SimpleFormTransformer, and
SimpleFormInstanceTransformer which allow for basic syntax validation
of submitted values, display of validation results, repeating form
elements depending on available data, form filling (e.g. with request
parameters), extraction of instance data. 

The last two features allow to have instance data separate from the
form controls. All those components work on XML files (or input
modules, which, through XMLFileModule allows to access XML files
again...) And those are the features I like most about XForms.
But then, this is nowhere near the cool features of Woody and only
meant as a teaser or migration path for plain HTML forms. However, I
believe it works well for completely dynamic forms.

Have a look at the simple form processing example in 2.1.2 (better: CVS)

Sorry. Couldn't resist the temptation ;-)

C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message