Nothing prevents people from writing:
class ApplicationModel < ActiveRecord::Base
self.abstract_class = true
end
class User < ApplicationModel
…
end
Nothing prevents people, but ApplicationController is provided by the default Rails skeleton, and used by “script/generate controller”.
Having the same for ActiveRecord isn’t entirely unreasonable, and wouldn’t really require touching ActiveRecord – just Rails generators.
Nothing prevents people, but ApplicationController is provided by the default Rails skeleton, and used by "script/generate controller".
Having the same for ActiveRecord isn't entirely unreasonable, and wouldn't really require touching ActiveRecord -- just Rails generators.
Controllers have a much closer bond than models do. The reason for ApplicationController is specifically to deal with the common scenario of filters that needs to be shared across all controllers and, as a distant second, shared functionality of the standard variety. In other words, application-specific behavior that doesn't fit into ActionController::Base.
I've personally never felt the desire to include any such application- specific behavior for all my Active Record models. And unlike Action Controller, Active Record doesn't have a monopoly on the model space in a Rails application (just think Active Resource or vanilla Ruby objects). I frequently have non-AR models, so ApplicationModel would be misleading.
So I see the comparison, but I don't think it's valid in this case. Controllers and models are of a different breed and need different care.
I see your point.
I often reopen AR::Base (or include something, it doesn't really matter). In my experience that's all sharing I need. ApplicationModel would suggest there's a root class for the M layer, and that's not going to work. Yeah.
So upon reflection what I miss is a root for AR models in the application, and ApplicationModel is a misleading name for it.
Reopening AR::Base does the job, but I'd just prefer a well-defined application specific class provided by the skeleton and generators so you know where people are going to put shared stuff, instead of carefully inspecting config/initializers and lib (say).
Given the mismatch such a new root class would imply for the documentation I am unsure it is worth the trouble, I can't think of a good proposal for this at this moment.
