On 24/02/2008, Sven Fuchs <[EMAIL PROTECTED]> wrote: > Is there a reason not to allow this feature for the application > controller? I'd like to move quite some stuff from an application > controller that I'm splitting up into engines ... and there's just no > more comprehensible place to use than plugin_name/app/controllers/ > application.rb. :)
The code mixing stuff only exists to make it simpler to override methods within the application, but it sounds like you want to make methods available to all controllers in your plugin by having those methods automatically mixed into the ApplicationController. This seems distinct from wanting to add methods defined within a plugin to ApplicationController automatically. > In my usecase I can safely assume that all engines are designed to fit > together though and readability-wise it really makes most sense to use > ApplicationController here. Will this be the case for everyone? I fear that enabling this will lead to a variety of conflicts that are difficult to control. Plugins from multiple sources are all adding methods to the superclass of *all* application controllers in a way that isn't controllable by the application developer. Would it perhaps be better that application developers (plugin 'consumers') have to explicitly 'opt-in' to functionality that affects ApplicationController directly? I think the usecase Sven describes would be better solved by extracting the common functionality he needs into a non-ApplicationController class or module, and explicitly including it into the controllers that require it. .... to bring a counter-point to my own points above, if Rails ever adopts the 'application_controller.rb' name change proposal, this behaviour will be available by default. Even in this case, I'd still probably discourage defining application_controller files in any plugins that are likely to be used outwith a very controlled environment. -- * J * ~ _______________________________________________ Engine-Developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
