Hi Berin,
On 7 Oct 2005, at 15:09, Berin Loritsch wrote:
Here's the deal: Cocoon is a very powerful publishing framework
adapted to do web applications, and Ruby on Rails is a very
empowering web application framework that can be adapted for a
number of purposes. There are two very different mindsets behind
the two frameworks--and I believe we can leverage the very potent
lessons learned from Rails for the Cocoon framework.
I couldn't agree more. In fact, I spoke about this at the GT this
morning :-)
The full slides with notes, videos etc will be available via the GT
web site shortly, but until then you can see the basics at http://
www.luminas.co.uk/andrew/raccoon.pdf
Your SHRT goes into rather more technical detail than I managed.
In all seriousness, the biggest lesson from the Ruby on Rails
project that Cocoon can learn is the power of convention. One of
the biggest things that contributes to the high learning curve of
Cocoon is the lack of convention.
Not just the lack of convention but also the lack of good sample apps
(solved by Bertrand with the bricks-cms) and of a decent generator of
templates (temporarily done by raccoon but hopefully soon by m2
archetypes).
This morning I asked if Cocoon is too complex for convention, or if
we simply have a logistical problem - lack of time to define suitable
conventions. It looks like you've given us a starting point!
Model
-----
The Rails model is one of the most powerful aspects of the whole
framework. I'm not going to go into the whole ActiveModel
architecture other than to say that the model lives in the app/
models/ directory and the class name is the singular form of the
concept (i.e. LogEntry) and the backing database table is the
plural form (i.e. LogEntries). Using convention to map class
methods to tables and records is a very powerful aspect that beats
out anything else in the Java world. It would be a project in and
of itself to write a replacement for this piece--which is not
something I would recommend for CRACK.
I got a little way down this path using XSLT and the SQLTransformer
(crude but it worked). We can go a long way using JDBI (http://
jdbi.codehaus.org/) and DdlUtils (http://db.apache.org/ddlutils/).
Hopefully Sylvain will be able to commit his JDBI flowscript wrapper
as a start.
View
----
In the CRACK version matching the /login/index URL, we would look
for (in this order) a .jx file, a .xml file, or a .xsp file that
matches the name of the action "index". More clearly, in that
example CRACK would look for app/views/login/index.jx first, and
then substitute the other extensions in case they are there. The
Rails view framework also allows fragments that can be embedded in
other views, but this is good enough for now.
I think views are one of the areas where RoR is the weakest, and
where we can make the most significant improvements - for example
thinking in terms of a CRACK view being index.jx/xml coupled with an
associated xslt by default.
Changes to Cocoon
-----------------
In order to support something like this, we don't have to make
fundamental changes to Cocoon. In fact, all we have to do is
provide an alternate Sitemap implementation that uses reflection to
find the controller class and build the pipeline based on the view
source, the layout location, etc.
Or a tool to one side of core Cocoon that provides these features,
and can also generate the default layout etc?
What do you think? Rosy picture? BTW, I only used the name CRACK
as an eye catcher--I'm not expecting the final product to be named
that.
Raccoon has kind of a ring to it, no? ;-)
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/
