You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2003/07/21 20:44:01 UTC
[RT] Comparing Woody & XMLForm : towards a unified form handling
(long)
Hi all,
Lately, I've been thinking a lot about form handling in Cocoon. The
reason for this is that I will very soon start a project which is
basically a large set of forms (about 40 different screens used to fill
an XML document containing collections having up to 1000 or 2000 items).
As part of our proposal for the project, I did some prototyping with
XMLForm (+flowscript) and liked its lightweight markup and the strong
separation it enforces between form definition and form layout. But I
disliked its poor syntactical validation facilities. On the other side,
we have Woody which is very good a validating data but which I find
heavy to use and defines its own schema language. So this RT is my
attempt to make a synthesis of the good and bad points of both
frameworks, augmented with my own ideas, so that we can move towards a
single unified form handling package in Cocoon.
Disclaimer : I don't want to start a war between Woody and XMLForm, but
just try to analyze what we have today and expose what I (hence it's
subjective) consider as good. Discussion is of course welcomed. Also, I
may have missed some features of one or the other framework. In that
case, please don't shoot at me, but be kind enough to explain what I
missed !
Also, I'll speak about XMLForm, even if it's somewhat dead and replaced
by JXForms (essentially a cleaner rewriting of the XMLFormTransformer
and an update of the markup to the latest XForms draft), because all
criticisms about XMLForm below come from the original XMLForm and not
the JXForms work.
---oOo---
General overview
----------------
Both Woody and XMLForm use the same basic principles :
1/ Content production : a form template is "instanciated", i.e. it is
filled with values coming from a data model, and the instanciated form
is transformed to the target language (e.g. HTML) using generic and/or
custom stylesheets that know how to render the various widgets.
2/ Form validation : upon form submission, values are validated and
stored into a data model, and violations are produced if some validation
error occurs (validations involving several fields are also possible).
In case of error, the form can be redisplayed with the violations.
But, as we will see below, the notions of form template, data model and
validation are very different in Woody and in XMLForm.
---oOo---
Form definition
---------------
Woody separates form definition, form template and form instance (3
different namespaces). The form definition is a kind of schema language
that defines every widget in the form with its label, datatype and
validation constraints. The template contains references to form fields
mixed with foreign markup (such as HTML). It is instanciated using the
WoodyTransformer : every field present in the template is replaced by
the corresponding instance acccording to the form definition.
Woody has no notion of application model, as it stores field values in
it's own data structure, which must be read and written to the
application model. Work is underway in this area with a JXPath based
binding.
XMLForm has only one markup, inspired by the W3C's XForms specification.
This markup is more or less equivalent to the Woody template (it accepts
foreign markup), which is instanciated ("augmented" would be better)
with either the XMLFormTransformer/JXFormsTransformer or the
JXFormsGenerator. Form fields contain XPath references to the data
model, which can therefore have an arbitrary complexity.
<my-opinion>
XMLForm is way easier to setup to produce forms : a single file, a data
model containing any mixture of objects handled by JXPath (JavaBeans,
DOM elements, etc), XPath expressions everywhere, and you're done. But
as soon as there's a need for data whose formatting is more than
toString(), such as dates and float values, and even more in an I18Nized
environment, XMLForm shows strong limitations, mainly related to lack of
proper formatting functions in XPath.
As JXPath supports extension functions, building a library of formatting
functions can be a solution to circumvent XPath's reduced function set.
But we'll see below that there's still a problem with parsing submitted
form data.
Woody, on the other hand, is more complicated to set up, as two files
are needed (form definition and form template), with many
cross-references (field IDs). But Woody shines for complicated
formatting (see <convertor> directives) and I18N.
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. 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.
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. This could also open
the door to other schema languages (WXS, RNG, etc).
</my-opinion>
---oOo---
Population and validation
-------------------------
"Population" is the term used to designate the action of "filling" the
data model with form-submitted data. "Validation" is the action of
controlling that submitted data is valid, i.e. that is satisfies some
syntactic and semantic constraints.
Upon form submission, XMLForm traverses all request parameters and tries
to set their value on the data model using JXPath. A feature allows to
filter request parameters that are not part of the data model. If the
data model was filled correctly, a validation is performed using
Schematron. This allows to have finer-grained or inter-field controls,
again using XPath expressions. Each of these two phases can produce
violations, which are recorded in the Form object.
Upon form submission, Woody traverses the form's widget tree, and each
widget is responsible to parse the corresponding request parameter and
validate it's value. Non-visual widgets are also provided to perform
inter-field controls.
<my-opinion>
Here again, XMLForm is very easy to use but shows some strong
limitations : because it's designed after XForms, XMLForm has no feature
to specify how to parse form parameters (strings) into strongly typed
data. So even basic parsing of e.g. dates is not possible, and
locale-dependent parsing is clearly not possible.
The Schematron validation has less restrictions since it deals with the
populated data model, and thus on strongly typed data, if they could be
parsed in the population phase.
XMLForm also has what I consider a strong security weakness : the
default request parameter filter rejects only special parameters such as
"cocoon-action-*", which means that a request can be hacked that
modifies a part of the data model that wasn't available as a form field.
Considering that programmers are lazy (as I am), the form model will
often be the actual business object. The consequences of providing a
form to a user to update her location information can be catastrophic if
the User class contains "address", "phoneNumber", but also "accessRights"...
W3C XForms, which inspired XMLForm, is a client-side specification
targeted at producing XML documents validated by a WXS (W3C XML Schema).
But XMLForm is server-side, and doesn't enforce any particular schema
language. This means that very few features of XForms are actually used
except the form markup and that all has to be invented to produce a
featured server-side form framework, particularily in this population &
validation phase.
Woody, by traversing the widget tree that was used to produce the form,
doesn't have the security weakness of XMLForm since only parameters
present in the produced form are considered. Also, it's strong parsing
and I18N features make custom formatting really easy.
But, being limited to the form's data model, complex validations
involving form data and application data can be difficult to do with
Woody and will need custom Java code.
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.
</my-opinion>
---oOo---
Mapping to the application data model
-------------------------------------
A form is useless if its content cannot be mapped in some way to the
application data model.
XMLForm has no special provision for mapping form data to application
data, but using JXPath makes it easy to fill any JavaBean or any DOM
structure. Post-validation application behaviour can be added to either
a subclass of AbstractXMLFormAction or in a flowscript.
Woody currently does not provide anything to map form data to
application data and all this must be coded either in a subclass of
AbstractWoodyAction or in a flowscript. But there's work underway to add
binding features to Woody, the first incarnation being based on JXPath.
<my-opinion>
XMLForm makes it easy (as pointed out above) for the lazy programmer to
set the application data as the form model : mapping is then immediate
and totally transparent. But along with the security problem mentioned
above, this also means that when a form population & validation fails,
it is very likely that some fields already have been modified,
potentially leaving the data model in an inconsistent state.
So the secure and clean solution is to use a form-specific data model (a
JavaBean, DynaBean or XML DOM), but this requires then custom code to
copy form data to the application data model, thus loosing the
simplicity provided by JXPath.
The ongoing work on Woody binding potentially allows a great range of
target data models : the current JXPath binding will make it easy to map
form data to an abitrary data structure, without XMLForm's limitations
since parsed and strongly typed data will be stored in the application
model. But we can also imagine other declarative bindings targetted at
e.g. relational databases (no intermediate bean), EJBs, etc.
</my-opinion>
---oOo---
I18N
----
I18N features should be separated in two main areas :
- I18Nization of form labels and item values (i.e. combobox labels)
- I18Nization of textbox inputs, such as floating point numbers, dates, etc.
For the first item, both XMLForm and Woody accept any foreign markup in
widget labels, including <i18n:*> tags for use with the I18NTransformer.
Woody lacks the equivalent to <xf:help> but this was recently discussed
and should be added soon. XMLForm also allows labels and similar items
to have their content fetched from the form model using a "ref"
attribute. In that case, however, only characters are produced, and not
mixed content.
For the second item (i18nization of inputs), XMLForm has no support, as
it hardly supports custom formats, as explained previously. Woody, on
the other hand, has strong support for i18nization of inputs through its
<convertor> tag that supports locale-specific patterns for formatting
and parsing.
<my-opinion>
XMLForm's strong limitations for values formatting also apply to the
i18n domain, whereas Woody not only provides strong support for value
formatting, but also strong support for locale-dependend formatting.
XMLForm's "ref" attribute on form labels allows messages to be part of
the form model, and thus be dynamic, but I'm not sure this is of real
use. And if it is, Woody may be able to provide an equivalent through
nested tags in the <wd:label> element.
</my-opinion>
---oOo---
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.
---oOo---
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.
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.
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. 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).
On the other hand, form->application binding cannot be live, since we
must ensure that all submitted value are valid before modifying the
application data.
---oOo---
Thanks for reading so far. As I expect this post to generate lots of
discussions, I suggest to create separate threads for particular
subjects (particularily the final "proposals" chapter) in order to keep
the discussion focused.
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>.
Sylvain et all,
We were patiently expecting that once it would be that:
Sylvain Wallez wrote:
> Hi all,
>
first of all: great work and gentle introduction, many thx
> Lately, I've been thinking a lot about form handling in Cocoon. The
> reason for this is that I will very soon start a project which is
> basically a large set of forms (about 40 different screens used to fill
> an XML document containing collections having up to 1000 or 2000 items).
> As part of our proposal for the project, I did some prototyping with
> XMLForm (+flowscript) and liked its lightweight markup and the strong
> separation it enforces between form definition and form layout. But I
> disliked its poor syntactical validation facilities. On the other side,
> we have Woody which is very good a validating data but which I find
> heavy to use and defines its own schema language. So this RT is my
> attempt to make a synthesis of the good and bad points of both
> frameworks, augmented with my own ideas, so that we can move towards a
> single unified form handling package in Cocoon.
>
here here!
it is not going to be an easy task for sure... the *one size fits
all* -goal is not always reachable:
indeed: on the one side a framework like this should be _useful_
(in the sense of being complete and fast to use)
but: on the other hand should not be limiting anyone to _only_
the envisioned possibilities of its creators... (that is always
the case, but I guess you understand what I'm trying to say)
the 80-20 rule will hopefully guide us (since that one is often
creating the itches we want to scratch)
> Disclaimer : I don't want to start a war between Woody and XMLForm, but
> just try to analyze what we have today and expose what I (hence it's
> subjective) consider as good. Discussion is of course welcomed. Also, I
> may have missed some features of one or the other framework. In that
> case, please don't shoot at me, but be kind enough to explain what I
> missed !
>
will do, and same position here, I can learn some from jxforms,
and Woody can benefit from your proposed enhancements in the process
> Also, I'll speak about XMLForm, even if it's somewhat dead and replaced
> by JXForms (essentially a cleaner rewriting of the XMLFormTransformer
> and an update of the markup to the latest XForms draft), because all
> criticisms about XMLForm below come from the original XMLForm and not
> the JXForms work.
>
> ---oOo---
>
> General overview
> ----------------
>
> Both Woody and XMLForm use the same basic principles :
>
> 1/ Content production : a form template is "instanciated", i.e. it is
> filled with values coming from a data model, and the instanciated form
> is transformed to the target language (e.g. HTML) using generic and/or
> custom stylesheets that know how to render the various widgets.
>
> 2/ Form validation : upon form submission, values are validated and
> stored into a data model, and violations are produced if some validation
> error occurs (validations involving several fields are also possible).
> In case of error, the form can be redisplayed with the violations.
>
> But, as we will see below, the notions of form template, data model and
> validation are very different in Woody and in XMLForm.
>
> ---oOo---
>
>
> Form definition
> ---------------
>
> Woody separates form definition, form template and form instance (3
> different namespaces). The form definition is a kind of schema language
the new form binding introduces a 4th namespace
but the good news is that the form-instance tags are not to be
developer-written (hm, but the xsl converting it into whatever is
dealing with it)
> that defines every widget in the form with its label, datatype and
> validation constraints. The template contains references to form fields
> mixed with foreign markup (such as HTML). It is instanciated using the
> WoodyTransformer : every field present in the template is replaced by
> the corresponding instance acccording to the form definition.
>
yes.
one small remark: you could choose not to use the template.
in that case one uses the WoodyGenerator which will produce the
FULL XML representation of the form-instance at the start of your
pipe (foreign markup is then typically decorated on the stream by
any wild mix of xslt, xinclude, ...)
but I get your point:
if I got this correct then the big advantage of xmlforms you
stress here is that the 'template' defines the _model_ while
woody explicitely has a separate file for the latter, correct?
in fact woody introduced the template approach to be able to skip
the XSLT requirement, so opting for no-template will leave you in
probably an even worse spot...
> Woody has no notion of application model, as it stores field values in
> it's own data structure, which must be read and written to the
> application model. Work is underway in this area with a JXPath based
> binding.
>
yep
> XMLForm has only one markup, inspired by the W3C's XForms specification.
> This markup is more or less equivalent to the Woody template (it accepts
> foreign markup), which is instanciated ("augmented" would be better)
> with either the XMLFormTransformer/JXFormsTransformer or the
> JXFormsGenerator. Form fields contain XPath references to the data
> model, which can therefore have an arbitrary complexity.
>
> <my-opinion>
> XMLForm is way easier to setup to produce forms : a single file, a data
> model containing any mixture of objects handled by JXPath (JavaBeans,
> DOM elements, etc), XPath expressions everywhere, and you're done. But
> as soon as there's a need for data whose formatting is more than
> toString(), such as dates and float values, and even more in an I18Nized
> environment, XMLForm shows strong limitations, mainly related to lack of
> proper formatting functions in XPath.
>
> As JXPath supports extension functions, building a library of formatting
> functions can be a solution to circumvent XPath's reduced function set.
> But we'll see below that there's still a problem with parsing submitted
> form data.
>
> Woody, on the other hand, is more complicated to set up, as two files
> are needed (form definition and form template), with many
> cross-references (field IDs). But Woody shines for complicated
> formatting (see <convertor> directives) and I18N.
>
> 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
every identification of a concern indeed creates a new
responsibility to be taken up...
it has been the classic approach to have those different
responsibilties be expressed through different files/namespaces
(since multiple people could/should be involved, thus allowing to
map responsibilities onto person-attached files)
in this case this is leading us to 'woody requires a lot of
configuration' (your remark on this is not new and the upcoming
binding is likely to make it worse)
so any suggestions on sensibly cutting some of the config trouble
makes all the sense in the world.
the full process of getting anywhere has 2 aspects IMHO:
1/ identify all the concerns and separate wisely
2/ recombine sensibly in 'assmebled' typical usages that lower
the 80-20 itch for specific use cases... (in dream mode: generate
the different config needs from a single source that might be as
wild as JDBC metadata information?)
Woody up to now had some stress on 1/ (and I think we're not even
there) it sure makes sense to start considering 2/ if we want to
increase its 'usability'
> was only a schema defining datatypes and if fields were defined only in
> the template. Although there is a great probability that datatypes can
mmm, I might be missing what you are saying here...
looking at the woody-definition file what I see is exactly
identifying data-types, but then I'm talking about composite
types rather then only single-field types (e.g. the composite
'person' type vs. his 'birthday'-date-field)
so what I might be reading wrongly here is that you would like to
see the set of woody-form-definition files to evolve into some
'datatype-catalogue' ?
hopefully that would still include the composite types it
focusses on now, and just provides for a reuse mechanism of
forms-subforms and predefined 'field-typs'
> 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.
>
the envisioned use case behind the current split is exactly this:
if we consider the HTML and WML front end versions of the same
use cases then most likely the templates will need to change, but
the model could remain the same, no?
e.g. in the case of WML you'ld probably split the complete
editing of the one form-model over a wizard-managed series of
templates... (and/or you would choose not to show the optional
fields of the model)
to be hoped for is that both cases would reuse:
- label/help/hotkey info (i18n)
- validation rules on the complete form-model
- the logic loading and submitting the complete filled-in
'form-model' back to whatever back-end
other examples would include:
- deploying the web application in an ASP model where the
different tennant-companies only provide their templates (leaving
out optional fields, splitting large models in different
ways,...) and reuse the same back-end logic
- not use any template at all, but just expose a ReST-like URL
pattern people can send requests to, and receive an XML back?
I'ld have to admit these are not classic use cases but hardly to
be overlooked by a modern form framework if you ask me... again I
think the goal of being widely usable probably starts by
separating the different concerns in the core of the thing and
then carefully combining some of them back again in very
specific/targetted ways of deployment?
(I see current cocoon success as proof of that pudding)
> Reusing datatypes for different fields would also increase the overall
> application consistency : as of today, if two fields have the same
agree, dataype-catalogue and form-subform recursiveness for
composite types could achieve this
I still see the split from the template as having a different use.
so by using all these words to be intellectually correct I just
forget to stress that I very much share your fear for the
'heaviness'
How to get a very practical way to setup a one file config
approach for simple stuff :-( without compromising the wider
usage and flexibility?
suggestions welcome...
> datatype and constraints, these must be duplicated. This could also open
> the door to other schema languages (WXS, RNG, etc).
> </my-opinion>
>
> ---oOo---
>
>
> Population and validation
> -------------------------
>
> "Population" is the term used to designate the action of "filling" the
> data model with form-submitted data. "Validation" is the action of
> controlling that submitted data is valid, i.e. that is satisfies some
> syntactic and semantic constraints.
>
> Upon form submission, XMLForm traverses all request parameters and tries
> to set their value on the data model using JXPath. A feature allows to
> filter request parameters that are not part of the data model. If the
> data model was filled correctly, a validation is performed using
> Schematron. This allows to have finer-grained or inter-field controls,
> again using XPath expressions. Each of these two phases can produce
> violations, which are recorded in the Form object.
>
> Upon form submission, Woody traverses the form's widget tree, and each
> widget is responsible to parse the corresponding request parameter and
> validate it's value. Non-visual widgets are also provided to perform
> inter-field controls.
>
> <my-opinion>
> Here again, XMLForm is very easy to use but shows some strong
> limitations : because it's designed after XForms, XMLForm has no feature
> to specify how to parse form parameters (strings) into strongly typed
> data. So even basic parsing of e.g. dates is not possible, and
> locale-dependent parsing is clearly not possible.
>
> The Schematron validation has less restrictions since it deals with the
> populated data model, and thus on strongly typed data, if they could be
> parsed in the population phase.
>
> XMLForm also has what I consider a strong security weakness : the
> default request parameter filter rejects only special parameters such as
> "cocoon-action-*", which means that a request can be hacked that
> modifies a part of the data model that wasn't available as a form field.
> Considering that programmers are lazy (as I am), the form model will
> often be the actual business object. The consequences of providing a
> form to a user to update her location information can be catastrophic if
> the User class contains "address", "phoneNumber", but also
> "accessRights"...
>
> W3C XForms, which inspired XMLForm, is a client-side specification
> targeted at producing XML documents validated by a WXS (W3C XML Schema).
> But XMLForm is server-side, and doesn't enforce any particular schema
> language. This means that very few features of XForms are actually used
> except the form markup and that all has to be invented to produce a
> featured server-side form framework, particularily in this population &
> validation phase.
>
> Woody, by traversing the widget tree that was used to produce the form,
> doesn't have the security weakness of XMLForm since only parameters
> present in the produced form are considered. Also, it's strong parsing
> and I18N features make custom formatting really easy.
>
> But, being limited to the form's data model, complex validations
> involving form data and application data can be difficult to do with
> Woody and will need custom Java code.
>
yep, touching the 80-20 rule again
validation can become just really arbitrary complex so an escape
to provided java-code is not to be prevented IMHO
how much of the stronger validation will be available under
declarative form is then a matter of time, itches and scratches
> 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.
no real opinion here,
consistency with other stuff does make sense fo course
I might be wrong but the simple expression syntax is more a means
for reusing by assembling smaller parts of ready Java code
the alternative would be that you'ld need to write a Java class
that does that assembly and then the definition file would list
the full qualified classname of that new beast.
I don't know jexl enough to evaluate it for this usage... your
advise and hints are welcomed
> </my-opinion>
>
> ---oOo---
>
>
> Mapping to the application data model
> -------------------------------------
>
> A form is useless if its content cannot be mapped in some way to the
> application data model.
>
> XMLForm has no special provision for mapping form data to application
> data, but using JXPath makes it easy to fill any JavaBean or any DOM
> structure. Post-validation application behaviour can be added to either
> a subclass of AbstractXMLFormAction or in a flowscript.
>
> Woody currently does not provide anything to map form data to
> application data and all this must be coded either in a subclass of
> AbstractWoodyAction or in a flowscript. But there's work underway to add
> binding features to Woody, the first incarnation being based on JXPath.
>
> <my-opinion>
> XMLForm makes it easy (as pointed out above) for the lazy programmer to
> set the application data as the form model : mapping is then immediate
> and totally transparent. But along with the security problem mentioned
> above, this also means that when a form population & validation fails,
> it is very likely that some fields already have been modified,
> potentially leaving the data model in an inconsistent state.
>
> So the secure and clean solution is to use a form-specific data model (a
> JavaBean, DynaBean or XML DOM), but this requires then custom code to
> copy form data to the application data model, thus loosing the
> simplicity provided by JXPath.
>
> The ongoing work on Woody binding potentially allows a great range of
> target data models : the current JXPath binding will make it easy to map
> form data to an abitrary data structure, without XMLForm's limitations
> since parsed and strongly typed data will be stored in the application
> model. But we can also imagine other declarative bindings targetted at
> e.g. relational databases (no intermediate bean), EJBs, etc.
yes.
haven't looked into jxpath deep enough (just used it now, didn't
get into the internals yet) but my current feeling would be to
cater for these other backend-models by writing a specific
JXPathContext wrapper... as such the effort would be reusable
more widely?
> </my-opinion>
>
> ---oOo---
>
> I18N
> ----
>
> I18N features should be separated in two main areas :
> - I18Nization of form labels and item values (i.e. combobox labels)
> - I18Nization of textbox inputs, such as floating point numbers, dates,
> etc.
>
> For the first item, both XMLForm and Woody accept any foreign markup in
> widget labels, including <i18n:*> tags for use with the I18NTransformer.
> Woody lacks the equivalent to <xf:help> but this was recently discussed
> and should be added soon. XMLForm also allows labels and similar items
> to have their content fetched from the form model using a "ref"
> attribute. In that case, however, only characters are produced, and not
> mixed content.
>
> For the second item (i18nization of inputs), XMLForm has no support, as
> it hardly supports custom formats, as explained previously. Woody, on
> the other hand, has strong support for i18nization of inputs through its
> <convertor> tag that supports locale-specific patterns for formatting
> and parsing.
>
> <my-opinion>
> XMLForm's strong limitations for values formatting also apply to the
> i18n domain, whereas Woody not only provides strong support for value
> formatting, but also strong support for locale-dependend formatting.
>
> XMLForm's "ref" attribute on form labels allows messages to be part of
> the form model, and thus be dynamic, but I'm not sure this is of real
> use. And if it is, Woody may be able to provide an equivalent through
> nested tags in the <wd:label> element.
> </my-opinion>
>
> ---oOo---
>
> 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
mmm, lets make that
* puberty (flirting around with different ideas, allowing
oneselve to think the wrong ones even :-))
which means we still have to get through
* adolescence (forming the real identity, gradually taking up
responsibility towards early adopters) and
* maturity (living its life, being used) before we reach the
stage of
* aged wisdom (where we have removed everything there was to
remove, dear Antoine)
IMHO a number of good discussions and try out code could get us
fastly passed the first two stages
> featured enough, as the preferred form handling package in Cocoon.
>
> ---oOo---
>
> 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.
>
yes,
> 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.
>
> 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
above sounds like allowing 'default' values in the form definition
combined with the fact that the default values themselves would
be collected at form-instantiation time?
care to elaborate how you saw this happen?
> 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. 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).
>
> On the other hand, form->application binding cannot be live, since we
> must ensure that all submitted value are valid before modifying the
> application data.
>
IIUC you're giving a shot at redistributing the information from
the three current config files (form-defition, form-template and
form-binding) into two reshaped ones: form-template and
widget-datatype-catalogue?
maybe an example of how things would look like would give us more
to chew on?
> ---oOo---
>
>
> Thanks for reading so far. As I expect this post to generate lots of
> discussions, I suggest to create separate threads for particular
> subjects (particularily the final "proposals" chapter) in order to keep
> the discussion focused.
>
didn't do at this moment yet... if everything remains related I
prefer one combining thread then multiple separates (but that's
just me, I'll be happy to go with the flow and see some separate
[woody proposal] threads pop up)
> Sylvain
>
-marc=
--
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 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 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 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.
Re: [RT] Comparing Woody & XMLForm : towards a unified form
handling (long)
Posted by Bruno Dumon <br...@outerthought.org>.
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 Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Thanks for reading so far. As I expect this post to generate lots of
> discussions, I suggest to create separate threads for particular
> subjects (particularily the final "proposals" chapter) in order to keep
> the discussion focused.
>
Now, as we all know this is really a "dangerous" topic as such threads might
result in "personal" wars driven by the developers of each part involved.
But
as Sylvain already pointed out, it's not the reason for this thread to
create
a "form" war. And personally, I don't think this will happen in Cocoon.
So, I just wanted to throw in my comments as I can only read mails from time
to time and can't really participate in the threads.
One comment I think that is really import came from my collegue, Guido who
said "XForms is a client-side standard", so is it really worth to implement
it in the server? (I hope, it's ok to quote you, Guido...don't blame Guido
for this comment, just me if required!) I don't know the answer, but if
someone would force me to give one, I would tend to say "No".
Now, I really never looked at XMLForms or JXForms, but this doesn't say
anything about their quality etc, it's simply lack of time. But I looked a
little bit at Woody and personally I feel that Woody is really a great
approach by separating form definition from the template. Actually, I
started to implement the same for my test project, looked at Woody and
saw that it already does most of the things I need :)
My ideas of building web applications is a little bit different from what
we have in Cocoon today: In short, I'm thinking of "writing" (whatever
that means) a component for each web page. This component is the controller
for that page and connects (MVC) to the model. A template is used to
render the page. This template uses bindings to insert data into the
template.
The bindings are connected to the component which in turn has access to
the object model. Simple, or?
Example:
You have a component EditUser, that has a property user (= method getUser).
You have a template (shortened):
<form>
<input id="surname"/>
<input id="forename"/>
</form>
And the binding
<binding id="surname" type="TextInputField">
<value>user.surname</value>
</binding>
<binding id="forename" type="TextInputField">
<value>user.forename</value>
</binding>
When the template is processed by the component EditUser, the bindings
are evaluated. So e.g. for the input field surname the binding
"user.surname"
is resolved by invoking "getUser()" on the component and "getSurname()" on
the result (JXPath evaluation).
When the submitted form data comes to Cocoon again, the EditUser component
previously creating the form is the one in charge and delegates to the
two input fields. So (without validation) the user is get from the component
and setSurname() resp. setForename() is invoked on the user object.
The plan is to implement two layers of validation, the first layer in the
binding where I can already define obvious validation rules and the second
one in the model, because I think there are cases where only the model can
validate the date. So perhaps a validateSurname() (if existent) might
be invoked on the user.
This is more or less my current idea, and I'm trying to find some time
to see how this fits into Woody. Now, for this thread, let's not discuss
my ideas (I have most of them running already anyway ;) ), this thread
has a different topic. Perhaps my idea from above gives some aspects for
further
discussion on how to do it - if not, just ignore my ideas...
Speaking of woody, woody has the template already and the form definiton.
Now, what's missing is the binding between the form fields and your
business data.
But, I think this is realy an important thread for Cocoon. IMHO it doesn't
make too much sense to have two (or even more) approaches for the "real form
handling in Cocoon" implement at cocoon.apache.org. We should only provide
one good and working solution. Other implementations might exist somewhere
else, but should not here.
So, I think we are on the right track and perhaps combining somehow
both approaches into a new (third) one (named XMoody?) is the distant plan.
If you read this, you might get the impression that I'm +1 for woody and
-1 for XMLForms. But this is not true; I currently only know more about
woody than XMLForms and I have a similar idea, so perhaps I'm a little
bit to biased...
HTH
Carsten