cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Towards a new/another Forms Framework
Date Wed, 02 Apr 2003 11:25:17 GMT
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.


View raw message