cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Date Fri, 07 Oct 2005 15:09:22 GMT
Andrew Savory wrote:

>> 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!

Its largely a lack of knowing where to start.  As to the sample apps--I 
agree to a point.  If you don't have the convention to build the sample 
app with, how is the potential user going to know what they are looking 
at?  In other words what are they going to walk away with when the look 
at a sample app?

>> 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.


SQLTransformer is evil (it should have been deprecated and done away 
with back in the early 2.0 days).  Again, its mixing the concerns.  A 
proper model is a separate entity that can be easily referenced, 
modified and controlled through the controller and then examined from 
the view.  It should not be mixed in with the view.

>> 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.

Amazingly, it is good enough for many uses.  I like the simplicity of 
being able to specify the JXL as the generator portion and then 
finishing the pipeline with the layout.  "It just works" for the 80/20 rule.

>> 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?

When the base convention is defined, it is easy to add the code 
automation scripts to support that convention.  Again, reasonable 
defaults also help.  That allows the user to concentrate on one thing at 
a time.



Mime
View raw message