I’m working on application which can be logically grouped into a core engine, and business domain modules. The business domain modules essentially encapsulate code which is specific to our customers’ businesses. We initially separated this out using the root rails structure for our core engine, and having all customer code in separate plugins.
But we’ve run into various problems with this approach, most of which can probably be put down to Rails class reloading in the development environment. While we have managed to get reloading largely working, we’ve run into weird Rails bugs with partially unloaded classes combined with the Rails.cache.
What I would like to know is, are we abusing the intended usage pattern for Rails plugins? Was packaging up aspects of our application as plugins the right move? And is there a better way to do it? Or should we rather soldier on and try sort out these remaining issues?
We’re currently moving toward rewriting the plugins as modules within the root rails structure, but I must confess I rather like the elegance of plugin mini-application directory structure.
Brendon McLean.
My large app includes several plugins that are private to the app. I agree that plugins can nicely isolate sets of functionality.
I haven’t run into the loading problem that you describe since I turned off the dynamic class reloading in dev mode.
Why not have dynamic class reloading? It seemed to slow things down too much. Easier to cntrl-c and restart the test mongrel when needed. After all, I usually run a given iteration of the code for more than one html request/reply cycle before making further changes.
Your original plugin architecture sounds like it was solving several problems for you. I’d first try to change the tool (turn off dynamic reloads) before changing the software architecture.