Interesting that Chad mentioned about avoiding instance variables. I must say I disliked the use of instance variables, In the odd little pet projects I’ve been playing with I’ve often made private controller methods to avoid the nasty use of @, and made them helper methods occasionally. I can’t say say I’ve gone all the way to eleminate their use though. It’s good to see other people think alike.

Association proxies is something I’ve been pretty poor with, and I’ve often not though about my design and ended up with slightly bloated/disjoint models, despite knowing about the AssociationProxys for well over a year now. It does help avoid some of the clumsy use of SQL. I don’t suppose you’ve seen a lib called Squirrel? I’ve skimmed through it at ….

http://giantrobots.thoughtbot.com/2007/2/13/a-convenient-squirrel-addition

It’s got a nice elegant syntax to replace common SQL queries. I wonder if it would work on the find method found in associations because it qould kill a lot of nasty find criterias. My main concern is how robust the plugin is as it’s not heavily used.

About your point about how Rails deals with views, I must agree there. One of my issues I have found when I’ve occasionally bothered to do any coding is that I end up moving a number of methods into models because what I am trying to do is common to a number of views. I think a lot of other people do the same, and especially now that Jamis made a point of it in the Skinny Controller, Fat Model post on his blog. Thinking back in retrostect the other day I thought it’s probably best to move this sort of stuff into helpers, because this sort of code doesn’t really belong in views nor models. It’s almost like like the paradigm of MVC is slightly lacking unless there is decent use of helpers. Certainly I would argue in Jamis’ post http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model that methods like age, name etc might be better as helpers.

Interestingly, it looks like controllers will support multiple view folders in version 2.0… http://weblog.rubyonrails.org/2007/2/4/new-feature-for-rails-2-0-multiple-controller-view-paths which might prove handy for applications that need slighly more flexible skinning.

Certainly I agree with the fact that views are due for some changes. After all Rails 1.2 was mainly controller and routing changes, and rails 1.1 was mainly ActiveRecord association changes (I guess some view stuff was touched on with the introduction of RJS).

As for testing, it’s good to see you’ve picked up on using it. (though I gotta say I rarely think about making proper test myself, and if I do they are normally just for tedious model related things). I seem to remember preching about testing back in the days when we used PHP. Like mainy, I’ve found fixtures a pain in the backside. My biggest issue with fixtures is they are a global dataset. This basically means that when you change/add some fixture data to suit the needs of a new test you end up breaking some other tests that rely on the same fixtures. On the odd occasions I’ve bothered to write tests, I’ve kept fixtures to a minimum. The other pain with fixtures is the fact if you change you DB tables (i.e. add or remove rows) fixtures need to be cleaned up.

Chad’s point about SQL’less controllers is a really good point. It’s never crossed my point, but I must agree that controllers are the wrong place for SQL.

Anyway, hope you are all keeping well and hope you aren’t having to do too much overtime!