cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
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:22:08 GMT
Sylvain Wallez <sylvain.wallez@anyware-tech.com> writes:

<snip/>

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



Mime
View raw message