Solution Break common behavior into Rails Engines Customize models/controllers/helpers in each project where needed by reopening classes Customize Rails views in each project as needed by overriding templates Link to Rails Engines in Gemfile via Git repo
What is a Rails Engine? Ruby Gem + MVC stack elements
What is a Rails Engine? Rails Engines let applications reuse: Models / Views / Controllers / Helpers Assets (JS, CSS, Images) Routes Rake tasks Generators
What is a Rails Engine? Rails Engines let applications reuse: Initializers RSpec / Cucumber Rack application with middleware stack Migrations and seed data Libraries
Engine Definition An engine structure is similar to a Rails app having app, config, lib, spec, features, etc… lib/engine_name.rb (engine loader) lib/engine_name/engine.rb (engine class) To reuse engine, generate gemspec (using “Jeweler or Gemcutter”)
Isolated Engines To avoid Ruby namespace clash with Models/Helpers/Controllers, you can define an isolated (namespaced) engine. Add “isolate_namespace MyEngine” to engine class body For more details, go to http://edgeapi.rubyonrails.org/classes/Rails/ Engine.html
Load OrderTypically Rails app files load first before Enginefiles.Strongly recommended to reverse so thatengine’s code is customizable in app
Load OrderReversing load order can happen in one of twoways: Patching “active_support/dependencies.rb” in Rails 3.1- (see next slide) Adjusting railties_order in Rails 3.2+
Engine Configuration Engines can be configured to customize rack middleware, load paths, generators, and Rails component paths. More details at: http ://edgeapi.rubyonrails.org/classes/Rails/ Engine.html
View and AssetCustomizationEngine View and Asset presentation can becustomized by redefining files in Rails App Customizations completely override files in Engine Examples of customizable View and Asset files: ERB/Haml JS CSS Images
Ruby Code CustomizationModel/Helper/Controller behavior can becustomized be redefining .rb files in Rails App Customizations get mixed in with files in Engine This allows: Adding new methods/behavior Replacing existing methods Extending existing methods (alias_method_chain)
Recommended EngineCode Management• Each Engine lives in own Repo independent of Rails App• Each Engine has its own Gem dependencies (Gemfile)• Engines preferably share the same Ruby version as Rails App
Typical DevelopmentProcess1.Make changes in engine, rake, and commit obtaining a new GIT ref2.Update Gemfile in app with new git ref, run “bundle install” (getting ride of symlink)3.Rake and commit changes in app.4.If more changes in engine are needed go back to step 1
Improved DevelopmentProcess1. Work in app and engine until done WITHOUT running “bundle install”2. Rake and commit changes in engine obtaining a new git ref3. Update Gemfile in app with git ref, run “bundle install”4. Rake and commit changes in app
Engines Reuse Engines Rails engines can reuse other Rails engines
Engines Reuse EnginesWhen multiple levels of depth are involved,commit repos and update Gemfile from thebottom up Example: Engine 2 => Engine 1 => App1. Commit in Engine 22. Update Gemfile in Engine 1 and commit3. Update Gemfile in App and commit
Rails Engine Patterns Goals: Keep engine code agnostic of app customizations Prevent bi-directional coupling to simplify reasoning about code Avoid app dependent conditionals to improve code maintainability
Pattern - Common DomainProblem: Multiple Rails Apps need to share a basicdomain model including default CRUD andpresentation behaviorExample: need to reuse address model and form entrybehavior
Pattern - Common Domain Solution: In engine, include basic domain models (base behavior, common associations) with their views, CRUD controllers, and routes. In each app, define domain model specialized behavior, extra associations, and custom views Make sure routes are declared with MyEngine::Engine.routes.draw (not Rails App name)
Pattern - Common DomainExample: address.rb, addresses_controller.rb,address route, and _address.html.erb
Pattern - Expose Helper Problem: need to customize presentation logic for a view in one app only, but keep the same logic in others Example: One App needs to hide address1 and county for non- government users. Other Apps wants to keep the fields displayed. You might start by overriding view, but then realize it is duplicating many elements just to hide a couple fields.
Pattern - Expose Helper Solution: In Engine, extract helper logic that needs customization into its own helper. In App, redefine that new helper with customizations.
Pattern - Expose Helper(trying to customize view in App)
Pattern - Expose Helper Remove custom view from App Use requires_extended_address? helper in Engine wherever the App used government_user? In Engine, define requires_extended_address? to return true In App, define requires_extended_address? to return government_user?
Pattern - Expose Helper(view + helper in Engine)
Pattern - Expose Partial Problem: need to have different customizations in one part of the view in multiple apps Example: Address form One App needs an extra neighborhood field Another App needs an extra region field
Pattern - Expose Partial Solution: In Engine, extract view part that needs customization as a partial. In App, redefine that partial with customizations.
Pattern - Expose Partial Example: Define _address_extra_fields partial with empty content in Engine Redefine _address_extra_fields in Apps needing extra fields
Pattern - Extension Point Problem: multiple Apps need to contribute data to a View in different places Example: multiple Apps need to add custom Rows in different spots of a List that comes from an Engine
Pattern - Extension Point Engine defines only 3 elements in a list (About Me, News and Noteworthy) 1 2 3
Pattern - Extension Point Solution: In Engine, add Helper logic that looks up partials in a specific ext directory, and based on file name (e.g. row_7.html.erb) insert into the right location in the View. In App, define these partials with the right file names and locations.
Pattern - ConfigurableFeatures Problem: different apps need different features from an engine in different combinations
Pattern - ConfigurableFeatures Solution: In Engine, add logic that looks up configuration options In App, configure Engine by overriding configuration options
Pattern - ConfigurableFeatures Example: Engine defines engine_config.yml enable_address_extensions: true enable_address_headers: true App overrides some options in engine_config.yml Engine uses config options to customize behavior using conditionals
Rails Engine Costs Overhead in establishing a new Rails Engine gem project Continuous switching between projects and engines to get work done Upgrade of ref numbers in Gemfile
Rails Engine Benefits Code reuse across all application layers Better maintainability due to: Independent project codebases Cleanly defined boundaries between projects and reusable components (engines) Project tests get smaller and run faster
Engines vs Services Engines are better when: Reusing small MVC features, especially domain independent (e.g. Search Map) Preferring to avoiding network and infrastructure overhead over establishing a service Wanting to quickly extract and reuse a feature
Engines vs Services Web Services are better when: Reusing larger MVC features that depend on domain data Need to consume feature in another programming language or outside the organization boundaries Need to scale up feature performance independently of the application (e.g. separate DB)
Engines vs Services To keep an easier to maintain Agile code base, start simple and then move incrementally towards a more complex architecture: Extract an MVC feature as an engine first Convert engine into a service when the need arises
Review Basics of Rails Engines Rails Engine Patterns Typical Development Process Summary of Benefits and Trade-Offs
More Info http://edgeapi.rubyonrails.org/classes/Rails/ Engine.html http://andymaleh.blogspot.com/2011/09/more-productiv http://andymaleh.blogspot.com/2011/09/more-producti engine.html http://stackoverflow.com/questions/2964050/rails-engin 2990539