cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Savory <>
Subject Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Date Fri, 07 Oct 2005 14:43:17 GMT
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://

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  

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:// and 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 Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Orixo alliance:

View raw message