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 (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.
Do you mean the widget tree crawling methods?
In http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2, 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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
