This project is archived and is in readonly mode.
Let engines ship their own initializers?
Reported by Sven Fuchs | February 15th, 2009 @ 09:38 PM | in 2.x
With engines init.rb is the new environment.rb. Err, by that I mean that plugin init.rb files can quickly get messy once there are a few engines.
So, how about this? http://gist.github.com/64852
PS: after_initialize is not really an option because engines usually want to allow the app to overwrite their defaults. Thus plugin initializers would need to run before the app intializers - as that's now happening with routes. So the only alternative here often is to mess with the plugin load order but that of course has its merits, too.
Comments and changes to this ticket
-
Simon Parsons April 16th, 2009 @ 05:42 PM
- Title changed from “Let engines ship their own initializers?” to “+1”
This is something that a client of ours wanted, and we're now using the code in the gist. It works well, and we definitely support its inclusion.
-
Simon Parsons April 16th, 2009 @ 05:42 PM
- Title changed from “+1” to “Let engines ship their own initializers?”
-
-
Francesc Esplugas July 8th, 2009 @ 04:41 PM
In my opinion an initializer has to be inside the application because if you want to configure something, with what you propose, you would have to modify the engine initializer itself.
-
Sven Fuchs July 8th, 2009 @ 04:46 PM
Francesc, I don't think that's always true.
For one thing you might set defaults in an engine intializer but make it so that people can overwrite it in the application.
Also, you might just want to use engine initializers as a place to wire things up, which needs to happen after engines are already fully loaded.
-
Daniel Guettler July 8th, 2009 @ 04:53 PM
I have to agree with Sven. Currently I'm using the Desert plugin to be able to split our application apart and reuse parts of it in other applications. I'm looking forward to move to Rails 2.3 and port all this to engine plugins. Currently I'am manually loading all plugin classes esp. some classes need to register them self. For this case it would be helpful to have the plugin define which classes need to register them self instead of keeping track of it in the parent application.
-
Simon Parsons July 8th, 2009 @ 05:13 PM
Our client continues to use this feature in a production environment with multiple engines shared between multiple apps. We have had no issues arise, and wouldn't go back even if this patch was definitively rejected.
In my opinion this is an intuitive solution to the needs of engines (particularly as opposed to standard plugins), given that engines which provide controllers and models are likely more tightly integrated with apps.
As Francesc says, it's important that plugin initializers run first: Sven definitely got this part right
-
Francesc Esplugas July 8th, 2009 @ 11:57 PM
I've been thinking about it, and this makes sense as the "engine" has to boot and generate its environment.
For example in Typus I've a
Typus.enablewhich makes the application configure for the first time, and then the application initializer is run, this could be done automaGIcally.Definitelly +1 to see an initial patch to test how this can work. I would modify Typus to take advantage of this new feature.
-
Steve St. Martin April 16th, 2010 @ 01:48 AM
Doesn't all the Railtie work in Rails 3.0 account for this? this could probably be marked as resolved.
-
Sven Fuchs April 16th, 2010 @ 08:29 AM
- State changed from “new” to “wontfix”
That's true. Will set it to wontfix bc/ this probably won't go into 2.x anymore, right?
Thanks Steve! :)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Daniel Guettler
DHH
Steve St. Martin
Tekin