This post is intended to initiate a discussion about extended the default behavior of rails plugin new to support nested engines as discussed in the presentation Rails Engines Patterns by Andy Maleh<http://confreaks.com/videos/863-railsconf2012-railes-engines-patterns>.
Currently the only way to implement a nested rails engine pattern within a set of gems, is to do so manually. A great example is RefineryCMS<https://github.com/refinery/refinerycms> . *Refinery’s architecture*<http://refinerycms.com/guides/getting-started#refinery-s-architecture> * "Refinery comprises of several Rails Engines. Each extension acts like a mini Rails application with its own routes and views. Refinery is architected like this so that it keeps out of the way of any custom development you will do in the /app directory."* While inheriting common domain from the RefineryCMS core. Refinery ships with a dependency engine generator, which is exactly the type of functionality that rails plugin new should have rails generate refinery:engine singular_model_name attribute:type [attribute:type ...] A use case would be create a core engine (MyEngine) which allows the nested dependency engines (MyEngine::Blog, MyEngine::Pages) to share common domain, like CRUD, Taggable, Searchable, etc, while keeping the engine code DRY and isolated from the main app (MyApp). Proposed implementation A: rails plugin new MyEngine-Blog --engine Proposed implementation B: rails engine new MyEngine-Blog --mountable rails engine new MyEngine-Blog --gem #Which would gemify the engine Thoughts? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
