cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: [RT] Towards a new/another Forms Framework
Date Thu, 03 Apr 2003 14:21:14 GMT
On Thu, 2003-04-03 at 14:28, Jeremy Quinn wrote:
[...]
> An ideal forms framework is complicated by the fact that people need to 
> do very different things ....
> 
> Here are examples of two obvious uses, and how they can differ:
> 
> 	Editing 'business' data
> 
> 		'forms' contain simple data types that need validating as data-types
> 		often require JavaBean etc. object mapping with business logic
> 		often require RDBMS etc. mapping for persistence
> 
> 	Editing XML Content
> 
> 		'forms' contain a mixture of simple data types and markup
> 		often need wysiwyg editing for the markup
> 		might need to transform form data from one MU language to another
> 		need to validate XML fragments
> 		need to roundtrip XML fragments between editor and server
> 		need to modify XML 'documents' on the server


And a third one: not editing anything at all, but just gathering
parameters to call some service.

> IMHO, it is the differences between these typical needs, that is 
> causing some of the misunderstandings between people who are currently 
> discussing form frameworks.
> 

The way I see things, providing a form for modifying an XML document is
not different from one for modifying a database record or an entity
bean.

During initialisation, load the form with data from the XML document,
and once the submit-until-everything's-valid cycle is over, apply the
changes back to the XML document.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message