Sylvain Wallez <[EMAIL PROTECTED]> 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.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.
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...
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
