How to Affect Plugin Load Order

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

On 1/30/06, Steve R. [email protected] 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 :slight_smile:


Rick O.
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 R.

Rick O. wrote:

On 1/30/06, Steve R. [email protected] 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 :slight_smile:


Rick O.
http://techno-weenie.net

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 A. [email protected] wrote:

patching the rails source.

[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Rails mailing list
[email protected]
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 :slight_smile:

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

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

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 *
    ~

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs