How to Affect Plugin Load Order

Rails
1

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

2

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

3

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

4

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

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

6

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

7

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