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.
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:
In addition to the resources that Greg mentioned, check out this too:
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.
