Rails Engines News

Engines at RailsConf

Mon, 18 May 2009 03:19:00 GMT

I gave my first presentation since Canada On Rails on Rails Engines at this year’s RailsConf, to cover the new support in Rails 2.3 for engines, including the problems you might encounter, how to handle them, and some advice about how to work effectively with this kind of re-use.

Edge engines now compatible with Rails 2.3

Mon, 20 Apr 2009 03:11:00 GMT

I’ve just made the appropriate changes to bring the engines plugin into compatibility with Rails 2.3, and the engine features it implements. You can find these changes in the ‘edge’ branch of the git repository, which I’m currently working on now.

Engines in Rails 2.3

Mon, 02 Feb 2009 00:40:00 GMT

Some support for ‘engine’ plugins has been merged into the Rails core codebase in Rails 2.3. In this guide, I’ll try to explain what works, what has changed, and what is currently missing compared to the original engines plugin.

What works

The core of the engines plugin has always been sharing controllers, models and views seamlessly from within a plugin. I’m glad to say that this is now fully supported by Rails itself. The same app/controllers and app/models folders will be added to the $LOAD_PATH in the appropriate order.

Secondly, loading views also works in the same way you’d expect. This means that you can override views and partials in your application, just like with the original engines plugin.

What has changed

Rails 2.3 also brings support for loading routes from plugins, but the technique has slightly changed. With Rails 2.3, create your routing file in your plugin as config/routes.rb (the engines plugin did not require the config directory).

The other change is that they should be formatted as a normal routing file. For example, with the file app/controllers/awesome_controller.rb in your plugin, the config/routes.rb could be

ActionController::Routing::Routes.draw do |map|
  map.blah '/awesome', :controller => 'awesome'
end

The main difference here is that you need to include the ActionController::Routing::Routes.draw line.

What is missing

Sadly, there are a few features of the engines plugin that have not been ported to Rails 2.3 yet. Those are:

Migrations from plugins

It’s not possibly to run migrations from plugins with Rails 2.3. There are a number of reasons for this, but principally the problem comes from needing to be able to determine which migrations from which plugins have already run.

If you’re using timestamped migrations there is no problem, since the likelihood of a timestamp collision is quite low. In this case, I would recommend writing a simple task or script to copy migrations from your plugin into the main db/migrate directory. It’s important that the migrations are anchored in some way to the main migration directory, since some folks use migrations to recreate their database rather than schema.rb, and so the set of migrations should accurately reflect the actual state of the application at any point in time.

If you are not using timestamped migrations, this is a bigger problem. Imagine you are developing your application, and have several migrations:

/my_app/db/migrate/001_create_users.rb
/my_app/db/migrate/002_add_widgets.rb
/my_app/db/migrate/003_reticulate_splines.rb

You then install a plugin with some migrations:

/my_app/vendor/plugins/my_plugin/db/migrate/001_install_the_awesome.rb

We now have two migrations with the version ‘1’ - one from the app (which has probably already run), and one pending from the plugin. There’s no way to tell, at the moment, that the plugin migration needs to be run.

I have some ideas for how to fix this, and so hopefully we’ll see some progress soon.

Public Assets in plugins

The engines plugin will mirror files from public or assets directories into the main application public directory, so that those files can be served directly to browsers. The plugin also augmented some of the view helpers so they could reference these files.

Rails 2.3 won’t automatically do this for you, but it shouldn’t be too arduous to write a few lines of code in init.rb to copy files into the public directory. However, without the helper additions of the engines plugin, your files won’t be automatically ‘namespaced’ according to plugin, so if two plugins try to copy a file called styles.css, one will overwrite the other. The solution? Try copying your files to a unique filename or subdirectory to avoid these clashes.

Code mixing

Rails 2.3 doesn’t attempt to do any of the ‘code mixing’ that the engines plugin does. For those of you not in the know, this is the functionality that lets your application override a single method in a controller or helper, without having to copy the whole file from the plugin into your application.

I cannot say for sure, but I doubt this feature will ever make it into Rails itself, and to be honest, I think that’s probably a good thing. While the code mixing mechanism is quite neat, there are other ways of overriding the implementation of methods which are more typically Rubyish, and involve less magic. I’ll try and post some examples here soon.

There you go

I hope that’s outlined the engines support in Rails 2.3 in a reasonably clear way. I hope that we’ll be able to merge some of the simpler missing features into the core (migrations and assets, notable) soon. Maybe you’re the one to write that patch? PDI :)

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.