Rails Ruby on Rails → 2.x

Comments and changes to this ticket

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  Simon Parsons April 16th, 2009 @ 05:42 PM

  • Title changed from “+1” to “Let engines ship their own initializers?”

• You flagged this item as spam.
  

  Glenn Powell July 6th, 2009 @ 11:41 AM

  +1

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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

• You flagged this item as spam.
  

  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.enable which 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.

• You flagged this item as spam.
  

  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! :)