Forum: Rails Engines development Rails 1.2 approacheth and the engines plugin may be a'changi

Hello all,

Firstly, thanks again for all your support with the development of
this plugin; arguably one of the most complex extensions of Rails, it
would be much harder to keep it all together without your feedback.

I thought it might be a good idea to fulfil the purpose of this list
by sharing some of my plans for the next release of Rails (1.2).
Rather than being an incremental release, I'm starting with a fresh
codebase, a fresh & clean API and some possibly-significant changes in
functionality.

Engines are dead, long live engines
-------------------------------------------------

Probably the biggest change that I'd like to undertake (and have
already started developing) is the obliteration of the notion of 'an
engine'. It seems clear now, a year in, that the biggest hurdle people
have when thinking about the extra functionality we're aiming at with
engines is the notion of 'installing an engine'. It feels big, it
feels clunky, and basically it paints the wrong picture. So engines
are to be no more.

Instead, I'd like to open up the functionality of the engines plugin
to *every* plugin the user has. If a plugin has an /app directory,
then it'll get added to the appropriate load paths. If it has a
/public folder, it'll get synced into the public space and the
action_view helpers will work with that. Now, you and I know that the
only thing that really makes, say, the 'login engine' different from
any other plugin is the fact that it needs to include an
'init_engine.rb' file. This will be one of the biggest changes that
I'm proposing: init_engine.rb will revert to being a vanilla-flavoured
init.rb.


And yes, Vanilla, not Neopolitan
--------------------------------------------

Here's the other significant change. The reason why init_engine.rb
exists is so that we could control the load order of enginized
plugins, and the reason behind this was twofold:

1. So that the engines plugin would be loaded before any plugins
(engines) that needed it
2. So that engines could require code from other engines

Feature 1 should no longer be an issue, thanks to some extra work I
can do, but I'm proposing that feature 2 should be abandoned. What I
mean is - unless Rails Core deems to allow controlling of plugin load
order, I  won't be providing any guarantees that plugin_x is loaded
before plugin_y. In our experience with the only existing layering of
engines (login + user), it leads to more complication than anything
else. Shucks! Who knew.


Other stuff too
-------------------

Some other stuff will be changing too, including some nifty tricks
with migrations and routing, but those two changes above are the most
significant and I thought it best to let folks know my plans before
1.2 really comes out.

Any thoughts, anyone? Bueller? Anyone?

On 12/8/06, James Adam <james.adam@gmail.com> wrote:
> Instead, I'd like to open up the functionality of the engines plugin
> to *every* plugin the user has. If a plugin has an /app directory,
> then it'll get added to the appropriate load paths. If it has a
> /public folder, it'll get synced into the public space and the
> action_view helpers will work with that. Now, you and I know that the
> only thing that really makes, say, the 'login engine' different from
> any other plugin is the fact that it needs to include an
> 'init_engine.rb' file. This will be one of the biggest changes that
> I'm proposing: init_engine.rb will revert to being a vanilla-flavoured
> init.rb.

Wonderful!

Sorry, that is all. I just wanted to give a big thumbs up on this
shift in thinking.

Thanks,
Justin

Hi James -

First off, thanks to you and the rest of the engines team for all of
the hard work in this area.  Engines never felt big and clunky to me,
rather they filled a great need in our shop for full-stack (views,
migrations, controllers, models) bundled code re-use, and now we've
come to depend on them.  Engines have saved us lots and lots of
time ... long live engines! I'm all for progress, but should I start
laying awake at night worrying about backwards compatibility? I love
'fresh and clean' but of course that also means 'not battle tested'...

Many thanks again

Henry

Oh yeah, I forgot to mention: one of the reasons we love engines so
much is that we can control the load order! For what it's worth, I
think it's a horrible idea not be able to control it.  We have
several instances where we need engine x in before y ... am I the
only one?

On 12/8/06, Henry <hpoydar@gmail.com> wrote:
> Oh yeah, I forgot to mention: one of the reasons we love engines so
> much is that we can control the load order! For what it's worth, I
> think it's a horrible idea not be able to control it.  We have
> several instances where we need engine x in before y ... am I the
> only one?

I have engines that must load in a particular order. That is one great
thing about engines. I can add functionality to layers of a Rails app
like subclassing a class in oop programming.

I hope that order of loading stays. I wish it was a rails core feature
where specified plugins load in a particluar order and then the
remainder of plugins load in any order. I don't know why the Rails
core won't let developers shoot themselves in the foot if that is what
they think it is doing.

I wish engines were in Rails core too :)

Peter

OK - I think I've figured out a reasonable way to support legacy
behaviour, but also make the progressive changes that I want Engines
1.2 to support.

*IF* you need to control the load order of your plugins, then keep the
current convention of replacing init.rb with init_engine.
Engines.start can then be called to load these plugins in a specific
order.

However, I'm not going to be promoting the 'Engines.start' behaviour
anymore - consider it a "secret" feature until Rails fixes their
plugin loading system such that it respects orderings.

- James