cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Learning from XForms
Date Thu, 11 Nov 2004 22:38:06 GMT
Daniel Fagerstrom wrote:

> Micah Dubinko wrote:
> <snip/>
>
>> I'm happy to learn whatever I can here.
>
>
> <snip/>
> Micah Dubinko wrote in another mail:
>
>> I want to get involved in Cocoon more, and wonder if this would be a 
>> good project to cut my teeth on. 
>
>
> Hi Micah (and the rest of the list)!
>
> There are certainly places in Cocoon where your help could be very 
> valuable, how about geting involved in Cocoon form handling ;)
>
> I hope I don't embarrass you by telling those on the list who don't 
> know (me until an hour ago e.g.) that Micah (http://dubinko.info/) 
> among other things is editor and author of the W3C XForms spec where 
> he has been involved for the last six years, author of an excelent 
> book about XForms (http://xformsinstitute.com/essentials/), and author 
> of numerous magazine articles.
>
> I thought about asking about your reaction to Sylvain's XForms-CForms 
> comparison 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2 
> but found out that you already have started to write about that 
> http://dubinko.info/blog/2004/10.html#perm2004-10-13_xmlforms. I also 
> found http://wiki.apache.org/cocoon/XFormsInCocoon. Please do not be 
> shy ;), publish your ideas about such things here at the list, so that 
> we can discuss them.
>
> XForms in Cocoon
> ----------------
>
> There have been several different partial XForms implementations in or 
> related to Cocoon since 2000. ExFormula (Berin Loritsch), Precept 
> (Torsten Curdt), XMLForm (Ivan Ivanov), JXForm (Christopher Oliver). 
> They where essentially one man shows. XMLForm become quite popular but 
> it had a security problem and also a got a community issue when Ivan 
> decided to continue development in an own fork outside Cocoon. IIRC 
> Berin had some discussions at the XForms mail-list a number of years 
> ago about server side implementation and draw the conclussion that the 
> commity was mainly interested in client side implementation.
>
> 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.

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.

> IMHO, this might be a mistake. I sometimes got the impression that we 
> spend a lot of time to independently evolve things that are quite 
> close to what XForms allready does. And the last time I reviewed the 
> spec it seemed to me that the XForms event model would work well at 
> the server side also.


I shamely admit I haven't read the final version of the XForm spec :-/

> Now we can't switch form frame work every now and then in Cocoon. Our 
> users need stabillity and we as a community needs focus, and CForms is 
> an excelent form frame work in many ways. But I think that we can and 
> should make it much less monolitic and thus open it up for pluging in 
> new ideas into the frame work. Now it is rather all or nothing.
>
> We currently have a long discussion about, (among other things), how 
> to achieve a stricter model - view separation in CForms 
> (http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2, especially 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2). 
> The major point here is to put the conversion/rendering step (what you 
> call I18N formatting in your blog entry, and also identify as a major 
> issue), between the model and the view.
>
> 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.

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.

> 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?

> If we can achive this, it will be possible to use an XForms like user 
> interface, and still using the rest of the frame work. Or to plug in 
> an own e.g. DOM based widget hierarchy whith the existing UI.
>
> IIUC there is still work to do in formalizing the life cycle and the 
> event handling in CForms, it would be very interesting to see a 
> comparison with the event model in XForms.


Sure, comparisons are always interesting.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message