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 2006-12-09 00:36
on 2006-12-09 00:44
On 12/8/06, James Adam <email@example.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
on 2006-12-09 00:54
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
on 2006-12-09 01:02
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 2006-12-09 01:08
On 12/8/06, Henry <firstname.lastname@example.org> 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
on 2006-12-14 12:11
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