cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Learning from XForms
Date Fri, 12 Nov 2004 17:05:29 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:


>> After this experience and especially after Sylvain's letter, there 
>> seem to have been a feeling in the community that XForms is not 
>> relevant for Cocoon.
> Let me correct this: in the now famous "XMLForms vs Woody" post, the 
> conclusion wasn't that XForms was not relevant for Cocoon, but that 
> the XForm event model was IMO too rich to be implemented in a simple 
> and efficient manner by a server-side implementation. 

Do you talk about the event model there? Anyway after your post whether 
it was influential or not, (I would say it was), there have been a 
concensus on the list among "key players" that XForms not is suited for 
server side implementation (search the archive for XForms). I don't 
know, but I am interested in Micah's opinion about it. The Chiba guys 
think it is suitable for server side implementation and maybe even prove 
it (

> Woody on the contrary was less ambitious, but had good foundations for 
> a server-side form framework. It later evolved into the CForms we have 
> today, which does have an event model which, although simple, fits 
> many complex needs as it runs server side. 

Sure, I think it was the best choice back then. What I'm discussing now 
is how to evolve our form processing so that we both keep back 
compatibillity and makes it an open framework where we can plug in new 


>> Another thing is having a request processor that writes into the 
>> widget tree instead of letting the widgets read from the request. 
>> This makes it possible to plug in an XML based request processor 
>> instead of the request parameters based, e.g.
> The danger here is to fall again in the XMLForm trap, where all 
> request parameters where checked to see if they corresponded to some 
> valid XPath expression.

As long as one uses a separate form model, this danger can be avoided by 
either letting the business model (or a binding framw work) pull data 
from the form model, or by having a schema that restrict what can be 
added to the form model.

One can also use the mechanism that Jonas Ekstedt and also Reinhard 
have proposed. One register all used widgets during form rendering and 
then only read from registred widgets during request processing. With 
this solution one is safe even without using a form model.

> Note also that most widgets only call getParameter() on the request, 
> and that we could easily cut that dependency by passing e.g. a Map 
> implementation wrapping the request. That's what JSF does to abstract 
> the request between servlet and portlet, as they have no abstraction 
> of the environment as Cocoon does. 

Might be a possiblity, the important thing is getting better separation.

>> In my view it is possible to break up the rather heavy widget 
>> interface in more focused concern areas, and especially to give a 
>> more focused model-view interface, without breaking back compabillity.
> Could you elaborate on this?

Yes, my main interested ATM is give a better model-view separation in 
the framework. Taking a look at e.g. your helper class for the JX macro 
implementation, a subset of the interaface is used for rendering the 
widget hierarchy. That part of the inteface could be factored out to a 
separate interface. In, I 
discuss what would be needed in a "populate" interface. And also that 
convertion/rendering IMO should be done in a separate component. These 
are examples of more focused concern areas. By splitting the widget 
interface in a number of sub interfaces it would be easier to replace 
one of the components with something else.


View raw message