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
