I like the idea of avoiding as much "black magic" as possible. Which to many, the dynamic runtime classpath/loading issues seem to be.
I'm just trying to think how you would find the all the overloaded classes and make sure they are all used correctly. For example, the login and user engines. Right now the user engine would inherit from the login engine, fine, but what if someone had an additional engine that modified the login engine with additional methods (overriding existing methods would be messy in any case), how would you know where to find the new extensions to the login engine and not use the user engine controller instead. I don't know if I'm making any sense here, but I hope you get the gist of it. I have some other thoughts, but am trying to find a way to formulate the wording so it makes some sense :) -Nick On 1/17/06, James Adam <[EMAIL PROTECTED]> wrote: > Hey guys, > > I'm toying with the idea of replacing the current code-overloading > scheme in Engines (where it merges code from multiple > controllers/helpers). What I might do instead is just have people use > normal inheritance/module inclusion. So if you wanted to change a > method in the UserController of the LoginEngine, for example, instead > of just creating your own /app/controllers/user_controller.rb with the > new method, you might actually create that controller as a subclass: > > class UserController < LoginEngine::UserController > def protect > # your overloaded method > end > end > > The advantage of this is that it means I don't need to search load > paths or modify any require strings. It also makes it a bit clearer to > the application developer that their controller is part of a grander > piece of code (currently there's no explicit relationship between > overriding controllers and engine controllers). > > An alternative scheme would be to have the controller code in a module > with a stub controller in the engine, which wouldn't be loaded if a > similar controller existed in the main app. This would be identical to > the way the user model object is defined and overridden currently. > > Doing something like this may solve the current problem of having to > get REALLY freaky with loading/requiring code (see Ticket #53 for > instance) annd be more future-proof, but also might introduce new > issues. > > Anyway - does anyone have any thoughts? The floor is open... > > - james > _______________________________________________ > engine-developers mailing list > [email protected] > http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org > _______________________________________________ engine-developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
