You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2003/07/22 18:23:55 UTC
Re: [RT] Comparing Woody & XMLForm : towards a unified form
handling (long)
Hi Sylvain,
thanks for starting this thread, hopefully it will clear up the current
situation around the multiple form frameworks.
On a general note, and I understand that you know this, many arguments
of the comparison between the two change when you consider that in
XMLForm you should also have a separate form model and business model.
The security, inconsistency and (for a part) data conversion problems
dissapear and the extra work to copy between the form and business
models reappears (and also the statement about validations involving
form data and application data).
I think that for the most part our form-vision corresponds, though I
have difficulties understanding your proposed changes.
On Mon, 2003-07-21 at 20:44, Sylvain Wallez wrote:
<snip/>
> IMO, Woody's separation of concerns between form definition and template
> is not that good. Woody would be easier to use if the definition file
> was only a schema defining datatypes and if fields were defined only in
> the template.
So you're still left with two files to edit and maintain...
> Although there is a great probability that datatypes can
> be reused for different fields and even different forms, I'm not sure
> using the same fields within different templates really make sense. For
> example, HTML and WML browsers have so much different screen sizes and
> interaction constraints that a single form definition can hardly be used
> for both.
Agreed. It is however not so much about reuse but rather separation of
skills: the form template will mostly be edited by a HTML designer.
>
> Reusing datatypes for different fields would also increase the overall
> application consistency : as of today, if two fields have the same
> datatype and constraints, these must be duplicated.
Originally it was planned to have a datatype-library, but this has not
yet been implemented.
Note also that the concept of datatypes in woody is in fact an
implementation detail of the "field" widget. Not all widgets (i.e. the
repeater) have a datatype.
> This could also open
> the door to other schema languages (WXS, RNG, etc).
here I can't follow: WXS/RNG validate XML. How would those operate on
Woody's form-instance datastructure? And the datatype associated with a
single field will most likely not require structural validation, which
is exactly the main purpose of WXS/RNG?
Or would you replace Woody's form-instance datastructure with plain XML?
>
> Population and validation
> -------------------------
<snip/>
> Finally, Woody uses its own expression language, with IMO is not a good
> choice if we consider that "standard" expression languages such as Jexl
> exist and are already used in other Cocoon blocks.
I'm of course open to suggestions on this one. The expression language
currently used is quite generic, and not tailored towards any purpose,
which is not the case for e.g. XPath. Jexl seems to be better in this
regard, though also not quite perfect. For example, using the current
expression interpreter I can compare two date fields simply using
something like "date1 < date2", while this is not possible in Jexl.
> Mapping to the application data model
> -------------------------------------
>
> A form is useless if its content cannot be mapped in some way to the
> application data model.
Strictly speaking this is not required, think of a search form or a form
that simply emails the user-entered data to some address.
<snip/>
> Post-validation application behaviour can be added to either
> a subclass of AbstractXMLFormAction or in a flowscript.
Woody will eventually also get such functionality.
>
> Conclusion
> ----------
>
> XMLForm has a lot of success because it has filled a giant need in
> Cocoon applications to handle forms. Moreover, it fits nicely with
> flowscript, and this combination builds an easy to use solution for form
> handling. But using it in more and more complex use cases show some
> strong limitations that are largely related to its desire to mimic
> XForms. And I'm not sure these limitations can be removed without
> diverging largely from the XForms approach.
>
> These limitations were obviously taken into account early in Woody's
> design, which make it stronger at handling data formatting and enforcing
> semantic constraints. But Woody, by over-separating concerns, is more
> heavy to use.
>
> Considering all the pros and cons, I think Woody, which is still in its
> infancy, is more promising on the long term and should be promoted, once
> featured enough, as the preferred form handling package in Cocoon.
yes! ;-)
>
> Proposals
> ---------
>
> We've seen that Woody requires to separate form definition from form
> template. I think (Bruno, correct me if I'm wrong) this constraint comes
> from the fact that the form _is_ the model, and thus must be filled with
> data _before_ being processed by the form template.
correct
But what's not clear to me yet is whether you want to see this changed.
>
> The ongoing work on form binding considers binding as a process
> surrounding form population and validation : the application->form
> binding fills an existing form, and the form->application binding
> transfers form data to the application model once the form is correctly
> validated.
And in a flowscript, it's as simple as this (taken from
binding_example.js):
var document = loadDocument(documentURI);
var binding = loadBinding(bindingURI);
var model = form.getModel();
binding.loadFormFromModel(form.form, document);
form.show("form2-display-pipeline");
binding.saveFormToModel(form.form, document);
saveDocument(document, makeTargetURI(documentURI));
cocoon.sendPage("form2-success-pipeline");
form.finish();
[The form.show method will keep showing the form to the user until
everything is validated]
>
> Now we can imagine to have a "live" application->form binding occuring
> at form definition time which could allow simultaneous building of the
> form definition and population of form data from the binding. This
> feature could remove the need for a separate form definition and could
> be implemented by a WoodyTemplateGenerator taking as input a template
> file containing field definitions.
So it would then be the responsibility of this WoodyTemplateGenerator to
build the form instance? And where would it store that?
I think the SAX-pipeline should have publishing as its only
responsibility, the preparation work should be done by flowscripts or
Java code (actions).
> A kind of "definition by example"
> (like the QBE that exists in Excel and various database systems).
>
> This "defining-template" would only define fields and not datatypes.
> These datatypes could be either inferred from the application model
> trough the binding or fetched from a separate schema file (the current
> form definition, with only datatypes definitions).
I don't get it yet.
Let me start from a different angle: suppose that we would allow the
datatypes to be defined inline in the fields in the template, then the
template would basically be the same as the current form definition but
with foreign (HTML or other) markup mixed in between. Correct?
In the current Woody, it is then based on this form model that a form
instance structure is build, and thus in fact the form template now
serves as the "schema" based on which it is created. The fact that we
could allow the datatypes to be defined in another file doesn't change
much to that.
Hmmm, I'll have to sleep a night over all this... any extra hints you
can give to how it would work, and maybe what would exactly change or
remain of the current Woody are welcome.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Comparing Woody & XMLForm : towards a unified
form handling (long)
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-07-23 at 08:53, Christopher Oliver wrote:
> Bruno Dumon wrote:
>
<snip/>
> >>Considering all the pros and cons, I think Woody, which is still in its
> >>infancy, is more promising on the long term and should be promoted, once
> >>featured enough, as the preferred form handling package in Cocoon.
> >>
> >>
> >
> >yes! ;-)
> >
> >
> I agree. But there are several features that XMLForm has that I would
> like to add to Woody first, before it can replace XMLForm, namely:
>
> 1) Support for automatic back/next navigation in multi-page forms using
> continuations.
yep. How that will be handled precisely is still an open point, but
there are certainly multiple possibilities.
Marc points me out that what we understand to be "back" is actually
dependent on the flow implementation. In flowscript it may be the
grand-grand-parent continuation, but if the "generalized flow" is taken
into account, that won't necessarily be the case. [do I need to go in
more detail here?]
What would be nice is if the flow-layer could pass a set of named links
to the view layer, i.e. a link called "back", and one called "next", but
what's behind them wouldn't matter.
> 2) The ability to programmatically add validation errors to Woody
> widgets from a Flowscript. This is needed because it may be easier to
> enforce some constraints by writing JS code, and because you may need to
> access a back-end system in order to perform the validation.
again yep. Until now the validation errors were an implementation detail
of the widgets, but we'll need to add a setValidationError (or maybe
addValidationError) method to the Widget interface.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Comparing Woody & XMLForm : towards a unified form handling
(long)
Posted by Christopher Oliver <re...@verizon.net>.
Bruno Dumon wrote:
>Hi Sylvain,
>
>thanks for starting this thread, hopefully it will clear up the current
>situation around the multiple form frameworks.
>
>On a general note, and I understand that you know this, many arguments
>of the comparison between the two change when you consider that in
>XMLForm you should also have a separate form model and business model.
>The security, inconsistency and (for a part) data conversion problems
>dissapear and the extra work to copy between the form and business
>models reappears (and also the statement about validations involving
>form data and application data).
>
>
Exactly right.
>I think that for the most part our form-vision corresponds, though I
>have difficulties understanding your proposed changes.
>
>On Mon, 2003-07-21 at 20:44, Sylvain Wallez wrote:
><snip/>
>
>
>>IMO, Woody's separation of concerns between form definition and template
>>is not that good. Woody would be easier to use if the definition file
>>was only a schema defining datatypes and if fields were defined only in
>>the template.
>>
>>
>
>So you're still left with two files to edit and maintain...
>
>
>
>>Although there is a great probability that datatypes can
>>be reused for different fields and even different forms, I'm not sure
>>using the same fields within different templates really make sense. For
>>example, HTML and WML browsers have so much different screen sizes and
>>interaction constraints that a single form definition can hardly be used
>>for both.
>>
>>
>
>Agreed. It is however not so much about reuse but rather separation of
>skills: the form template will mostly be edited by a HTML designer.
>
>
>
>>Reusing datatypes for different fields would also increase the overall
>>application consistency : as of today, if two fields have the same
>>datatype and constraints, these must be duplicated.
>>
>>
>
>Originally it was planned to have a datatype-library, but this has not
>yet been implemented.
>
>Note also that the concept of datatypes in woody is in fact an
>implementation detail of the "field" widget. Not all widgets (i.e. the
>repeater) have a datatype.
>
>
>
>> This could also open
>>the door to other schema languages (WXS, RNG, etc).
>>
>>
>
>here I can't follow: WXS/RNG validate XML. How would those operate on
>Woody's form-instance datastructure? And the datatype associated with a
>single field will most likely not require structural validation, which
>is exactly the main purpose of WXS/RNG?
>Or would you replace Woody's form-instance datastructure with plain XML?
>
>
>
>>Population and validation
>>-------------------------
>>
>>
><snip/>
>
>
>>Finally, Woody uses its own expression language, with IMO is not a good
>>choice if we consider that "standard" expression languages such as Jexl
>>exist and are already used in other Cocoon blocks.
>>
>>
>
>I'm of course open to suggestions on this one. The expression language
>currently used is quite generic, and not tailored towards any purpose,
>which is not the case for e.g. XPath. Jexl seems to be better in this
>regard, though also not quite perfect. For example, using the current
>expression interpreter I can compare two date fields simply using
>something like "date1 < date2", while this is not possible in Jexl.
>
>
The good thing about Jexl is that it is nearly identical to Javascript,
making the form template's expression language well-integrated with the
Flowscript layer that calls it. The good thing about JXPath is that it
makes the form template's expression language well-integrated with that
of the XSLT stylesheets that follow it in a pipeline.
The Woody expression language doesn't seem to be documented, nor is its
source code present in CVS. So I can't say there's a problem with it. It
may be fine, but we need people to try it and find out. For that to
happen it needs documentation.
>
>
>>Mapping to the application data model
>>-------------------------------------
>>
>>A form is useless if its content cannot be mapped in some way to the
>>application data model.
>>
>>
>
>Strictly speaking this is not required, think of a search form or a form
>that simply emails the user-entered data to some address.
>
><snip/>
>
>
>
>> Post-validation application behaviour can be added to either
>>a subclass of AbstractXMLFormAction or in a flowscript.
>>
>>
>>
>
>Woody will eventually also get such functionality.
>
>
>
>>Conclusion
>>----------
>>
>>XMLForm has a lot of success because it has filled a giant need in
>>Cocoon applications to handle forms. Moreover, it fits nicely with
>>flowscript, and this combination builds an easy to use solution for form
>>handling. But using it in more and more complex use cases show some
>>strong limitations that are largely related to its desire to mimic
>>XForms. And I'm not sure these limitations can be removed without
>>diverging largely from the XForms approach.
>>
>>These limitations were obviously taken into account early in Woody's
>>design, which make it stronger at handling data formatting and enforcing
>>semantic constraints. But Woody, by over-separating concerns, is more
>>heavy to use.
>>
>>Considering all the pros and cons, I think Woody, which is still in its
>>infancy, is more promising on the long term and should be promoted, once
>>featured enough, as the preferred form handling package in Cocoon.
>>
>>
>
>yes! ;-)
>
>
I agree. But there are several features that XMLForm has that I would
like to add to Woody first, before it can replace XMLForm, namely:
1) Support for automatic back/next navigation in multi-page forms using
continuations.
2) The ability to programmatically add validation errors to Woody
widgets from a Flowscript. This is needed because it may be easier to
enforce some constraints by writing JS code, and because you may need to
access a back-end system in order to perform the validation.
Regards,
Chris
Re: [RT] Comparing Woody & XMLForm : towards a unified form handling
(long)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bruno Dumon wrote:
>Hi Sylvain,
>
>thanks for starting this thread, hopefully it will clear up the current
>situation around the multiple form frameworks.
>
>On a general note, and I understand that you know this, many arguments
>of the comparison between the two change when you consider that in
>XMLForm you should also have a separate form model and business model.
>The security, inconsistency and (for a part) data conversion problems
>dissapear and the extra work to copy between the form and business
>models reappears (and also the statement about validations involving
>form data and application data).
>
>I think that for the most part our form-vision corresponds, though I
>have difficulties understanding your proposed changes.
>
>
Thanks to Carsten, Marc and you for the positive feedback. Yes, I think
we globally have the same vision and that we should be able to quickly
come to a framework that should satisfy most people.
As for my proposed changes, I started a quick'n dirty hack to showcase
them. However, I'm still on vacation and only little of my time is
available for Cocoon ;-)
More soon, stay tuned.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Comparing Woody & XMLForm : towards a unified form handling
(long)
Posted by Marc Portier <mp...@outerthought.org>.
Antonio Gallardo wrote:
> Bruno Dumon dijo:
>
>>[an obvious improvement would be to make the binding also part of the
>>javascript-form-wrapper, so that you don't have to load the binding
>>yourself and can use form.load(object) and form.save(object)]
>
>
> This would be better if we can also attach a Bean here! I would allow to
> "speak" to a Database using OJB. A scratchpad of how it would be:
>
> We have a Bean filled from a database using OJB.
>
> Then we can use:
>
> function form2(form, myBean, bindingURI) {
> var document = loadBean(myBean);
> var binding = loadBinding(bindingURI);
>
> binding.loadFormFromModel(form.form, document);
> form.show("form2-display-pipeline");
> binding.saveFormToModel(form.form, document);
> fillBean(document, myBean);
> /* We catch the Bean --> use OJB to store to DB */
> ....
> cocoon.sendPage("form2-success-pipeline");
> form.finish();
> }
>
>
> loadBean(myBean); /* Load the Bean to a document */
> fillBean(myBean); /* Fill the Bean from the form retrieved values */
>
> This is just an initial idea. Currently I am trying to understand the OJB.
> I have already a simple demo using OJB-JDO. My next step is try to build a
> simple interface to interact with Woody.
>
>
> I am very glad with the steps Woody is currently doing! I hope soon we
> will have the "glue" between OJB-Woody.
>
it is there, it is called jxpath
since the current binding implementation is using jxpath to
evaluate the xpath expressions this should already be working (at
least partially)
what needs to be done to complete the story:
0/ find time to do this:
1/ setup a sample & test-environment for bean-binding
2/ and add a javabean-specific <wb:insert-node> variant that
takes a Factory class/method instead of an XML template (only for
repeater-binding)
regards,
-marc=
> Best Regards,
>
> Antonio Gallardo.
>
>
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [RT] Comparing Woody & XMLForm : towards a unified form
handling (long)
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-07-22 at 23:57, Antonio Gallardo wrote:
> This would be better if we can also attach a Bean here!
I've added an example to CVS using a bean in the binding. It uses a
different binding definition (because the structure of the XML is
different from that of the bean), but the form model and form template
stay the same. After successful submit of the form, the JX generator is
used to extract the information from the bean.
The actual flow-script that controls this is the function 'form2bean' in
the binding_example.js file.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Comparing Woody & XMLForm : towards a unified form
handling (long)
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-07-22 at 23:57, Antonio Gallardo wrote:
> Bruno Dumon dijo:
> > [an obvious improvement would be to make the binding also part of the
> > javascript-form-wrapper, so that you don't have to load the binding
> > yourself and can use form.load(object) and form.save(object)]
>
> This would be better if we can also attach a Bean here! I would allow to
> "speak" to a Database using OJB. A scratchpad of how it would be:
>
> We have a Bean filled from a database using OJB.
>
> Then we can use:
>
> function form2(form, myBean, bindingURI) {
> var document = loadBean(myBean);
> var binding = loadBinding(bindingURI);
>
> binding.loadFormFromModel(form.form, document);
> form.show("form2-display-pipeline");
> binding.saveFormToModel(form.form, document);
> fillBean(document, myBean);
> /* We catch the Bean --> use OJB to store to DB */
> ....
> cocoon.sendPage("form2-success-pipeline");
> form.finish();
> }
>
In your example above you're doing:
bean -> document -> form (and the reverse direction)
but you can actually do:
bean -> form (and the reverse direction)
so the bean replaces the document. This was also what I hinted at with
my form.load(object) and form.save(object) methods: the object can be
either a bean or a DOM-tree.
See also Marc's mail for the status of this.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Comparing Woody & XMLForm : towards a unified form handling (long)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Bruno Dumon dijo:
> [an obvious improvement would be to make the binding also part of the
> javascript-form-wrapper, so that you don't have to load the binding
> yourself and can use form.load(object) and form.save(object)]
This would be better if we can also attach a Bean here! I would allow to
"speak" to a Database using OJB. A scratchpad of how it would be:
We have a Bean filled from a database using OJB.
Then we can use:
function form2(form, myBean, bindingURI) {
var document = loadBean(myBean);
var binding = loadBinding(bindingURI);
binding.loadFormFromModel(form.form, document);
form.show("form2-display-pipeline");
binding.saveFormToModel(form.form, document);
fillBean(document, myBean);
/* We catch the Bean --> use OJB to store to DB */
....
cocoon.sendPage("form2-success-pipeline");
form.finish();
}
loadBean(myBean); /* Load the Bean to a document */
fillBean(myBean); /* Fill the Bean from the form retrieved values */
This is just an initial idea. Currently I am trying to understand the OJB.
I have already a simple demo using OJB-JDO. My next step is try to build a
simple interface to interact with Woody.
I am very glad with the steps Woody is currently doing! I hope soon we
will have the "glue" between OJB-Woody.
Best Regards,
Antonio Gallardo.
Re: [RT] Comparing Woody & XMLForm : towards a unified form
handling (long)
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-07-22 at 22:42, Bruno Dumon wrote:
<snip/>
> > I would love to see this commented a little more so that I can
> > understand more.
I should have started by saying the purpose of the example is to edit
the contents of an XML file through a Woody form.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Comparing Woody & XMLForm : towards a unified form
handling (long)
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-07-22 at 22:11, Stefano Mazzocchi wrote:
On Tuesday, Jul 22, 2003, at 11:23 America/Guayaquil, Bruno Dumon wrote:
>
> >> Although there is a great probability that datatypes can
> >> be reused for different fields and even different forms, I'm not sure
> >> using the same fields within different templates really make sense.
> >> For
> >> example, HTML and WML browsers have so much different screen sizes and
> >> interaction constraints that a single form definition can hardly be
> >> used
> >> for both.
> >
> > Agreed. It is however not so much about reuse but rather separation of
> > skills: the form template will mostly be edited by a HTML designer.
>
> Question: have you thought about using garbage as the template file?
The WoodyTemplateTransformer is somewhat different because it inserts
XML representations of the widgets, while most template transformers
look up 'primitive' (non-xml) values. But I didn't look much at the
existing template solutions yet (including garbage).
> [skip]
> >> The ongoing work on form binding considers binding as a process
> >> surrounding form population and validation : the application->form
> >> binding fills an existing form, and the form->application binding
> >> transfers form data to the application model once the form is
> >> correctly
> >> validated.
> >
> > And in a flowscript, it's as simple as this (taken from
> > binding_example.js):
> >
> > var document = loadDocument(documentURI);
> > var binding = loadBinding(bindingURI);
> > var model = form.getModel();
> >
> > binding.loadFormFromModel(form.form, document);
> >
> > form.show("form2-display-pipeline");
> >
> > binding.saveFormToModel(form.form, document);
> > saveDocument(document, makeTargetURI(documentURI));
> > cocoon.sendPage("form2-success-pipeline");
> > form.finish();
> I would love to see this commented a little more so that I can
> understand more.
ok. In fact, the above code is quite rough, it's just quickly thrown
together to make it work.
But here it is:
// the form2 function is not directly called by the sitemap but by
// a generic "woody" function that instantiates the form based on
// parameters passed from the sitemap (see woody.js file)
function form2(form, documentURI, bindingURI) {
// document contains the document to be edited as a DOM tree
// (loadDocument is an utility function that looks up the
// Avalon DOMParser component to parse the file)
var document = loadDocument(documentURI);
// binding contains an object that can bind data between
// a DOM-tree and Woody form (bidirectional). The binding
// is described in an XML file and is based on JXPath
// (loadBinding is an utility function that looks up an
// Avalon component which builds this binding)
var binding = loadBinding(bindingURI);
// we start by binding the document data to the form
// the 'form' variable is a javascript wrapper around the
// actual form, and 'form.form' is the actual Java form object
binding.loadFormFromModel(form.form, document);
// shows the form to the user until is validated successfully
form.show("form2-display-pipeline");
// use the binding to update the DOM-tree with the
// data from the form
binding.saveFormToModel(form.form, document);
// save the DOM-tree back to an XML file, the makeTargetURI
// function makes a modified filename so that the
// original document is not overwritten
saveDocument(document, makeTargetURI(documentURI));
cocoon.sendPage("form2-success-pipeline");
form.finish();
}
[an obvious improvement would be to make the binding also part of the
javascript-form-wrapper, so that you don't have to load the binding
yourself and can use form.load(object) and form.save(object)]
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Comparing Woody & XMLForm : towards a unified form handling (long)
Posted by Stefano Mazzocchi <st...@apache.org>.
I have never had the chance (yet) to try any of the form-handing
mechanisms, but I'm glad that people start talking about convergence.
Other than this, I don't have much to say.
On Tuesday, Jul 22, 2003, at 11:23 America/Guayaquil, Bruno Dumon wrote:
>> Although there is a great probability that datatypes can
>> be reused for different fields and even different forms, I'm not sure
>> using the same fields within different templates really make sense.
>> For
>> example, HTML and WML browsers have so much different screen sizes and
>> interaction constraints that a single form definition can hardly be
>> used
>> for both.
>
> Agreed. It is however not so much about reuse but rather separation of
> skills: the form template will mostly be edited by a HTML designer.
Question: have you thought about using garbage as the template file?
[skip]
>> The ongoing work on form binding considers binding as a process
>> surrounding form population and validation : the application->form
>> binding fills an existing form, and the form->application binding
>> transfers form data to the application model once the form is
>> correctly
>> validated.
>
> And in a flowscript, it's as simple as this (taken from
> binding_example.js):
>
> var document = loadDocument(documentURI);
> var binding = loadBinding(bindingURI);
> var model = form.getModel();
>
> binding.loadFormFromModel(form.form, document);
>
> form.show("form2-display-pipeline");
>
> binding.saveFormToModel(form.form, document);
> saveDocument(document, makeTargetURI(documentURI));
> cocoon.sendPage("form2-success-pipeline");
> form.finish();
I would love to see this commented a little more so that I can
understand more.
>
--
Stefano.