Apparently this bit of documentation hasn’t survived the transition to
the new wiki:
The ‘code merging’ that the Engines plugin does works for helpers and
controllers because of the naming convention the files containing
those classes have (whatever_controller… whatever_helper.rb and so
on). The Engines plugin overrides the loading mechanism so that when
one of those files is loaded, it merges the code with any similarly
named controllers in well-known places within your engines directory.
There is no such naming convention for models (or any other ruby
files), so there’s no way to determine where any other corresponding
files might be. If you asked ruby/rails to “require ‘guid’”, there’s
no way to determine just from the filename (and that’s all we have)
whether or not it’s a model from /app/models, a lib from /lib, or from
somewhere in /vendor (or anywhere else on the loadpath). Shy of going
through the WHOLE load path searching for similarly-named files and
loading them, there’s nothing we can do - and doing that would be a
spectacularly bad idea:
- it would be very slow
- it would risk loading unnecessary files along with all their
dependencies - imagine looking for your ‘widget’ class and having a
whole bunch of GUI code loaded into memory just because it contains a
class of the same name.
So - technical limitations. Or ‘design flaw of Rails’ if you feel they
should’ve named the model files whatever_model.rb.
The solution I’d suggest, and that I’ve tried to present in the login
and user engines, is not actually putting any code into model classes
directly. Instead, create modules which can then be included into
model classes. To override the User class in the login engine, you
only have to create a user.rb in your /app/models directory, and
ensure that it has the line “include
‘LoginEngine::AuthenticatedUser’”. To override any methods defined in
the module, just redefine them in your class.
Hope this makes it a bit clearer.