Rails Engines News

Engines 2.1.0 release

Sun, 01 Jun 2008 03:31:00 GMT

As I’m sure everyone knows, Rails 2.1.0 was released earlier today, and I’m pleased to say that the engines plugin has been keeping quietly up to date with the changes. Many of the improvements in Rails 2.1.0 have made the plugin simpler, most notably the refactoring of ActionView (see ActionView::TemplateFinder, for example). Thanks to everyone who’s contributed to this release so far; there are plenty of improvements that I’ve yet to integrate!

You can grab a compatible version of the plugin straight from github :

script/plugin install git://github.com/lazyatom/engines.git

Or, direct access to the 2.1.0 tag, in fancier git parlance:

cd vendor/plugins
git clone git://github.com/lazyatom/engines.git
git checkout 2.1.0

If you’re using SVN, do any of these instead (although I’m not sure how often I’ll be keeping that up to date)

script/plugin install engines
svn checkout http://svn.rails-engines.org/engines/tags/rel_2.1.0

As ever, feedback and bug reports are very welcome!

Merb slices, again

Sat, 24 May 2008 04:28:24 GMT

Michael Klishin keeps a great blog for updates to Merb, and I follow his posts regularly. I was a bit bemused to read his latest post about merb-slices, however:

The difference with Rails Engines is that merb-slices use Merb core API for plugins, and nothing else. It does not do crazy black magic, it does not use guesses and Ruby introspection to hook into framework boot process at “god knows when” point in time. It utilizes idea of merb-core to just be simple to extend. Where Rails engines add layers of magic by hooking into complicated Rails boot process with magical alias method chain, it also did not rely just on API in version 1.x. When Rails 2.0 came out with plugins API being refactored, Engines collapse on upgrade of your app.

Certainly in the past, the interaction between the engines plugin and Rails updates has been… well, interesting. That’s because at the time, the Rails core developers took a stance that they didn’t want to support ‘slice’ style development. The plugin mechanism in Rails 1.0 was simple and unsophisticated, so we had to do ‘crazy black magic’, as you call it, to get engines to work.

However, times have changed. Please take a look at how the plugin mechanism works in Rails 2.0. It’s designed to be cleanly extensible, so you don’t need to resort to ‘black magic’, and hopefully it succeeds at that. And a lot of those improvements have been a result (directly or indirectly) of the things I felt plugins should be able to do - the things that the engines plugin originally patched in. If you need some evidence of this, the current plugin mechanism was implemented by, well, me.

Probably future versions of Engines, like 2.5 or 3.0 will be much much cleaner and won’t use hacks, I do not know. I just think that Slices and Engines example shows how simple and modular code applied to simple task (extand darn load paths and register some routes; it is that simple) is beautiful, does not break and easy to comprehend compared to monuments of personal cleverness. It also shows how easy it is to hook into Merb boot process using one simple convention.

There are a couple of things going on here. Firstly, I think it’s great that merb can support changes in it’s behaviour very easily. As I said a few days back, to have that kind of extensibility supported cleanly by the framework makes life a lot easier. So Michael’s point here could just be that merb is cleaner internally that Rails is. Fine.

But - “Probably future versions of Engines, like 2.5 or 3.0 will be much much cleaner and won’t use hacks” - huh? Please point out the hacks you’re refering to. Have you actually looked at the engines plugin source code recently? This post reads to me as classic FUD about engines, feeding misconception back into public opinion because you don’t want ‘merb-slices’ to be attacked in the same way that Rails engines were a couple of years back.

It’s fine if you think that merb is ‘better’ than Rails, but if you’re going to decry code as hacky, at least be constructive about it.

Merb slices

Thu, 22 May 2008 04:15:17 GMT

Ezra just posted about a new feature for merb - slices. Seems like these cover much of what the engines plugin enables for Rails - sharing models, controllers, views and assets between your applications. It’s really great to see framework-level support for this kind of development style, as it can be incredibly powerful; certainly there’s a balance to be sought when sharing implementation between projects, but that balance is for the developer to gauge, without necessarily having to work against the framework. Great stuff!

Heading for Github

Mon, 28 Apr 2008 10:26:26 GMT

I’ve been using Git for a few months now, so I’m happy to say that the engines plugin development is going to be heading over to GitHub in the near future.

Engines 2.0 (ish)

Tue, 11 Dec 2007 06:02:00 GMT

Hi all,

Just a quick note to let you know, should it be relevant, that we’re readied a new release of the Engines plugin, revamped and ready for Rails 2.0, and would absolutely love for you to start using it and sending feedback about what’s broken, what’s missing and what could be improved.

Grab the plugin here, check out the README, and find out more after the cut…

Plugems, Welcome!

Wed, 02 May 2007 03:02:19 GMT

Revolution on Rails have finally released their solution to shared dependencies between Rails applications, which they have called Plugems (see what they’ve done there?). In their announcement they discuss some of the differences between plugins, “engines” (ahem!) and Plugems, and I think they’ve raised some interesting points.

Engines 1.2 Released

Sun, 04 Feb 2007 11:17:55 GMT

I’ve just pushed the 1.2 release of the engines plugin forward as the official release found by script/plugin. The 1.2 release is compatible with Rails 1.2, and undoubtedly the best release so far. It’s never been easier to make your plugins more powerful, and I’m very happy with some of the new features 1.2 gives, including routes in plugins and a new “best-practise” for sharing migrations.

Engines are dead…

The new 1.2 release also represents a psychological “reboot” for the engines plugin. Thanks to some of the features we managed to contribute to Rails itself, any plugin can be enhanced by the engines plugin. This is the final blow to the unfortunate misunderstanding that “engines are evil”, because there’s literally no such thing as “an engine” anymore. The engines plugin is just a plugin that makes other plugins more powerful.

Below the cut you can read about some of the enhancements that the engines plugin contributes to making sharing code amongst your projects even simpler.

Farewell, login_engine.

Tue, 23 Jan 2007 04:09:52 GMT

While I prepare for the upcoming release of the engines plugin 1.2 release, I should also add that the “login engine” and “user engine” won’t be joining us on the journey to 1.2.

Engines are dead! Long live engines!

Wed, 03 Jan 2007 08:10:50 GMT

With the upcoming release of Rails 1.2, I thought it was a great opportunity to revisit the way that the engines plugin operates internally. Over the past year or so, the engines plugin has caused quite a stir (and picked up a few admirers, but despite misunderstandings and opinion pieces, people still seem to find it useful.

However, Rails is always changing, and so the engines plugin must change as well…

Engines vs. appable_plugins?

Wed, 15 Nov 2006 03:35:56 GMT

(This was posted as a response to the article on pluginaweek.org here, but is reproduced here so I can expand a bit more…)

Hi Aaron & Co.,

Some clarifications, in particular what the engines plugin “doesn’t” do:

Supports sharing of model code.

Unless Rails has changed such that it consistently requires/loads model code with a path, I’m not sure you can consistently mix in model code. The only reason this was never supported by engines is because there’s no way to tell the if ‘user.rb’ is a model or a regular Ruby library at the point where you’d want to do code mixing…