Magic Conventions

What makes an awesome framework? A lot of things obviously, but one particular thing is how much magic it does.

I was amazed at the magic going on in Rails the first time I looked at it. ActiveRecord automatically knew which tables my classes mapped to! It automatically gave me handy functions, (ar.foo for regular attributes and ar.foo? for booleans, for instance). Specifying (basic) validations was a piece of cake. Adding relations to other tables was also super easy. It also automatically located the ID column of my tables.

Of course, there is really no magic going on at all. Mostly it's just the ardent use of conventions that made the magic appear. AR assumes that if your AR subclass is named Artist, it will find a database table named artists. Same thing for all the other conventions, as was immediately noticable when you named your PK's artist_id instead of simply id (or did AR consider this well? I might be mistaken).

Conventions are great, if you know that they exist you can do things the framework wants you to, and get huge benefits in the amount of code you don't have to write. If you already have a working solution, perhaps you can refactor it to look like something the framework expects.

There are also instances where you follow conventions that help you out without first realizing it, and all of sudden you realize half of the code you were going to write isn't necessary, sweet!

Magic conventions have another great property, you will be completely astonished when you experience them from the first time. "How did the framework know I wanted it to work this way?", "How could they possibly have made this so seamless?". If this is the first impression a user gets, I think they'll be enticed to stay in the framework.

Conventions don't have to force users to abide by the rules completely though, they can act as default behavior, and if you a) have old code you need to use or b) want some behavior that isn't default, you can provide the users with means of changing anything (such as a global JSON or XML file, or local changes through basic setters.) So, the user can still get a lot of benefit by having the conventions there, although not as much as if they'd follow them all, obviously. One example of this is Rail's ActiveRecord, by default it maps a capitalized class name in singular form onto an underscored table in lowercase, using plural form (e.g. the class PostedComment to the table posted_comments). If you have other table naming schemes you wish to use with Rail's AR, just callset_table_name. More code (since the default mapping convention required no code at all from the user), but it gives the user the possibility of making it possible to use AR anyway.

Now onto Cactus. Cactus also has a lot of magic in it, it's one of the reasons I think it's so much fun to use. For instance, if you in a Template have a HTML element with class="author", and you in your KeyValueCoding subclass have an author property containing a string, the Template will assume that you want to display that string inside the author element. Which you do, right? It's also assumed that if you have a property pointing to an array, and a HTML List (OL or UL), each item in the list should be displayed in it's own list item (LI). Pretty nifty, if I may say so myself. There is of course nothing extremely complicated going on here, but parts of it may just seem like magic the first time you see it. Cactus does a whole lot of other magic as well, something I won't go into detail on right now. Unfortunately, cactus has few mechanisms for changing the default behavior as it currently stands, but this will surely be changed -- once the need arises, or once I have the time.