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.
