I'm not sure if Cocoon should be used for writing web applications at all. If you want to write a simple application, you need to write (and learn) the sitemap, flowscript and probably JXTemplate. If you want to use cforms, you need to know how to write form definitions, form templates and maybe even form bindings. If you want to apply some styling you need to know about XSLT as well.
And it even makes it more difficult if you want to reuse some of these parts (try to extend or override parts in cforms, jxtemplate or flow - it wasn't designed for this). I've switched to use Wicket for the new application that we've been creating here. I think it's much easier to create web applications with wicket (because one of the things that make it easier to use is that it takes the request/response cycles away). It's back to basic html (or xhtml) with Java. And onf of the best things is that you can reuse and extend your components (including reuse of markup). Cocoon's SoC made writing web applications better because of the strong separation of logic, content and styling. And javaflow improved it because it took some request/response details away. I think Wicket has achieved the same goal, but I think it's more productive to use than Cocoon is these days. Maybe Cocoon should focus on XML transformation stuff again, and not trying to integrate yet anohter product... Just my 2 cents. > -----Oorspronkelijk bericht----- > Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > To be honest I'm not sure if javascript is better than xml :) Though I > don't like both of them when it comes to describing a flow, Spring > Webflow as imho to big plus points: a visual editor and it's > well known > outside of Cocoon. This doesn't imply that it's really better > or better > usable.
