cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))
Date Mon, 04 Aug 2003 16:44:47 GMT
Hunsberger, Peter wrote:

>Sylvain Wallez <> writes:
>>Now the above sentence is totally contradictory with a previous proposal of me to
include the binding into the form definition. Why did I proposed this ? Because in small/medium
apps, the one that designs the form is often (again, my own experience) the one that does
the back-end. But it may also be the one that does the view layer. And so allowing the files
to be merged reduces development time by avoiding cross-referenced files.
>>But _allowing_ these files to be separated when needed (i.e. large projects) is IMO
something important.
>>Things are never black or white : there's an infinity of greys inbetween...
>So, the question becomes: for Cocoon, which end of the spectrum are we going to focus
on? There's a desire to be able to do simple forms, if only to be able to attract people to
Cocoon.  However, the reality is that Cocoon is probably over-kill for simple forms.  If all
you need is simple forms why use Cocoon? Doesn't (ahem) JSP/Struts meet your needs? Really,
for me, the reason to use Cocoon is because you've got a lot of complexity to manage.  Thus,
I personally think the thing to focus on for Cocoon forms management is the complex use cases,
not the simple ones.  
>Maybe, after you've got the ability to do the complex management properly people will
find ways to hide much of the complexity (eg. good defaults) and then Cocoon will also be
easier for people to learn...

Cocoon needs simple forms also, because being both a publication 
framework and a webapp framework, there are many uses that are heavily 
publication oriented with a little bit of webapp and thus simple forms. 
On the other hand, moving to a full-blown webapp framework requires 
complex forms, as you point out.

And this is what the current work on Woody is all about : let simple 
forms be simple (or users will keep JSP/Struts even if Cocoon would ease 
their publication needs) and allow complex forms.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message