The comprehensible but often superfluous model method in Rails is used in an ActionController to tell it about an ActiveRecord model that it ought to have loaded in order to have the AR classes available to it. It’s kind of got the feeling of a require or a use in Perl. It’s fairly straightforward to reason by analogy about what it does.
(The only confusing thing, I think, is that it works by imputing a filename from a symbol representing the class to do its “magic” so if you define multiple AR classes in a single file, you’d want to make sure that the symbol that matches the filename containing the multiple classes is what you pass to the model method.)
But in a nutshell, you stick model :my_object_class in, say, the base ApplicationController class and you’re good to go to use MyObjectClass and any subclasses defined in the same file.
Well, it was the way you do it. Around Rails 1.2, it started barfing up preemptive deprecation warnings: model is deprecated and will be removed from Rails 2.0.
So, you follow the URL they give you for more info. Unhappily, nowadays (August 2007), the page they point you to, http://rubyonrails.org/deprecation, doesn’t say anything about model. WTF, guys?
Googling around tells you that you should use require_dependency instead. Oh, good. Way longer to type and harder to remember, but it’s OK, because require is part of the language itself and is familiar to those who understand it. Er, wait: it’s require_dependency, not require: it’s a Rails feature, not a Ruby core language feature.
Fine, you say, I’ll do it if I must. Just do a replace on those lines, and you’re good, right? Oh, wait again, now my app is bombing with an error 500, and the log says undefined method `ends_with?' for :my_object_class:Symbol. I won’t keep you in suspense: you can’t give a symbol :my_object_class to require_dependency, you have to give it a String ("my_object_class").
All of this highlights a pretty big issue with Rails. It’s really an infantile, nascent culture. To keep up with it, you really need to be in constant conversation with the community (like constant: I mean, you need to be sitting in the session at RailsConf with Colloquy open on your MacBook, chatting about stuff on an hour-by-hour basis). This isn’t bad, but you better understand it. And you better be refactoring your app constantly in order to keep up with best practices and to be able to use new plugins, etc. — which also isn’t bad, but it’s expensive and a hassle.
And to anybody who thinks a Perl app is tough to maintain: yeah, right. Try Rails code from a year or so ago if all you know is Ruby and you haven’t been heavily engaged in Rails culture during that time.
“Convention over Configuration” is fine and dandy as long as you’re steeped in the culture that maintains the shared conventions.