[korch]

I have come to believe the only purpose of controllers is to impose a callback structure on top of a deterministic set of resource-models. The more simple and lean the better. CRUD just happens to be the most useful subset of callback structures, so it's the default. If you're putting code in your controller that isn't for one of the 7 resource actions, then it probably ain't controller code. (To be glib, you should instead move that code to lib/util.rb, the smartest next mistake).

On the flip side, if you remove all the non-REST code from your controller to the extreme, like what you'd see when using the inherited_resources gem, the only code left will be your callbacks. DHH said this presentation needed to show some code to make the claim hit home. So the only code left to remove is the callback code.

How could the controller callbacks be made better, and more invisibly integrate with the routing muck? Rails 3 is getting the state machine gem added to core, so no doubt about this time next year someone will have re-re-re-written the routing code using the state machine api. Could the routing muck be made to be the controller callbacks? I always liked the idea of how the Seaside framework did it using continuations, even though in practice it wasn't quite as good. Everyone knows that creating a zen-simple state machine api using continuations is not fun by anyone's measure of the word "fun."