I''m using bundled_resource, login_engine, and a few other plugins. It appears Rails considers plugins in alphabetic order. Turns out that there is a particular order that will work and alphabetic ain''t it. The login engine must be loaded first. Bundled resource then includes ''application_helper'' and the application helper includes LoginEngine. If bundled_resource is allowed to load first, when it includes ''application_helper'' the include LoginEngine fails with an undefined constant. Is there a way to change plugin load order? Thanks -- Posted via http://www.ruby-forum.com/.
On 1/30/06, Steve Ross <cwdinfo@gmail.com> wrote:> I''m using bundled_resource, login_engine, and a few other plugins. It > appears Rails considers plugins in alphabetic order. Turns out that > there is a particular order that will work and alphabetic ain''t it. > > The login engine must be loaded first. Bundled resource then includes > ''application_helper'' and the application helper includes LoginEngine. If > bundled_resource is allowed to load first, when it includes > ''application_helper'' the include LoginEngine fails with an undefined > constant. > > Is there a way to change plugin load order? > > ThanksWhy not just fudge the names a bit? a_login_engine will cause it to load first :) -- Rick Olson http://techno-weenie.net
I actually did it the other way around: zbundled_resource. But seriously, we deal with dependencies all over the development process. Ruby Gems are good with dependencies, and other parts of Rails are. Isn''t there a cleaner way to deal with this? Steve Ross Rick Olson wrote:> On 1/30/06, Steve Ross <cwdinfo@gmail.com> wrote: >> Is there a way to change plugin load order? >> >> Thanks > > Why not just fudge the names a bit? a_login_engine will cause it to > load first :) > > > -- > Rick Olson > http://techno-weenie.net-- Posted via http://www.ruby-forum.com/.
Steve, the engines plugin requires you to call "start_engine" for just this reason -- if your engine depends on another plugin, there''s no way to guarantee that the dependency will be loaded before the engines plugin. IIRC, the idea is for "start_engine" to disappear as soon as rails supports user-defined plugin load order. So long story short, I don''t believe there''s a way to determine that load order atm, other than by patching the rails source. cheers Gerret On 1/31/06, Steve Ross <cwdinfo@gmail.com> wrote:> I actually did it the other way around: zbundled_resource. > > But seriously, we deal with dependencies all over the development > process. Ruby Gems are good with dependencies, and other parts of Rails > are. Isn''t there a cleaner way to deal with this? > > Steve Ross > > Rick Olson wrote: > > On 1/30/06, Steve Ross <cwdinfo@gmail.com> wrote: > >> Is there a way to change plugin load order? > >> > >> Thanks > > > > Why not just fudge the names a bit? a_login_engine will cause it to > > load first :) > > > > > > -- > > Rick Olson > > http://techno-weenie.net > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
This issue isn''t really related to the fact that engines need to be ''started'', as the problem would occur with if the file being require''d at the top of application_helper.rb was a part of any plugin that hadn''t been processed yet. The next release of Rails should make things *slightly* better, because as I recall I had a patch accepted which added all the plugin ''lib'' directories before performing any of the init.rb code. However I''m not sure if that code remains intact. The ''best'' way that I can think of to avoid this issue at the moment would be for plugins not to load files like application_helper. However, I can perfectly understand why Duane has done this... - james On 1/31/06, Gerret Apelt <gerret.apelt@gmail.com> wrote:> Steve, > > the engines plugin requires you to call "start_engine" for just this > reason -- if your engine depends on another plugin, there''s no way to > guarantee that the dependency will be loaded before the engines > plugin. > > IIRC, the idea is for "start_engine" to disappear as soon as rails > supports user-defined plugin load order. So long story short, I don''t > believe there''s a way to determine that load order atm, other than by > patching the rails source. > > cheers > Gerret > > On 1/31/06, Steve Ross <cwdinfo@gmail.com> wrote: > > I actually did it the other way around: zbundled_resource. > > > > But seriously, we deal with dependencies all over the development > > process. Ruby Gems are good with dependencies, and other parts of Rails > > are. Isn''t there a cleaner way to deal with this? > > > > Steve Ross > > > > Rick Olson wrote: > > > On 1/30/06, Steve Ross <cwdinfo@gmail.com> wrote: > > >> Is there a way to change plugin load order? > > >> > > >> Thanks > > > > > > Why not just fudge the names a bit? a_login_engine will cause it to > > > load first :) > > > > > > > > > -- > > > Rick Olson > > > http://techno-weenie.net > > > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- * J * ~
While the plugin load order hasn''t necessarily been fixed, I just want to mention that bundled_resource no longer loads application_helper, and therefore has no conflict with the engines plugin. It turns out the fix was simple: include bundle helper modules in the ActionView::Base class instead of the ApplicationHelper class. Works like a charm :) I wonder if engines could use this technique also? It might be nice for some functionality to be automagic so that no modification to ApplicationHelper is necessary. Duane On Jan 31, 2006, at 10:05 AM, James Adam wrote:> This issue isn''t really related to the fact that engines need to be > ''started'', as the problem would occur with if the file being require''d > at the top of application_helper.rb was a part of any plugin that > hadn''t been processed yet. > > The next release of Rails should make things *slightly* better, > because as I recall I had a patch accepted which added all the plugin > ''lib'' directories before performing any of the init.rb code. However > I''m not sure if that code remains intact. > > The ''best'' way that I can think of to avoid this issue at the moment > would be for plugins not to load files like application_helper. > However, I can perfectly understand why Duane has done this... > > - james > > On 1/31/06, Gerret Apelt <gerret.apelt@gmail.com> wrote: >> Steve, >> >> the engines plugin requires you to call "start_engine" for just this >> reason -- if your engine depends on another plugin, there''s no way to >> guarantee that the dependency will be loaded before the engines >> plugin. >> >> IIRC, the idea is for "start_engine" to disappear as soon as rails >> supports user-defined plugin load order. So long story short, I don''t >> believe there''s a way to determine that load order atm, other than by >> patching the rails source. >> >> cheers >> Gerret >> >> On 1/31/06, Steve Ross <cwdinfo@gmail.com> wrote: >>> I actually did it the other way around: zbundled_resource. >>> >>> But seriously, we deal with dependencies all over the development >>> process. Ruby Gems are good with dependencies, and other parts of >>> Rails >>> are. Isn''t there a cleaner way to deal with this? >>> >>> Steve Ross >>> >>> Rick Olson wrote: >>>> On 1/30/06, Steve Ross <cwdinfo@gmail.com> wrote: >>>>> Is there a way to change plugin load order? >>>>> >>>>> Thanks >>>> >>>> Why not just fudge the names a bit? a_login_engine will cause >>>> it to >>>> load first :) >>>> >>>> >>>> -- >>>> Rick Olson >>>> http://techno-weenie.net >>> >>> >>> -- >>> Posted via http://www.ruby-forum.com/. >>> _______________________________________________ >>> Rails mailing list >>> Rails@lists.rubyonrails.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > > > -- > * J * > ~ > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
It''s something I''ve thought about, and engine developers are of course free to do (since engines are still just plugins). At the same time, though, I can''t help but feel it''s a bit wrong to slip so deep into the class heirarchy, though I''m not sure why. Can someone please convince me that it''s a kosher thing to do? In all truth I would *love* to remove the need to add includes to ApplicationControlller/Helper... -- * J * ~ On 2/2/06, Duane Johnson <duane.johnson@gmail.com> wrote:> While the plugin load order hasn''t necessarily been fixed, I just > want to mention that bundled_resource no longer loads > application_helper, and therefore has no conflict with the engines > plugin. > > It turns out the fix was simple: include bundle helper modules in the > ActionView::Base class instead of the ApplicationHelper class. Works > like a charm :) > > I wonder if engines could use this technique also? It might be nice > for some functionality to be automagic so that no modification to > ApplicationHelper is necessary. > > Duane > > On Jan 31, 2006, at 10:05 AM, James Adam wrote: > > > This issue isn''t really related to the fact that engines need to be > > ''started'', as the problem would occur with if the file being require''d > > at the top of application_helper.rb was a part of any plugin that > > hadn''t been processed yet. > > > > The next release of Rails should make things *slightly* better, > > because as I recall I had a patch accepted which added all the plugin > > ''lib'' directories before performing any of the init.rb code. However > > I''m not sure if that code remains intact. > > > > The ''best'' way that I can think of to avoid this issue at the moment > > would be for plugins not to load files like application_helper. > > However, I can perfectly understand why Duane has done this... > > > > - james > > > > On 1/31/06, Gerret Apelt <gerret.apelt@gmail.com> wrote: > >> Steve, > >> > >> the engines plugin requires you to call "start_engine" for just this > >> reason -- if your engine depends on another plugin, there''s no way to > >> guarantee that the dependency will be loaded before the engines > >> plugin. > >> > >> IIRC, the idea is for "start_engine" to disappear as soon as rails > >> supports user-defined plugin load order. So long story short, I don''t > >> believe there''s a way to determine that load order atm, other than by > >> patching the rails source. > >> > >> cheers > >> Gerret > >> > >> On 1/31/06, Steve Ross <cwdinfo@gmail.com> wrote: > >>> I actually did it the other way around: zbundled_resource. > >>> > >>> But seriously, we deal with dependencies all over the development > >>> process. Ruby Gems are good with dependencies, and other parts of > >>> Rails > >>> are. Isn''t there a cleaner way to deal with this? > >>> > >>> Steve Ross > >>> > >>> Rick Olson wrote: > >>>> On 1/30/06, Steve Ross <cwdinfo@gmail.com> wrote: > >>>>> Is there a way to change plugin load order? > >>>>> > >>>>> Thanks > >>>> > >>>> Why not just fudge the names a bit? a_login_engine will cause > >>>> it to > >>>> load first :) > >>>> > >>>> > >>>> -- > >>>> Rick Olson > >>>> http://techno-weenie.net > >>> > >>>