James Adam wrote: > 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
I am just getting started learning Ruby (I hardly know much at all--and that goes for Rails and the Engines, too), but as an old C++ guy, I remember with horror the problems we used to have when 'upgrading' to a new version of a C++ framework, where we inherit from the provided functionality of an older version of the framework. Similarly, I don't know if a late-binding script language like Ruby has similar problems or if your current code-overloading scheme solves it or has the same problem, but if I were you, I'd google a few keywords like "framework class brittleness upgrade problems C++" etc., you get the idea. Maybe even try Borland OWL or Microsoft's windowing framework for C++ (I can't recall the name of it now), then head over to the Ruby language forums to ask the gurus there about class design and "versioning over time" of Ruby classes and see what they say. HTH, Brad -- Posted via http://www.ruby-forum.com/. _______________________________________________ engine-developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
