Rails 3: Engines or/and Railties. How to use them?

zeka · September 24, 2010, 11:38pm

Howdy all,

I have spent a couple of days trying to figure out how to put
different pieces of our (quite large) app into components.

The idea was to use Rails 3 Engines/Railties and place them in /lib.
Each would have its own [app/views, app/helpers, app/models and app/
controllers]

We also needed an ability for those components to override views/
helpers/controllers in the parent “container app”.

No luck there. Perhaps this snippet illustrates better what I was
trying to do:
http://pastie.org/1180038

Is it what engines/railties are for?
And if not, how can I “componentize” some of the partials we have?

Our app needs certain pieces present/removed depending on which
installation we do. Right now we have a bunch of if/elses that depend
on configuration, and it looks a bit ugly, so I wanted to take some
partials+controllers+models and move them into lib/xxx and then by
including/excluding a single “require lib/xxx” I was planning to
enable/disable them.

Is it possible?
Thank you

zeka · September 25, 2010, 8:00pm

zeka wrote:

I have spent a couple of days trying to figure out how to put
different pieces of our (quite large) app into components.

The idea was to use Rails 3 Engines/Railties and place them in /lib.
Each would have its own [app/views, app/helpers, app/models and app/
controllers]

We also needed an ability for those components to override views/
helpers/controllers in the parent “container app”.

No luck there. Perhaps this snippet illustrates better what I was
trying to do: http://pastie.org/1180038

Is it what engines/railties are for?
And if not, how can I “componentize” some of the partials we have?

Our app needs certain pieces present/removed depending on which
installation we do. Right now we have a bunch of if/elses that depend
on configuration, and it looks a bit ugly, so I wanted to take some
partials+controllers+models and move them into lib/xxx and then by
including/excluding a single “require lib/xxx” I was planning to
enable/disable them.

This is a pretty big topic, and I haven’t found a good all-in-one
resource either, but after a few days of poking around and re-reading
articles, I’ve just started to componentize core libs I use in my apps
as well.

First, as for the path overrides, no need to inject paths yourself.
Rails will look in certain places if you provide those places. You tried
using /lib, but the correct place is in /vendor/plugins. Rails will look
inside all /vendor/plugins/{WHATEVER}/app/views folders. So you were
close. Don’t bother with the path shift business.

Making a plugin is as simple as using the rails generator, but making
engines requires a slightly different organization of the files. This is
a good place to start, but there’s some out of date info. The /rails
folder inside the plugin that the article suggests making is obsolete.

As for creating proper Rails3 engines, these are the links that I went
round and round with until it started to make sense:

gist.github.com

https://gist.github.com/josevalim/e139fa787aa882c0aa9c

1_railtie.rdoc

Railtie is the core of the Rails Framework and provides several hooks to extend
Rails and/or modify the initialization process.

Every major component of Rails (Action Mailer, Action Controller,
Action View, Active Record and Active Resource) are all Railties, so each of
them is responsible to set their own initialization. This makes, for example,
Rails absent of any ActiveRecord hook, allowing any other ORM to hook in.

Developing a Rails extension does not _require_ any implementation of
Railtie, but if you need to interact with the Rails framework

This file has been truncated. show original

2_engine.rdoc

Rails::Engine allows you to wrap a specific Rails application and share it accross
different applications. Since Rails 3.0, your Rails::Application is nothing
more than an Engine, thus your engines will behave much more closer to an application
since then.

Any Rails::Engine is also a Rails::Railtie, so the same methods (like rake_tasks and
generators) and configuration available in the latter can also be used in the former.

== Creating an Engine

This file has been truncated. show original

3_plugin.rdoc

Rails::Plugin is nothing more than a Rails::Engine, but since it's loaded too late
in the boot process, it does not have the same configuration powers as a bare
Rails::Engine.

Opposite to Rails::Railtie and Rails::Engine, you are not supposed to inherit from
Rails::Plugin. Rails::Plugin is automatically configured to be an engine by simply
placing inside vendor/plugins. Since this is done automatically, you actually cannot
declare a Rails::Engine inside your Plugin, otherwise it would cause the same files
to be loaded twice. This means that if you want to ship an Engine as gem it cannot
be used as plugin and vice-versa.

This file has been truncated. show original

There are more than three files. show original

http://www.themodestrubyist.com/2010/03/01/rails-3-plugins---part-1---the-big-picture/
http://www.themodestrubyist.com/2010/03/05/rails-3-plugins---part-2---writing-an-engine/

After that you start making your engines and plugins into gem, and they
become even easierto use in multiple projects.

Hope that gives you a some help.

– gw

zeka · September 27, 2010, 3:13am

In addition to the resources that Greg mentioned, check out this too:
http://keithschacht.com/creating-a-rails-3-engine-plugin-gem/

The one advantage I found of putting your shared resource into a plugin
and storing in vendor/plugins is that while you’re editing the project
it’s easy to peek into that directory to figure out what view you want
to override. It’s really part of the same codebase whereas when it’s
packaged in a gem, it’s usually a whole separate project (and separate
repo) so it can be an extra step in your workflow to reference the
resource’s code.

But that advantage is also it’s disadvantage. By packaging your plugin
into a full engine and packaging up as a gem, you get two advantages:
gems are easier to share across projects, it’s easier to manage versions
(you can specify the exact gem version you want in your gemfile), and
they’re easier to distribute if you want to share them with others.

-Keith

zeka wrote:

Howdy all,

I have spent a couple of days trying to figure out how to put
different pieces of our (quite large) app into components.

The idea was to use Rails 3 Engines/Railties and place them in /lib.
Each would have its own [app/views, app/helpers, app/models and app/
controllers]

We also needed an ability for those components to override views/
helpers/controllers in the parent “container app”.

No luck there. Perhaps this snippet illustrates better what I was
trying to do:
http://pastie.org/1180038

Is it what engines/railties are for?
And if not, how can I “componentize” some of the partials we have?

Our app needs certain pieces present/removed depending on which
installation we do. Right now we have a bunch of if/elses that depend
on configuration, and it looks a bit ugly, so I wanted to take some
partials+controllers+models and move them into lib/xxx and then by
including/excluding a single “require lib/xxx” I was planning to
enable/disable them.

Is it possible?
Thank you