rails.git - Mirror of official rails repo with custom fixes.

	Commit message (Collapse)	Author	Age	Files	Lines
*	Patch for #1458 - [3.1.0.rc1] App plugins initialized before engines	Joseph Wong	2011-06-16	1	-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 path	Piotr Sarnacki	2010-12-09	1	-8/+0
\|
*	Move singleton pattern to Railtie and remove Engine::Configurable and ↵	Piotr Sarnacki	2010-09-03	1	-1/+1
\| \| \| \|	Application::Configurable in favor of unified Railtie::Configurable
*	Gather initializers from railties in engines to get rid of additional ↵	Piotr Sarnacki	2010-09-03	1	-10/+0
\| \| \| \|	looping through initializers
*	Engine can now load its own plugins	Piotr Sarnacki	2010-09-03	1	-12/+12
\|
*	Made Engine valid rack app with its own middleware stack	Piotr Sarnacki	2010-09-03	1	-2/+2
\|
*	Solve some pendencies.	José Valim	2010-01-24	1	-1/+1
\|
*	Extract Railtie load from application.	José Valim	2010-01-23	1	-0/+31