aboutsummaryrefslogtreecommitdiffstats
path: root/railties/lib/rails/application/railties.rb
Commit message (Collapse)AuthorAgeFilesLines
* Rails::Plugin has goneSantiago Pastorino2012-01-031-1/+1
|
* Patch for #1458 - [3.1.0.rc1] App plugins initialized before enginesJoseph Wong2011-06-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and plugins inside engines It seems that plugins inside a Rails 3.1 application proper (i.e. in /vendor/plugins) are initialized before engines and plugins inside engines. After some debugging, I found the culprit in Rails::Application::Railties#all: def all(&block) @all ||= railties + engines + super @all.each(&block) if block @all end The call to super here implicitly passes the &block argument, which has the unfortunate side-effect of adding the plugin initializers first (in front of other railties and engines) in the case of Rails::Engine#initializers: def initializers initializers = [] railties.all { |r| initializers += r.initializers } initializers += super initializers end The solution here is to replace the super call with a call to #plugins.
* Rails::Engine.find(path) - method to find engine by pathPiotr Sarnacki2010-12-091-8/+0
|
* Move singleton pattern to Railtie and remove Engine::Configurable and ↵Piotr Sarnacki2010-09-031-1/+1
| | | | Application::Configurable in favor of unified Railtie::Configurable
* Gather initializers from railties in engines to get rid of additional ↵Piotr Sarnacki2010-09-031-10/+0
| | | | looping through initializers
* Engine can now load its own pluginsPiotr Sarnacki2010-09-031-12/+12
|
* Made Engine valid rack app with its own middleware stackPiotr Sarnacki2010-09-031-2/+2
|
* Solve some pendencies.José Valim2010-01-241-1/+1
|
* Extract Railtie load from application.José Valim2010-01-231-0/+31