October 8, 2005
Ruby on Rails on Cocoon
"Everything should be made as simple as possible, but not simpler", said Albert Einstein. Perfect words to describe the work we need to do on Apache Cocoon in order to make it more user-friendly, and to make it easier to get up and running building Cocoon-based applications.
Simplicity was definitely the emergent theme in the run-up to and during the Cocoon GetTogether. Helping our users understand the framework - and the compelling reasons for using it. Helping them see how to build applications, and helping them get up and running as quickly as possible. For example, we need to provide more demo applications, like Bertrand's Bricks CMS. These applications should illustrate the type of thing you can do with Cocoon, clearly identifying the best practice.
We should work harder to make it easier to configure Cocoon. Pro-netics' new java-based build tool is an excellent step in this direction, but I believe we must go further. Not every user will be operating at the level of blocks - they shouldn't need to know what bsf or poi or web3 or slop are in order to customise the version of Cocoon they are running. Let's get some high-level task definitions together and group blocks under them, in the same way Linux distributions reduced installation complexity to a question of "what do you want to do with your computer?".
Churchill said "Out of intense complexities, intense simplicities emerge." By working to make Cocoon easier to use for our users, we will certainly find that Cocoon becomes a more powerful framework than ever. By adopting conventions we will find that many tasks done by Cocoon become incredibly easy, requiring the minimum amount of code and effort. Berin's timely post to the developer mailing list, Cocoon on Rails Application Component Kernel, gives us a well thought-out starting point. Coupled with Sylvain's work with JDBI and the many ideas that were flowing over the last three days, I think we can have the bulk of this done very quickly. The GetTogether may be over, but the work is only just beginning.
To clarify a point that Ugo raises in his CocoonGT wrapup, I think this is less about jumping on a bandwagon and more about learning from what others are clearly quite successfully doing to help their users. We all have huge investments in the platform, and if we want to move into the future with it, we have to make sure we can bring the users (and future developers) along with us.
I've just updated my GetTogether slides for the Simplifying Cocoon talk to include the notes, which are rough but may help give more background. The slides are available here and the accompanying videos are also now online. Step 1: generating a template application. Step 2: generating the 'controller'. Step 3: datasource configuration. Step 4: dynamic cforms from database metadata. I'm sure they'll also be on the GT slides and recordings page soon, too. I'm just cleaning out the Raccoon application itself to get rid of some of the mess, and then I'll make it available for all to see the horrors that are my XSLT/SQL Transformer twistedness ;-)