cocoon-dev mailing list archives

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

> Sylvain Wallez wrote:
>> Daniel Fagerstrom wrote:
> <snip/>
>>> 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 
> modules.
> <snip/>
>>> 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.

Do you mean the widget tree crawling methods?

> In 
> I discuss what would be needed in a "populate" interface.

As I mentioned previously, either abstracting the request parameters 
through a Map could be a way to achieve this.

We could also add a setValue(String), but that may not be enough, as 
some widgets do more than reading a single value. For example, an action 
checks its own parameter (e.g. "ok"), but also parameters corresponding 
to an image button (i.e. "ok.x").

Furthermore, traversing the tree in order is important, as some 
containers prepare a context for their children. This is for example the 
case of repeater (creating rows if "repeater-id.size" is present) or 
aggregate-field that splits its request parameter and feeds its children.

> And also that convertion/rendering IMO should be done in a separate 
> component.

I agree with this. CForms convertors should be usable not only in CForms.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message