Improve readability with 100E2R June 15th, 2008
You know those things you stumble upon online, that inspire you to rethink the way you handle an aspect of your work?
I've struck upon one such inspiration nugget in 100E2R, The 100% Easy-2-Read Standard. It's a set of 5 complaints and 5 rules for web publishers. The page on which it's presented also includes an interesting list of referrers and some thought provoking commentary.
It promotes the design choices that I now realize underpin the web content that jumps out at me and inspires me to produce more beautiful applications.
So if you've also been scratching your head and trying to figure out why you can't get "that web 2.0 look" right, even though you're using the Trebuchet MS font and the grid implementation du jour, be sure to feast your mind on The 100% Easy-2-Read Standard.
I recommend reading the comments as well. Both the criticism and affirmation will get you thinking (for yourself). The list of referrers provides some great terrain for exploration.
Model, view or controller? June 14th, 2008
This came up on the rubyonrails-talk mailing list again, and it took me too long to find my answer from last time in the archives, so here it is.
Sometimes it's hard to decide which layer of an MVC application to put code in.
It took me a long time to settle on a simple decision process that works for me, especially in the J2EE environment where it's not as easy to change your mind.
I default to trying to push code down into the model. However, I ask myself these two questions:
- Does this code describe anything other than behavior of this model?
- Does this code know about CGI or HTML?
If the answer to either of those questions is yes, I look more seriously at putting the code in the controller or an helper. If the answer is "yes and no", I'm probably trying to do too much at once, and need to break it up across the layers.
In summary, favor the model, but not at the cost of layering violations.
The attitude that this comes from is that your domain model (your collection of "models") is the system. The controller is only there to mediate a view into it. This attitude works well for the kinds of applications Rails is suited to.
Here are two more considerations:
- Code that you put in the model is easy to use from the Rails console and runner. Code that's in the controller is more of a pain in the arse to get to.
- Model instances can call each others' methods, but they can't call methods on controllers without jumping through hoops.