Engines Development Best Practices

We have been developing with engines version 1.1.2 for some time.
However, we are going through a major code cleanup. Our development
happened organically, first we built a single rails app, then we
realized we needed to break our efforts up into several rails apps.
Thus, we discovered engines and used them to “peel” out a slice of our
main application so that we may share it amongst our other apps (mainly
models). Later this grew to a few more engines that included the full
MVC compliment.

As we reboot our development efforts in rails 1.2 we are now developing
our applications with engines as a part of the infrastructure from the
ground up. Thus, we need to be developing the underlying engines while
at the same time sharing across multiple apps all of which are under
active development and may be changing parts of the engine at the same
time. We are using svn externals to keep everything up to date.

Given our development model, if things need to be added to the engine
such as models, migrations and controllers what is the best way to do
this? Since a plugin does not have it’s own generators it would be quite
a maintenance nightmare, not to mention destroying the elegance and
abstraction of engines, to generate them in the top level rails apps and
keep copying everything down to the engine.

Our thought was to make the engine itself a rails app, copy in the
plugin specific elements and change public to assets then include the
whole thing in vendor/plugins. Any unused elements would simply be
ignored or we could strip them out. That way we can use the generators
and other support files a complete rails app would provide. Are there
any ramifications to this approach?

Are there any established best practices for this type of situation?
What do we do about unit testing the engine by itself?

Any advice or experience is appreciated.

-James

On 3/15/07, James Ho [email protected] wrote:

Given our development model, if things need to be added to the engine
such as models, migrations and controllers what is the best way to do
this? Since a plugin does not have it’s own generators it would be quite
a maintenance nightmare, not to mention destroying the elegance and
abstraction of engines, to generate them in the top level rails apps and
keep copying everything down to the engine.

This might not be the solution you’re looking for, but I simply don’t
use generators when adding things to the engine. As a side effect I
found it forced me to learn the rails structure a bit better :slight_smile:

What do we do about unit testing the engine by itself?

I’m assuming you’re running the latest engines plugin since you’re
using rails 1.2. So if you put your engine tests in
vendor/plugins/engine_name/test they can be run with rake test:plugins
PLUGIN=engine_name

Justin

Thanks for the note on testing.

I think what we have decided to is develop the plugin in a stand alone
rails app that has it’s own engine. Then as as deployment process, copy
out all the appropriate files from the rails app down into the
engine/plugin and let that be the master plugin that we deploy out to
our other apps.

Hopefully, tis will allow us to have good abstraction while at the same
time keep the engine lightweight.

-J

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs