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
|