Is it possible to embed (nest) Rails engines inside of other Rails engines?
I am working on a Rails 3.1 app that I want to split up into a couple different sections and turn each section into a Rails engines. However, I also want to be able to turn the entire app into a Rails engine.
Possible, but not easy.
http://confreaks.com/videos/863-railsconf2012-railes-engines-patterns
Think what benefits you get from nested engines. Nesting means coupling and if you want to improve maintainability and testability you should reduce that coupling.
I think the ideal engine should be easily able to run standalone - this is why you have dummy app created in test directory. Sure you can keep nesting or keep common stuff in main app but you will see that with growing code base it is harder to maintain tests with tightly coupled dependencies.
As a solution I would try composition instead. Put engine directories next to each other but use nested modules:
engines/foo_project - namespaced FooProject::*
engines/foo_project_user - namespaced FooProjectUser::* or FooProject::User::*
If there is something which FooProject::User needs from FooProject then ideally it shoud be extracted into another engine like FooProject::Layout. In another direction the main app should wire User stuff into FooProject. Add integration tests on the main app level and you get ordnung.
Related
I'm currently upgrading an app to rails 4. I planned to install this app for few persons but they have different needs. I decide to use this upgrading version time to put some of my models in engines. The objective is to spend less time tweaking the app for the needs of the situation. The core app will manage the basic resources and the engines will add features (The app is managing membership for small organizations).
I read a lot documentation including the "guides". I tested some engines to see the behaviour of the app. Here are my questions I couldn't answer by my searches:
1 - Naming convention:
How do you name your engines? My first attempt was to name it by their function but when I generated my first model I saw that I can't use the function name for my model.
I was think about something like: Coreappname_functionality
for exemple I want to add activities for my members the engine will be named : member_activities
2 - full vs mountable
I read a lot about this subject, lot of people seem to use mountable engines. I try both of them and I think that the full option is really fast to implement (no routing, no namespace isolation that I have to be aware of). But I also understand the risk for the class collisions. If I'm the only one writing code for this app is it a bad habit to use a full engine(it's just a laziness question). Are there others advantages of mountable engine even if I'm not planning to use them in another app?
3 - "if engine exists?"
Inside the core app i'll put the code that all the engines need. For example inside the side bar I want to display the list of the last activities but only if the activities engine is used. The objective is to put all the necessary code inside the core app but use this code depending on the present of engines or not.
During my test time I used:
if defined? Activity
#activities = Activity.all
end
and render it the views something like this:
<% if defined? Activity %>
<h3><%= #activities.first.title %></h3>
<% end %>
It's working well but I'm not sure that it is a good practice. Is there an alternative?
Do you have any advices before I jump in the engine's world?
I prefer posting my questions before instead of posting my errors after the attempt!
For anybody reading that...
I think there is a misunderstanding about what an isolated engine is. In fact it is a bit confusing. Some may think that's choosing between isolated and not isolated is a bit like a matter of preference. But that's not entirely true.
Isolated engine is just that. An isolated engine. It's not suitable for a "module" of your application. It's more like a "subapplication" of you application. The difference is critical. Modules of your application probably will share models, api or some business logic. Still, encapsulation of responsibilities is important, but there will be some connections. For example probably almost all of your modules will be using something like EventDispatcher module. While isolated engine is a whole application on it's own. Although it could use models from the host application it can't use models from different isolated engine (at least without hacks, a lot of pain in 'certain situations' and that's generally a bad idea causing bad design).
So if you try to implement your app modules using isolated engines your probably end up storing all your models in main/host application to be reusable between your - in fact - subapplications. Probably the same with views. And maybe with assets too. And if some business logic have to be shared it probably would end up in main application too. So that's basically defeats the whole purpose. That's why you should use not isolated engines for your modules. While isolated engines are good for a - totally encapsulated - subapplication. For example if you want to have an e-commerce shop alongside with your main application (spree gem does exactly that).
A more enterprise example would be an ERP system. It could have subapplications like: CRM, Resource Management, etc (isolated engines). And those subapplications could have their own modules (not isolated engines).
Just for the completeness of my answer. As a isolated engine i mean that generated using rails plugin new engine_name --mountable, while a not isolated would be generated using rails plugin new engine_name --full.
Disclaimer:
Maybe there are some cases when you would want to go different way (probably when implementing some kind of magic gem doing some magic things), but that's up to you to figure it out. By this answer I just mean it should be applicable in most applications.
In computing terms, an engine is something that is continually producing output based on input. But in Ruby, the term seems a little bit loose. The people who've created Refinery CMS have taken to calling gems that extend the functionality of their system, 'engines'.
Basically, what I want to know is, is Spree, the open source ecommerce cms written in ruby, an engine? Would calling it the 'spree engine' be correct?
As defined by Rails, an Engine is a lot like an application within an application. Spree is one of these, and there are others. Each engine has its own app folder with the same sort of structure you'd see in a top-level application.
You can combine one or more engines together into an application, then add your own functionality on top. That's what makes systems like Spree far more flexible than a fixed-puropose Rails app that you have limited control over.
Things that extend Rails are only truly engines if they are self-contained applications. Many gems add functionality that's much more specific than that, so are better termed "plug-ins" or "modules" depending on the phrasing.
It's actually pretty easy to build your own engine and can be useful for separating and re-using code across several different applications.
I think that there is quite good explanation in guide Getting Started with Engines.
Spree is actually comprised of many engines...
The overcooked version: Engines come kitted with (many of) the guts of a typical rails application, with a few bonuses: namespacing out of the box, generators for easily copying migrations, and the ability to mount it in another rails application.
From http://guides.rubyonrails.org/engines.html
1 What are engines?
Engines can be considered miniature applications that provide functionality to their host applications. A Rails application is actually just a "supercharged" engine, with the Rails::Application class inheriting a lot of its behavior from Rails::Engine.
Try to read this guide: http://guides.rubyonrails.org/engines.html and also this cast: http://railscasts.com/episodes/277-mountable-engines
Just finished watching "Railscast 277" on mountable engines in Rails, what are practical uses of mountable engines?
One of the best examples would be Devise (for authentication) which is an engine (plugin) but its mounted as a shared-engine; you also get namespaced engines and this helps to retain a sense of context.
Another example would be the Active Admin add-on, error notification plugins...and a whole lot more. In terms of 'mounting' from a purely routing point of view, you can see how — with a namespaced engine you can serve a completely isolated rails app from a route from within your app itself.
You should consider reading this as well.
Two major uses:
Reusability. Gems that expose a lot of application functionality are often distributed as engines.
Modularity. Particularly for large applications, there are often parts of the application that don't seem like they want to be mixed in with the main application, yet are too closely related to be extracted to entirely separate applications. Engines can work well for this.
Spree takes this to extremes: the core Spree framework is the main Rails application, and to customize it, you write engines. This means you're never modifying the Spree core directly.
Hypothetical question (at the moment!)
Suppose I have a great idea for an application. It acts on data which can be well-represented by tables in a relational database, using interlinked objects which represent those tables. It supports a well-defined API for interacting with (Creating, Reading, Updating, Deleting) those objects, and viewing information about them.
In short, it's a perfect fit for Rails... except it doesn't want to be a web-app. Perhaps it wants a Command Line interface; or an OS-native dialog-based interface; or perhaps it wants to present itself as a resource to other apps. Whatever - it just isn't designed to present itself over HTTP.
These questions suggest it's certainly possible, but both approach the problem from the point of view of adapting an existing web-app to have an additional, non-web, interface.
I'm interested in knowing what the best way to create such an app would be. Would you be best to rails new non_web_app, in order to get the skeleton built "for free", then write some "normal" Ruby code that requires config/environment - but then you have a lot of web-centric cruft that you don't need? Or would it be better to roll up your sleeves and build it from whole cloth, taking just the libraries you need and manually writing any required configuration?
If the latter, what exactly is needed to make a Rails app, but without the web bits?
If you want to access the Rails ORM to develop a CRUD non-web application, just include ActiveRecord in your own Ruby script; you will avoid using a lot of Rails modules you probably don't need (routing, template generator, ...) Here is an example of how to do it.
If you prefer to have the full Rails stack, do not run your Rails web app in an application server (WEBrick, Passenger, Mongrel, ...) to avoid any HTTP exposure, and interact with your application using tasks or the rails console.
I would avoid taking Rails too far off the rails. If I were doing this and felt that the gains of rails w/o the web stuff I'd do the following:
rails new non_web_app
and ignore the webbish cruft and use rails to generate models. In this way you get the tight, comfortable database behavior and can tie various gems in as you want to augment those models. I'd not bother implementing views, of course, and I'd consider implementing controllers in which the various render bits are removed and to use you instantiate an instance of the controller and call the action directly. This means the controller represents your API into your business logic still but the "views" it now "renders" are simply the return of the data output.
Then you could simply strip out the bits you do not need...the public directory, the view structure under app, config/routes.rb, etc. You'll need to test those changes incrementally and make sure that removing some now extraneous bit doesn't throw the Rails world into chaos.
Rails is for Web apps. That means HTTP. Now, you could package a Web app so that it runs on the desktop instead, or you could use ActiveRecord with a desktop application framework like Monkeybars.
I have a rails app which contains some fairly generic functionality (eg managing users). I would like to use that common functionality in other rails apps without copying it. The hard part seems to be that this code contains a number of models, controllers and views.
I know that gems and plug-ins allow code to be shared but they seem to apply more to sharing utility and library functionality rather than core parts of an app.
Any advice on how to do this would be greatly appreciated.
We are working with a Rails engine to share functionality between client projects and have gotten quite far with it. The engine contains controllers, models, views, and even routes. It provides core functions needed in each project (access to our in-house content management system) so projects don't have to start from scratch.
Most of the code has been structured in a way that it can be easily extended or overwritten where needed in the projects (mostly by subclassing). It's distributed as gem.
I can't show you code (it's not open-source), but I can point you to some helpful resources:
Rails 3 Plugins - Part 1 - The Big Picture
Rails 3 Plugins - Part 2 - Writing an Engine
Rails::Engine documentation
Plugin Authors: Toward a Better Future
Hope this helps!
Making copies is not always bad. That's why I ask about the reasons you don't want to copy the code.
If you create a 'library', you must ensure that every application will use it in the same manner. Or you have to prepare the 'library' for every possible difference between your applications which use it.
If you share the code, you are adding a dependency to your program. Any change in that shared code will affect more than one application.
Often it's much simpler to copy the code to another application, because then your may apply any modification without thinking about others.
Are you sure that managing users is so generic that you will not make any application-specific changes to it?
What about creating links to the files/directories that have the MVC? That is better than making copies.