Sylvain Wallez wrote:
<snip />
My impression is that with all these changes, Cocoon will be sexy
again. Add a bit of runtime analysis of databases and automatic
generation of CForms to the picture, and you have something that has
the same productivity as RoR, but in a J2EE environment. It also
includes what I learned when working on Ajax and the consequences it
has on the overall system architecture.
Hm, I'm not sure how to say this, so that it sounds not too sharp, but
although all the features you described are useful, I don't think they
are enough for a major version. That's more sort of 2.x evolution, not a
3.0 revolution :-)
I would change the order. What makes RoR and some others "sexy" is the
quick start a long with out-of-the-box "databasebrowser" support. So
imho a app-skeleton generator would be really important to make the
cocoon community grow. Just give it a database, hit a button and here's
your fancy new databasebrowser. This would reduce the barriere for
cocoon beginners, too, as they don't have to start from scratch and can
learn by modifying small parts of the components involved....
Some thoughts on this:
-choose a db layer... spring with hibernate for example
-write some code generators, or even better, some kind of a subsitemap,
that generates all files that are not supplied by the developer (if you
want a customized template, write one, if not, take the one generated by
cocoon (on the fly))
-get some fancy widgets for the db browser...
Speaking of widgets... I am not sure if it makes sense to reinvent the
"widgetwheel"... Wouldn't it be better to put some work into the JSF
block, and use myfaces/tomahawk as "cocoon gui" ? Replace the "ugly" JSF
renderkits with cocoon pipelines, and supply "flow" as controller for
JSF ? Not sure about this, but I think this could really rock :-)...
tom
