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/04/01 16:18:30 UTC
[RT] Towards a new/another Forms Framework
The last few days I've been doing some thinking about form-handling.
I've been looking at the current solutions in Cocoon and IMHO there
still is room for improvement here and there. BTW, all this has nothing
to do with Ivelin's announcements, or with the fact that it's April 1
today. It's been stuff which has been brewing in our heads for quite
some time.
I'm not going to write a long proposal here (or at least I'll try not
to), but just some notes to make clear in what direction I'm thinking.
It should be possible to create a form just by describing its structure
in an XML file (lets call this a "form description"). I don't like the
fact that for XMLForm/Struts the user needs to write a bean just to hold
the form data. Apparently the struts people are realizing this and have
introduced something like 'DynaFormBeans' for this purpose. XMLForm
allows to use any DOM document as data-structure, but a DOM document can
only hold strings, and not dates or numbers.
(BTW, not using XML, XML validation, and XPath expressions as request
parameter names is a conscious choice, so what I'm describing here is
quite orthogonal to XMLForm, and leaning more towards
FormValidatorAction. XML will of course be used extensively for
publishing and configuration.)
A form description would basically list all the "widgets" on the form.
Each widget would have an associated type (string, date, long, decimal,
...), a number of validation rules, an id, and other required
configuration information depending on the specific widget
implementation. A form description would be parsed ones into an object
model, lets call this a "FormDefinition". Based on this FormDefinition,
a FormInstance can be created, which is a lightweight data-structure
that holds the instance-specific data for the form (the submitted values
and the validation results). So this would avoid the need to create a
bean, since from the user perspective, it would be as if the widgets
themselves hold their value.
Of course the kinds of widgets, validation rules, ... should be defined
by an interface so that anyone can provide additional implementations.
For the rendering part, each widget-instance should be able to produce
an XML representation of itself. Then either a generator or transformer
approach can be used to generate or merge-in the data.
The whole approach to think of a form as a set of widgets that can
themselves hold their value etc. also returns in JSF (Java Server
Faces), so that JSR can also be used for inspiration.
For those cases where the user just wants to make a form above some
database-table, EJB or Web-service, we could introduce some
mapping-concept that allows to map database fields or EJB properties to
widgets on the forms, so that load and store operations can be done
without any coding.
Some other things that should be possible with the form-framework:
* repeating (iterating) structures (to create tables etc.)
* enabling/disabling widgets based on the values of other widgets.
* event handling: when user selects an item or changes a value, do an
automatic form submit and call an event handler on the server
* pose no requirements on the structure of URL's
* should be usable together with flowscript, but using flowscript
should not be a requirement
* ...
All the above are as of yet only ideas, there's no code yet, but once it
gets this far I'd like to add it as a block to Cocoon CVS.
Thoughts?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Towards a new/another Forms Framework
Posted by joern turner <jo...@web.de>.
hello Bruno,
have a look at the W3C XForms CR http://w3.org/markup/forms which
describes most of what you're mentioning and is the next generation of
web-forms. it's expected to become Final Recommendation in summer.
Joern Turner
Bruno Dumon wrote:
> The last few days I've been doing some thinking about form-handling.
> I've been looking at the current solutions in Cocoon and IMHO there
> still is room for improvement here and there. BTW, all this has nothing
> to do with Ivelin's announcements, or with the fact that it's April 1
> today. It's been stuff which has been brewing in our heads for quite
> some time.
>
> I'm not going to write a long proposal here (or at least I'll try not
> to), but just some notes to make clear in what direction I'm thinking.
>
> It should be possible to create a form just by describing its structure
> in an XML file (lets call this a "form description"). I don't like the
> fact that for XMLForm/Struts the user needs to write a bean just to hold
> the form data. Apparently the struts people are realizing this and have
> introduced something like 'DynaFormBeans' for this purpose. XMLForm
> allows to use any DOM document as data-structure, but a DOM document can
> only hold strings, and not dates or numbers.
>
> (BTW, not using XML, XML validation, and XPath expressions as request
> parameter names is a conscious choice, so what I'm describing here is
> quite orthogonal to XMLForm, and leaning more towards
> FormValidatorAction. XML will of course be used extensively for
> publishing and configuration.)
>
> A form description would basically list all the "widgets" on the form.
> Each widget would have an associated type (string, date, long, decimal,
> ...), a number of validation rules, an id, and other required
> configuration information depending on the specific widget
> implementation. A form description would be parsed ones into an object
> model, lets call this a "FormDefinition". Based on this FormDefinition,
> a FormInstance can be created, which is a lightweight data-structure
> that holds the instance-specific data for the form (the submitted values
> and the validation results). So this would avoid the need to create a
> bean, since from the user perspective, it would be as if the widgets
> themselves hold their value.
>
> Of course the kinds of widgets, validation rules, ... should be defined
> by an interface so that anyone can provide additional implementations.
>
> For the rendering part, each widget-instance should be able to produce
> an XML representation of itself. Then either a generator or transformer
> approach can be used to generate or merge-in the data.
>
> The whole approach to think of a form as a set of widgets that can
> themselves hold their value etc. also returns in JSF (Java Server
> Faces), so that JSR can also be used for inspiration.
>
> For those cases where the user just wants to make a form above some
> database-table, EJB or Web-service, we could introduce some
> mapping-concept that allows to map database fields or EJB properties to
> widgets on the forms, so that load and store operations can be done
> without any coding.
>
> Some other things that should be possible with the form-framework:
> * repeating (iterating) structures (to create tables etc.)
> * enabling/disabling widgets based on the values of other widgets.
> * event handling: when user selects an item or changes a value, do an
> automatic form submit and call an event handler on the server
> * pose no requirements on the structure of URL's
> * should be usable together with flowscript, but using flowscript
> should not be a requirement
> * ...
>
> All the above are as of yet only ideas, there's no code yet, but once it
> gets this far I'd like to add it as a block to Cocoon CVS.
>
> Thoughts?
>
Re: [RT] Towards a new/another Forms Framework
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-04-02 at 15:25, Sylvain Wallez wrote:
[...]
> Since everybody is throwing ideas here in a somehow unordered way, let
> me throw in mine, considering my experience with our home-grown forms
> framework that we use since late 2000.
>
> First of all, we use a model to define "entities", which can be either a
> business object or a form. An entity defined by a set of fields, each
> field having a type. A field can also be a relation to some other entity
> (more on this later). This model is more like XMI than like XMLSchema.
Hmm, I think these entities actually have a lot in common with was I
thinking of for my "form description", except that it's not focussed on
forms only.
>
> On this model, we have different families of mappings : forms mapping,
> persistence mapping (to store e.g. in a database), javabean mapping
> (relation to the object model), etc.
>
> The form mapping, and IMO this is where XMLForm has strong weaknesses,
I think XMLForm just follows the Struts-design here. In struts, you are
supposed to make all form bean properties that correspond to HTML
textboxes of type String. This is because the purpose of the form bean
is to hold the data entered in the form -- which may be invalid dates or
numbers.
In Struts, it is then the purpose of the validator to check that the
dates or numbers are indeed valid dates or numbers (but it leaves them
as strings in the form bean).
Once everything's valid, some other (user-written) code is supposed to
read the values from the form bean, convert them to actual date or
number objects, and then apply them to the business bean.
(I got the above information from reading some messages by Craig
McClanahan on struts-dev, so it's pretty authoritive)
A problem in the above scenario is that both the validator and the
conversion-code need to be aware of the user's locale and the formatting
pattern used. And the same when you fill up a form bean with data from a
business bean. I don't know how or if struts helps here.
That's why in my form ideas I would let a field hold both the string
value and the converted object, and let conversion happen as part of the
validation. If "other code" then reads the field's value, it doesn't
need to do any conversion anymore.
Just wondering: in your form-framework, if conversion of the
user-entered text to e.g. a date fails, where do you store the
user-entered text for re-display on the form? Maybe as part of the
validation error?
> defines formats for either datatypes (int, date, etc). or each of the
> fields. We also make a difference between input and output formats. A
> date for example, can be displayed as "Wednesday 2 april 2003" but input
> as "04-2-2003" on the same screen. Formats can also be i18n-ized,
> meaning the previous example on a french browser will be displayed as
> "Mercredi 3 avril 2003" and input as "2/4/2003".
Agreed on the input and output formats -- we have the same in xReporter.
>
> Since fields can also be defined as relation to other entities, we can
> use this information to automatically populate pop-menus and lists. This
> is a little bit like the "beaff.enumeration" in Bertrand's proposal.
>
> Once we have an entity model an some associated formats, we can feed a
> view with it. The view contains some "widgets" related to either a
> datatype or a particular field. This allows for example to have any
> input associated to a date field automatically converted to an input
> with a fancy calendar popup and some client-side syntactic validation;
>
> When the form is submitted, the server-side validation framework parses
> each input with the format defined in the mapping, and feeds the data
> model, reporting any violation.
>
What I've mostly learned from your explanation is that what I called the
"form description" is in your framework separated out in entity
definitions and a form mapping. (I'm undecided yet on wheter I like this
better -- need to sleep a night over it)
>
> Now back to the discussion.
>
> In the above, the important features that are currently missing in
> XMLForm are mainly the ability to define the input/outpout format for
> non-trivial datatypes such as dates.
>
> Also, we must be able to define a forms model through a configuration
> file, avoiding the need to write Java code for simple cases. DynaBeans
> are IMO a good solution for this, and are becoming the de-facto standard
> for dynamically typed objects at least in the Apache-Java world.
>
> Next, I would like Cocoon's form solution to be based on existing
> components. Form validation is a sooo common problem that we should
> avoid as far as possible to reinvent the wheel and concentrate on the
> Cocoon-specific part of form handling, which IMO is mainly in the view
> area : form population, widgets, etc.
>
> A good candidate seems to be commons-validator : a lot of work is going
> on there, and joining forces will lead to a more featureful package than
> if we do our own. Also, as I stated in a previous post, this promotes
> cross-project collaboration and will ease the migration of users between
> the various Apache frameworks. And this can only be good for Cocoon.
I completely agree on the reuse and joining forces, as long as it fits
with what we're looking for.
I'm also wondering how struts (and related to this, dynabeans and
commons-validator) will evolve in the future, since from what I
understood from struts-dev, the long-term plan is to migrate to JSF,
which has its own validation system, and doesn't have the concept of
form beans.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Towards a new/another Forms Framework
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bruno Dumon wrote:
>The last few days I've been doing some thinking about form-handling.
>I've been looking at the current solutions in Cocoon and IMHO there
>still is room for improvement here and there. BTW, all this has nothing
>to do with Ivelin's announcements, or with the fact that it's April 1
>today. It's been stuff which has been brewing in our heads for quite
>some time.
>
>I'm not going to write a long proposal here (or at least I'll try not
>to), but just some notes to make clear in what direction I'm thinking.
>
Since everybody is throwing ideas here in a somehow unordered way, let
me throw in mine, considering my experience with our home-grown forms
framework that we use since late 2000.
First of all, we use a model to define "entities", which can be either a
business object or a form. An entity defined by a set of fields, each
field having a type. A field can also be a relation to some other entity
(more on this later). This model is more like XMI than like XMLSchema.
On this model, we have different families of mappings : forms mapping,
persistence mapping (to store e.g. in a database), javabean mapping
(relation to the object model), etc.
The form mapping, and IMO this is where XMLForm has strong weaknesses,
defines formats for either datatypes (int, date, etc). or each of the
fields. We also make a difference between input and output formats. A
date for example, can be displayed as "Wednesday 2 april 2003" but input
as "04-2-2003" on the same screen. Formats can also be i18n-ized,
meaning the previous example on a french browser will be displayed as
"Mercredi 3 avril 2003" and input as "2/4/2003".
Since fields can also be defined as relation to other entities, we can
use this information to automatically populate pop-menus and lists. This
is a little bit like the "beaff.enumeration" in Bertrand's proposal.
Once we have an entity model an some associated formats, we can feed a
view with it. The view contains some "widgets" related to either a
datatype or a particular field. This allows for example to have any
input associated to a date field automatically converted to an input
with a fancy calendar popup and some client-side syntactic validation;
When the form is submitted, the server-side validation framework parses
each input with the format defined in the mapping, and feeds the data
model, reporting any violation.
Now back to the discussion.
In the above, the important features that are currently missing in
XMLForm are mainly the ability to define the input/outpout format for
non-trivial datatypes such as dates.
Also, we must be able to define a forms model through a configuration
file, avoiding the need to write Java code for simple cases. DynaBeans
are IMO a good solution for this, and are becoming the de-facto standard
for dynamically typed objects at least in the Apache-Java world.
Next, I would like Cocoon's form solution to be based on existing
components. Form validation is a sooo common problem that we should
avoid as far as possible to reinvent the wheel and concentrate on the
Cocoon-specific part of form handling, which IMO is mainly in the view
area : form population, widgets, etc.
A good candidate seems to be commons-validator : a lot of work is going
on there, and joining forces will lead to a more featureful package than
if we do our own. Also, as I stated in a previous post, this promotes
cross-project collaboration and will ease the migration of users between
the various Apache frameworks. And this can only be good for Cocoon.
Ah, and special thanks to Stephen Burns for his version of XMLForm based
on commons-validator. This definitely has go in our code base.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Towards a new/another Forms Framework
Posted by Andrew Savory <an...@luminas.co.uk>.
On Tue, 1 Apr 2003, Bruno Dumon wrote:
> Schema with a capital S: are you talking about W3C XML Schemas?
Yes.
> > This is basically because we're getting lots
> > of requests to build "ingestion interfaces" that allow people to add
> > content to a database based on a given metadata standard (which is
> > provided as a schema). I think there's a lot of crossover between our
> > schema-based forms plan and your RT.
>
> Yep, though I think that what you'd like to have layers on top of the
> form framework: it could be possible to generate form descriptions from
> the schema information, but not all forms are always automatically
> generated from a schema.
Definitely. A standard form framework descriptor file would make sense,
then we could (for example) use XSLT to transform Schemas into
descriptors.
Another useful feature (here we go with creeping features already!) would
be the concept of "controlled vocabularies", ie being able to tie a
predetermined set of options to a given form control. I guess this would
be a feature of the mapping-concept.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
Re: [RT] Towards a new/another Forms Framework
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-04-01 at 16:34, Andrew Savory wrote:
> Hi Bruno,
>
> On Tue, 1 Apr 2003, Bruno Dumon wrote:
>
> > It should be possible to create a form just by describing its structure
> > in an XML file (lets call this a "form description"). I don't like the
> > fact that for XMLForm/Struts the user needs to write a bean just to hold
> > the form data. Apparently the struts people are realizing this and have
> > introduced something like 'DynaFormBeans' for this purpose. XMLForm
> > allows to use any DOM document as data-structure, but a DOM document can
> > only hold strings, and not dates or numbers.
>
> Interesting. We've been thinking long and hard recently about whether or
> not it's possible to dynamically generate a form (or wizard-style set of
> forms) from a given Schema.
Schema with a capital S: are you talking about W3C XML Schemas?
> This is basically because we're getting lots
> of requests to build "ingestion interfaces" that allow people to add
> content to a database based on a given metadata standard (which is
> provided as a schema). I think there's a lot of crossover between our
> schema-based forms plan and your RT.
Yep, though I think that what you'd like to have layers on top of the
form framework: it could be possible to generate form descriptions from
the schema information, but not all forms are always automatically
generated from a schema.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Towards a new/another Forms Framework
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi Bruno,
On Tue, 1 Apr 2003, Bruno Dumon wrote:
> It should be possible to create a form just by describing its structure
> in an XML file (lets call this a "form description"). I don't like the
> fact that for XMLForm/Struts the user needs to write a bean just to hold
> the form data. Apparently the struts people are realizing this and have
> introduced something like 'DynaFormBeans' for this purpose. XMLForm
> allows to use any DOM document as data-structure, but a DOM document can
> only hold strings, and not dates or numbers.
Interesting. We've been thinking long and hard recently about whether or
not it's possible to dynamically generate a form (or wizard-style set of
forms) from a given Schema. This is basically because we're getting lots
of requests to build "ingestion interfaces" that allow people to add
content to a database based on a given metadata standard (which is
provided as a schema). I think there's a lot of crossover between our
schema-based forms plan and your RT.
> Thoughts?
Where do we start? ;-)
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
RE: [RT] Towards a new/another Forms Framework
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Wednesday, April 02, 2003 10:44 AM
> Robert Koberg wrote:
> > Why not use some schema dialect (XML Schema seems to have achieved
> critical
> > mass???) and add a form namespace that indicates the widgets. You get
> > datatyping for free.
>
> I don't get it. can you elaborate more?
I just sent a message to the forrest list to get a discussion this going.
Hopefully it can continue and the way to do this will be clear.
Best,
-Rob
>
> Stefano.
Re: [RT] Towards a new/another Forms Framework
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
> Hi,
>
>
>>-----Original Message-----
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>Sent: Wednesday, April 02, 2003 3:25 AM
>>To: cocoon-dev@xml.apache.org
>
>
>
>>But I also want to point out something that I'll need a lot in the
>>future: the XML datatype in a form.
>>
>>I would like to be able to submit an entire XML island into a form
>>textarea and have the server-side form handler be able to validate it
>>against a particular schema.
>
>
> But that would be invalid markup. It would be better to use a PUT (I am
> still using a POST with a hidden INPUT...). We do the XML Schema validation
> client-side and just send the updated XML back to the server for storage.
It would be better to use WebDAV directly, but this isn't a perfect world.
yes, i was thinking about a POST with a hidden textarea or input.
>>That would be *KILLER* for serious content management solutions where
>>all the data aggregation from the document can be done via javascript on
>>the client side directly (and it's pretty dead easy also to make
>>transparently portable for 6th generation browsers!).
>
>
> I am confused. In the previous paragraph you say you want to submit it to
> the server for validation. But in the above para you talk about client-side
> validation?
No, about "client side construction". And even if you do validation on
the client side, you still have to do it on the server side to avoid
security holes.
> Why not use some schema dialect (XML Schema seems to have achieved critical
> mass???) and add a form namespace that indicates the widgets. You get
> datatyping for free.
I don't get it. can you elaborate more?
Stefano.
RE: [RT] Towards a new/another Forms Framework
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Wednesday, April 02, 2003 3:25 AM
> To: cocoon-dev@xml.apache.org
> But I also want to point out something that I'll need a lot in the
> future: the XML datatype in a form.
>
> I would like to be able to submit an entire XML island into a form
> textarea and have the server-side form handler be able to validate it
> against a particular schema.
But that would be invalid markup. It would be better to use a PUT (I am
still using a POST with a hidden INPUT...). We do the XML Schema validation
client-side and just send the updated XML back to the server for storage.
>
> That would be *KILLER* for serious content management solutions where
> all the data aggregation from the document can be done via javascript on
> the client side directly (and it's pretty dead easy also to make
> transparently portable for 6th generation browsers!).
I am confused. In the previous paragraph you say you want to submit it to
the server for validation. But in the above para you talk about client-side
validation?
Why not use some schema dialect (XML Schema seems to have achieved critical
mass???) and add a form namespace that indicates the widgets. You get
datatyping for free.
?
-Rob
>
> This is also why I'm happy to see XMLForm to move into a block: the
> XForm-inflicted mindset is too limiting for what I'm going to need in
> the future for roundtrippable data.
>
> Stefano.
Re: [RT] Towards a new/another Forms Framework
Posted by Stefano Mazzocchi <st...@apache.org>.
Bruno Dumon wrote:
> I think this is where my approach differs from most of the other form
> solutions discussed here: I'm not interested in being able to edit any
> XML instance governed by any WXS or RNG schema.
>
> I see a form as a collection of widgets holding strongly typed data
> (strings, numbers, dates, and so on). There will be one special type of
> widget that is a collection of a set of other widgets. So a form can
> become a tree structure of widgets, each widget containing some data.
>
> Such a form _could_ be populated with data from an XML document, and
> once the form is succesfully submitted, its data could be applied back
> to the XML document. But it could be used for any other purpose as well.
>
> So in a certain sense, you could see the widget-tree as some kind of
> limitted, strongly-typed XML tree, and the form description could be
> seen as a special kind of XML schema. But I don't see any need to
> actually use XML datastructures and validation here.
I totally agree with your vision of separating the 'concept of a form'
from the XForm-inflicted XML-driven mental perception.
let me not miss the oppurtunity to remind you all that XForm is jet
another language invented for the client side and that it's not
currently supported by *NO* mainstream browser whatsoever. Nor I think
it will in the near future, given that everybody is moving toward XHTML
form modules.
But I also want to point out something that I'll need a lot in the
future: the XML datatype in a form.
I would like to be able to submit an entire XML island into a form
textarea and have the server-side form handler be able to validate it
against a particular schema.
That would be *KILLER* for serious content management solutions where
all the data aggregation from the document can be done via javascript on
the client side directly (and it's pretty dead easy also to make
transparently portable for 6th generation browsers!).
This is also why I'm happy to see XMLForm to move into a block: the
XForm-inflicted mindset is too limiting for what I'm going to need in
the future for roundtrippable data.
Stefano.
Re: [RT] Towards a new/another Forms Framework
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-04-02 at 05:32, ivelin wrote:
> Bruno,
>
> It is funny enough that it's April 1, but your email reminds me about the
> one Torsten sent out about a year ago, not on April 1 ;)
> http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg14370.html
>
Maybe in spirit, but not in concrete ideas (see further on...)
>
> > It should be possible to create a form just by describing its structure
> > in an XML file (lets call this a "form description"). I don't like the
> > fact that for XMLForm/Struts the user needs to write a bean just to hold
> > the form data. Apparently the struts people are realizing this and have
> > introduced something like 'DynaFormBeans' for this purpose. XMLForm
> > allows to use any DOM document as data-structure, but a DOM document can
> > only hold strings, and not dates or numbers.
>
> Since XMLForm uses JXPath, it also supports DynaBeans
> http://www.mail-archive.com/general@jakarta.apache.org/msg07487.html
>
> If I am not completely mistaken, most of your email describes in detail
> features of an XForms inplementation: cross field dependencies, event
> handling, generating instances from XSD. I think that Chiba is probably
> (again) your best bet in this regard.
> It has a tool which generates XForms documents and instances from XML
> Schemas.
I think this is where my approach differs from most of the other form
solutions discussed here: I'm not interested in being able to edit any
XML instance governed by any WXS or RNG schema.
I see a form as a collection of widgets holding strongly typed data
(strings, numbers, dates, and so on). There will be one special type of
widget that is a collection of a set of other widgets. So a form can
become a tree structure of widgets, each widget containing some data.
Such a form _could_ be populated with data from an XML document, and
once the form is succesfully submitted, its data could be applied back
to the XML document. But it could be used for any other purpose as well.
So in a certain sense, you could see the widget-tree as some kind of
limitted, strongly-typed XML tree, and the form description could be
seen as a special kind of XML schema. But I don't see any need to
actually use XML datastructures and validation here.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Towards a new/another Forms Framework
Posted by ivelin <iv...@apache.org>.
Bruno,
It is funny enough that it's April 1, but your email reminds me about the
one Torsten sent out about a year ago, not on April 1 ;)
http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg14370.html
> It should be possible to create a form just by describing its structure
> in an XML file (lets call this a "form description"). I don't like the
> fact that for XMLForm/Struts the user needs to write a bean just to hold
> the form data. Apparently the struts people are realizing this and have
> introduced something like 'DynaFormBeans' for this purpose. XMLForm
> allows to use any DOM document as data-structure, but a DOM document can
> only hold strings, and not dates or numbers.
Since XMLForm uses JXPath, it also supports DynaBeans
http://www.mail-archive.com/general@jakarta.apache.org/msg07487.html
If I am not completely mistaken, most of your email describes in detail
features of an XForms inplementation: cross field dependencies, event
handling, generating instances from XSD. I think that Chiba is probably
(again) your best bet in this regard.
It has a tool which generates XForms documents and instances from XML
Schemas.
The team is also working on a graphical web tool to visually create wizards
and other form pages.
The discussion should be probably directed toward whether Cocoon needs to go
with an all XForms server side solution or stick to a simpler but proven
one. Maybe both in different branches.
Ivelin
Re: [RT] Towards a new/another Forms Framework
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-04-01 at 17:04, Torsten Curdt wrote:
> Geoff Howard wrote:
> > Very interesting - do you envision it covering client/server side
> > validation?
Server side primarely, but not excluding client side.
>
> Just want to make sure: had anyone had a look into precept?
> Maybe at least the examples?
I'll take a look at it.
>
> It's not even close to be more than POC. But the vision was
> to build forms with your favorite schema editing tool for the
> model definiton.
I assume you're talking about XML schema languages here (WXS, Relax NG,
...)?
I find this approach rather complex and error-prone for data-entry
forms. XML Schema languages tend to be mainly strong in checking the
structure of XML documents, and not so much in checking the values of
individual text nodes. I know XML Schemas have a datatype library, but
you can't expect users (using different locales) to enter their numbers
in IEEE format or enter dates like "2003-04-01". But maybe I'm
misunderstanding something here...
> And then use a XML editor or IDE for the
> views. One of our interns wrote a POC swing application
> to drag-and-drop the controls into the views.
> And I still have a table renderer transformer on my machine
> that calculates a table layout for any given controls by
> it's x and y coordinates.
>
> It also already provides the hooks for client+server side
> validation. Just NYI.
>
> Especially database mapping is still an issue. And it has
> no flow support yet.
Database mapping and flow seem like seperate issues for me, so that's
not really a problem.
> But maybe we can steel at least some
> ideas for something new?!
Yep, I'll certainly take a more detailed look into it.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Towards a new/another Forms Framework
Posted by Torsten Curdt <tc...@dff.st>.
Geoff Howard wrote:
> Very interesting - do you envision it covering client/server side
> validation?
Just want to make sure: had anyone had a look into precept?
Maybe at least the examples?
It's not even close to be more than POC. But the vision was
to build forms with your favorite schema editing tool for the
model definiton. And then use a XML editor or IDE for the
views. One of our interns wrote a POC swing application
to drag-and-drop the controls into the views.
And I still have a table renderer transformer on my machine
that calculates a table layout for any given controls by
it's x and y coordinates.
It also already provides the hooks for client+server side
validation. Just NYI.
Especially database mapping is still an issue. And it has
no flow support yet. But maybe we can steel at least some
ideas for something new?!
--
Torsten
Re: [RT] Towards a new/another Forms Framework
Posted by Geoff Howard <co...@leverageweb.com>.
Very interesting - do you envision it covering client/server side validation?
Geoff
At 09:18 AM 4/1/2003, you wrote:
>The last few days I've been doing some thinking about form-handling.
>I've been looking at the current solutions in Cocoon and IMHO there
>still is room for improvement here and there. BTW, all this has nothing
>to do with Ivelin's announcements, or with the fact that it's April 1
>today. It's been stuff which has been brewing in our heads for quite
>some time.
>
>I'm not going to write a long proposal here (or at least I'll try not
>to), but just some notes to make clear in what direction I'm thinking.
>
>It should be possible to create a form just by describing its structure
>in an XML file (lets call this a "form description"). I don't like the
>fact that for XMLForm/Struts the user needs to write a bean just to hold
>the form data. Apparently the struts people are realizing this and have
>introduced something like 'DynaFormBeans' for this purpose. XMLForm
>allows to use any DOM document as data-structure, but a DOM document can
>only hold strings, and not dates or numbers.
>
>(BTW, not using XML, XML validation, and XPath expressions as request
>parameter names is a conscious choice, so what I'm describing here is
>quite orthogonal to XMLForm, and leaning more towards
>FormValidatorAction. XML will of course be used extensively for
>publishing and configuration.)
>
>A form description would basically list all the "widgets" on the form.
>Each widget would have an associated type (string, date, long, decimal,
>...), a number of validation rules, an id, and other required
>configuration information depending on the specific widget
>implementation. A form description would be parsed ones into an object
>model, lets call this a "FormDefinition". Based on this FormDefinition,
>a FormInstance can be created, which is a lightweight data-structure
>that holds the instance-specific data for the form (the submitted values
>and the validation results). So this would avoid the need to create a
>bean, since from the user perspective, it would be as if the widgets
>themselves hold their value.
>
>Of course the kinds of widgets, validation rules, ... should be defined
>by an interface so that anyone can provide additional implementations.
>
>For the rendering part, each widget-instance should be able to produce
>an XML representation of itself. Then either a generator or transformer
>approach can be used to generate or merge-in the data.
>
>The whole approach to think of a form as a set of widgets that can
>themselves hold their value etc. also returns in JSF (Java Server
>Faces), so that JSR can also be used for inspiration.
>
>For those cases where the user just wants to make a form above some
>database-table, EJB or Web-service, we could introduce some
>mapping-concept that allows to map database fields or EJB properties to
>widgets on the forms, so that load and store operations can be done
>without any coding.
>
>Some other things that should be possible with the form-framework:
> * repeating (iterating) structures (to create tables etc.)
> * enabling/disabling widgets based on the values of other widgets.
> * event handling: when user selects an item or changes a value, do an
>automatic form submit and call an event handler on the server
> * pose no requirements on the structure of URL's
> * should be usable together with flowscript, but using flowscript
>should not be a requirement
> * ...
>
>All the above are as of yet only ideas, there's no code yet, but once it
>gets this far I'd like to add it as a block to Cocoon CVS.
>
>Thoughts?
>
>--
>Bruno Dumon http://outerthought.org/
>Outerthought - Open Source, Java & XML Competence Support Center
>bruno@outerthought.org bruno@apache.org
Re: [RT] Towards a new/another Forms Framework
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 2 avr 2003, à 00:02 Europe/Zurich, Neeme Praks a écrit :
> ...I also read that doc and couldn't really figure out the distinction
> between data-types and field-types... both of them can be used in
> field declarations, so where exactly is the difference?
The idea is that data-type is a more general concept than field-type.
For example, several field-types could refer to the same data-type,
maybe overriding some of the data-type attributes.
If you're thinking about form fields and what Bruno calls "form beans"
the boundary can be hard to see, but data-types could also be used to
automatically generate "business beans" classes or mappings to such
classes.
-Bertrand
Re: [RT] Towards a new/another Forms Framework
Posted by Neeme Praks <ne...@apache.org>.
Bruno Dumon ::
>>A while ago I suggested something along these lines
>>(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103786946103965&w=2),
>>there was little response at the time and I didn't follow with concrete
>>code but you might find it useful.
>>
>>
>Very interesting, the approach with the "data-types" and "field-types"
>corresponds a lot with what I've been thinking of.
>
I also read that doc and couldn't really figure out the distinction
between data-types and field-types... both of them can be used in field
declarations, so where exactly is the difference?
Neeme
Re: [RT] Towards a new/another Forms Framework
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
<snip mode="agree"/>
Le Mardi, 1 avr 2003, à 17:24 Europe/Zurich, Bruno Dumon a écrit :
> ...That's basically the one thing where
> we differ in approach: I would just let the fields remember their
> value,
> instead of requiring some bean here, so the data and the form are the
> same.
ok - makes sense with the distinction between "form beans" and
"business beans" that you mention.
> ... Once the form is succesfully
> validated, some action code should then apply the data gathered in the
> form bean to the business bean.
Make sense but this is yet another mapping IMHO ;-)
can be trivial based on field names/reflection but still exists -
another reason for a data-dictionary based approach.
> ...The validation I have in mind is mostly things
> like checking that for number fields, the user entered a number and not
> some random string (thus checking that the type conversion is
> succesful), maybe check length of strings, etc.
ok.
-Bertrand
Re: [RT] Towards a new/another Forms Framework
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-04-01 at 16:50, Bertrand Delacretaz wrote:
> Le Mardi, 1 avr 2003, à 16:18 Europe/Zurich, Bruno Dumon a écrit :
>
> > ...It should be possible to create a form just by describing its
> > structure
> > in an XML file (lets call this a "form description"). I don't like the
> > fact that for XMLForm/Struts the user needs to write a bean just to
> > hold
> > the form data...
>
> Maybe going all the way down to a kind of "data dictionary" that
> describes the data model and tools to work with it would be even better?
>
> A while ago I suggested something along these lines
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103786946103965&w=2),
> there was little response at the time and I didn't follow with concrete
> code but you might find it useful.
Very interesting, the approach with the "data-types" and "field-types"
corresponds a lot with what I've been thinking of.
>
> I think you need three mappings to write a complete web application,
> and these should ideally all derive from the same definitions (what I
> call the data dictionary). Might not be doable right away, but
> designing the dictionary for these uses could be very useful later on
> (need to check the YAGNImeter though):
>
> -mapping from data to XML forms
the 'data' would then be the beans? That's basically the one thing where
we differ in approach: I would just let the fields remember their value,
instead of requiring some bean here, so the data and the form are the
same.
> -mapping from request attributes to data (type conversions, key
> lookups, etc.)
> -bidirectional mapping from data to storage (database or XML)
I see this last one as an optional and distinct part (not all forms are
used to edit some entity), but definitely useful for crud-type
applications.
>
> Not to mention other things that can also be stored in a data
> dictionary, like internationalized fields names, links to help pages,
> hints for acccessiblity, etc. Some of this belongs to forms, but a lot
> of it is broader in range than forms, hence the idea of central
> repository for this information, not limited to forms.
>
> Of course form definitions are needed at some point, but with a system
> based on a data dictionary they could be very simple, just listing
> which fields go in which form. Also useful when a field is used in
> several forms.
Yep, I think I agree with this datatype - formfield separation.
>
> > ...a FormInstance can be created, which is a lightweight data-structure
> > that holds the instance-specific data for the form (the submitted
> > values
> > and the validation results). So this would avoid the need to create a
> > bean, since from the user perspective, it would be as if the widgets
> > themselves hold their value.
>
> Would be cool but won't you need beans anyway for storage, java-based
> validations and the like?
Sure, but that would be "business beans", not form beans. I've done some
reading in the struts documentation, and they made a very clear
distinction over there between "business beans" and "form beans". The
form beans are just some instance variables with getters/setters for
them, but contain no business logic. Once the form is succesfully
validated, some action code should then apply the data gathered in the
form bean to the business bean.
>
> I'm not sure if script-based validations are good enough, I prefer to
> write the heavy-duty validation stuff in code that is independent from
> the web application framework (but that's a personal preference).
Sure, I agree with this. The validation I have in mind is mostly things
like checking that for number fields, the user entered a number and not
some random string (thus checking that the type conversion is
succesful), maybe check length of strings, etc.
>
> >
> > ....For those cases where the user just wants to make a form above some
> > database-table, EJB or Web-service, we could introduce some
> > mapping-concept that allows to map database fields or EJB properties to
> > widgets on the forms, so that load and store operations can be done
> > without any coding.
>
> That's where I think a data dictionary can help: forms AND database
> fields can be derived from it, it contains more info than just the
> forms definitions.
>
> <snip-other-good-ideas/>
>
> I don't know the existing XMLForm stuff in as much detail as I'd like
> (haven't actually used it yet), so some of my comments might be
> irrelevant, but hopefully this helps!
Sure helps a lot!
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Towards a new/another Forms Framework
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 1 avr 2003, à 16:18 Europe/Zurich, Bruno Dumon a écrit :
> ...It should be possible to create a form just by describing its
> structure
> in an XML file (lets call this a "form description"). I don't like the
> fact that for XMLForm/Struts the user needs to write a bean just to
> hold
> the form data...
Maybe going all the way down to a kind of "data dictionary" that
describes the data model and tools to work with it would be even better?
A while ago I suggested something along these lines
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103786946103965&w=2),
there was little response at the time and I didn't follow with concrete
code but you might find it useful.
I think you need three mappings to write a complete web application,
and these should ideally all derive from the same definitions (what I
call the data dictionary). Might not be doable right away, but
designing the dictionary for these uses could be very useful later on
(need to check the YAGNImeter though):
-mapping from data to XML forms
-mapping from request attributes to data (type conversions, key
lookups, etc.)
-bidirectional mapping from data to storage (database or XML)
Not to mention other things that can also be stored in a data
dictionary, like internationalized fields names, links to help pages,
hints for acccessiblity, etc. Some of this belongs to forms, but a lot
of it is broader in range than forms, hence the idea of central
repository for this information, not limited to forms.
Of course form definitions are needed at some point, but with a system
based on a data dictionary they could be very simple, just listing
which fields go in which form. Also useful when a field is used in
several forms.
> ...a FormInstance can be created, which is a lightweight data-structure
> that holds the instance-specific data for the form (the submitted
> values
> and the validation results). So this would avoid the need to create a
> bean, since from the user perspective, it would be as if the widgets
> themselves hold their value.
Would be cool but won't you need beans anyway for storage, java-based
validations and the like?
I'm not sure if script-based validations are good enough, I prefer to
write the heavy-duty validation stuff in code that is independent from
the web application framework (but that's a personal preference).
>
> ....For those cases where the user just wants to make a form above some
> database-table, EJB or Web-service, we could introduce some
> mapping-concept that allows to map database fields or EJB properties to
> widgets on the forms, so that load and store operations can be done
> without any coding.
That's where I think a data dictionary can help: forms AND database
fields can be derived from it, it contains more info than just the
forms definitions.
<snip-other-good-ideas/>
I don't know the existing XMLForm stuff in as much detail as I'd like
(haven't actually used it yet), so some of my comments might be
irrelevant, but hopefully this helps!
-Bertrand