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 16.03.2007 00:34
on 16.03.2007 14:32
On 3/15/07, James Ho <jho@zadspace.com> 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 :) > 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
on 16.03.2007 17:55
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