Skip to main content

Cairngorm should take a lesson from Rails

On Monday I was adding some new functionality to and it occurred to me how tedious it is to do that kind of stuff within Cairngorm. Just like DHH calls it: "XML sit-ups" (though it's not XML, but the sit-ups are the same).
The problem is:

  1. There is a lot of repetitive wiring to be done
  2. In our situation, where all client-server interactions follow the same pattern, one interaction could safely be deduced from a minimum of information.
For example: let's say I want to create the new "list users" functionality. I need to create a "list users" event, wire this event into the controller so that it fires up the "list users" command, create a method "list users" in the delegate, define "list users" in services.xml and, finally, code the "list users" command. And the same for "add user", "delete user" etc. You get the picture.

I think that Cairngorm should have a drink from RoR's "convention over configuration" cool-aid. How could this work?

Suppose you fire the event

new CairngormEvent("list_users", [rest params])

You do not have to define this event type. By convention, the controller will execute the ListUsersCommand. This ListUsersCommand is the piece you actually have to implement. Within ListUserCommand's execute method you call the delegate as usual. But, you should not have to define, what the delegate is supposed to do. Something like


should suffice. The delegate knows that the method "listUsers" translates into "/list/users" and dispatches the request onto its default server. The parameters are mapped onto CGI-style parameters, potentially converting camel-case into underscore_case. The response will automatically be sent to the command.

Of course, one should be able to overwrite, i.e. explicitly define the default behavior. But that can be done already.

Maybe, I am biased because in our project all client-server interaction is rather uniform, but I can well imagine that others go through the same kind of repetitive exercise. IMO this would be a worthwhile update to Cairngorm.


Popular posts from this blog

NoSQL talk at Developer Summit

Three days ago I had to chance to talk about NoSQL at the Internet Briefing's Developer Summit. On top of general ideas and concepts like the CAP theorem I chose to talk about Apache Jackrabbit, CouchDB and Cassandra. My slides are embedded below.
It was a really good event with interesting speakers and a knowledgeable audience. I was especially pleased that when I talked about CouchDB's HTTP API someone from the audience mentioned that Apache Sling does something very similar for Jackrabbit.
Special kudos to Christian Stocker of Liip for daring to do a live demo of the "real-time web" - he took a picture from his phone and had it pop up on Jabber and Twitter in about 5 secs.
Vlad Trifa has posted a good summary of the whole event (part 1, part 2) - he also gave a great presentation about the application of the REST architectural style to the "Web of Things".

No SqlView more presentations from mmarth.

NoSQL: A long-time relation(ship) comes to an end

(cross-posting from here)

OK, I admit it, declaring that "the RDBMS is dead" is a meme that has been going around the software industry for a while. Remember object-oriented data bases that were supposed to replace the relational ones? Well, guess who is still here. However, despite the RDBMS's amazing survival skills I would like to propose a related prediction:

I believe that the year 2009 will go down in history as the year when the "relational model default" ended. The term "relational model default" was coined by me to describe a peculiar thing that goes on in application development: start talking to your average application developer about some arbitrary business requirement and chances are that simultaneously he mentally constructs a relational model to fit those requirements.
That relational approach to modeling your problem may or may not be suitable. The real problem is that all too often this default does not get challenged. As a consequence,…