Rails Engines - All Site Updates

Frequently Asked Questions

Wed, 30 Aug 2006 06:13:38 GMT

Engines vs Generators

Engines could be considered in many ways the natural successor to Rails’ generators:

Both are mechanisms for packaging up disparate groups of files which must be placed throughout your whole application directory structure
Both provide controllers, models, libraries and views, along with schema information, tests and helpers to be used throughout your application’s code.

Oh God, What Have We Done?

This was something of a response to misunderstandings about what Engines are. For more background you might want to read DHH’s first post about engines and this.

Issue Tracker Login Information

I hate spam, and no more so that on issue tracking websites. To log into http://dev.rails-engines.org and comment or create new tickets, you need to login:

  login: engines
  password: engines

You can login in here.

Development

Wed, 30 Aug 2006 06:11:07 GMT

Read the README!

If you’re interested in developing plugins that ultilise the engines plugin, the first thing you need to read is the engines plugin README, which lays down all the basics about how it enhances Rails’ own plugin mechanism.

Tutorials

Gwyn Morfey has written a guide building plugins that can take advantage of the engines plugin’s features.

Joe at AlterLabs also wrote one of the best introductions to developing an engine (thought this has not been updated to reflect the 1.2 release of the engines plugin yet).

Other Information

Introduction

Wed, 30 Aug 2006 04:49:24 GMT

The engines plugin? Huh?

The engines plugin enhances Rails’ own plugin framework, making it simple to share controllers, helpers, models, public assets, routes and migrations in plugins.

It enables plugins to carry whole chunks of functionality into your existing application without affecting any of your existing code. They could also be described as application aspects, or vertical application slices - top-to-bottom units which provide full MVC coverage for a certain, specific application function.

Alternatively, you can use the engines plugin to share the smallest, simplest assets including common migrations, javascripts, stylesheets or images.

See the engines plugin in action

~~In true Rails style, we’ve got a demo video (Quicktime, 13MB) all pipin’-hot and ready to serve ya!~~ This video refers to an old version of the engines plugin; I hope to upload an updated one soon, highlighting many of the new features. It’s also work noting that it demonstrates the login engine, which has now been deprecated.

If you don’t like video, then head straight over to the engines plugin README.

Installation

See the Download page for info on setting up the main Engines plugin.

More Information

More information can be found all over this site, but in particular you might want to check out the Frequently Asked Questions and the Developer documentation.

Bugs and Issues

Wed, 30 Aug 2006 04:42:54 GMT

If you’re having problems with engines, there are quite a few places to look for help:

Our Lighthouse page
- Open Tickets
The mailing lists:
- If you’re having problems with a specific engine, please post to the engine-users mailing list;
- Discussion of the engines plugin internals and bug reports go to engine-developers.
The rails mailing list itself: rubyonrails-talk@googlegroups.com

Download

Wed, 30 Aug 2006 04:16:00 GMT

There are quite a few ways to get your hands on the various engines available. The first thing to do in any case is to get the Engines plugin itself, which is what we’ll cover here.

Rails’ own `script/plugin` command

The first thing to do is update the plugin command’s list of download sources:

$ ruby script/plugin discover

Now we can install the actual Engines plugin:

$ ruby script/plugin install engines

Alternately, you can explicitly specify the location from which to download and install the engines plugin:

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

From this point you can now install plugins as normal - any additional files each plugin provides will automatically become available when your Rails application loads.

git

The engines plugin development mainly happens using git now. Find out more at github…

SVN

The old, irregularly-updated Rails Engines Subversion repository can currently be found at http://svn.rails-engines.org/. The layout for this repository is discussed here.

News

Wed, 30 Aug 2006 03:15:29 GMT

Engines 2.1.0 release

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!

Posted by James Adam on Jun 01, 2008

Merb slices, again

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.

Posted by James Adam on May 24, 2008

Merb slices

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!

Posted by James Adam on May 22, 2008

Heading for Github

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.

Posted by James Adam on Apr 28, 2008

Engines 2.0 (ish)

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…

Posted by James Adam on Dec 11, 2007

Rails Engines - All Site Updates

Frequently Asked Questions

Development

Read the README!

Tutorials

Other Information

Introduction

The engines plugin? Huh?

See the engines plugin in action

Installation

More Information

Bugs and Issues

Download

Rails’ own script/plugin command

git

SVN

News

Rails’ own `script/plugin` command