I like the idea of “instant functionality” Engines can offer, but
practical implementation issues make adding and removing more tedious
than it should be.
The process typically requires:
- manual modifications to environment.rb ( e.g., adding engine
configuration and “Engine.start :myengine”
- manual modification to app/controllers/application_controller.rb
This should be more automatic and flexible, as with http.conf includes
in Apache:
Include includes/*
Installation scripts can thus add new functionality simply by copying
their boilerplate configurations to an include directory, and no changes
would need to occur in environment.rb or application_controller.rb.
This makes it a lot easier to add/remove controllers, such as deploying
a particular engine config or upgrade w/o touching core application
files. Or, if a particular engine needs to be configured differently
for various deploy scenarios but the core application files remain
constant, then it makes sense to have differing configs for that
particular engine w/o having to duplicate the rest of the core
application config files.
On 8/8/06, Robert M. [email protected] wrote:
This should be more automatic and flexible, as with http.conf includes
files. Or, if a particular engine needs to be configured differently
for various deploy scenarios but the core application files remain
constant, then it makes sense to have differing configs for that
particular engine w/o having to duplicate the rest of the core
application config files.
Whether or not an engine (or plugin) requires modification to
app/controllers/application.rb, etc, depends on the particular
engine/plugin. It’s quite simple to send the :include message during
the plugin/engine’s initialization.
The reason why engines in particular require the ‘Engines.start’ line
is because they don’t use the same start-up hook as normal plugins
(whose init.rb files are automatically evaluated as you’d wish). The
reason for this is twofold:
- they need to be loaded after the engines plugin itself
- it can be useful to control whether or not they are loaded, and in
which order.
The current plugin mechanism doesn’t have this kind of control (see
http://dev.rubyonrails.org/ticket/5468, which won’t be included).
The idea of environment.rb ‘includes’ seems like it might already be
solved in the form of plugin init.rb files, which are automatically
loaded. If plugins can be used to do everything you need, then your
problem is already solved. Different deploy scenarios can also be made
explicit by having different configurations in the various
evironment/* files.