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 (http://chiba.sourceforge.net/features.html).
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 (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2) 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 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2, 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.
<snip/>
/Daniel
