A story about gemified engines


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A story about gemified engines

  1. 1. A story about Gemified Engines A 45-minute introduction to Engines
  2. 2. FYI A few essential concepts
  3. 3. A few essential concepts ○ A Ruby Gem is a container for reusable Ruby code. ○ A Rails Gem is a Ruby Gem that depends on Rails. ○ To "gemify" something, is to create a Gem out of a piece of isolated Ruby code.
  4. 4. Enlighten me! Quick intro to Railties & Engines
  5. 5. Quick intro to Railties & Engines ○ Since version 3, Rails major components are built on top of a core class called Railtie. ○ Thus, all (new and old) components based on this class were dubbed "Railties". ○ This class "provides several hooks to extend Rails and/or modify the initialization process".1 [1] Taken from http://api.rubyonrails.org/classes/Rails/Railtie.html
  6. 6. Quick intro to Railties & Engines ○ Railties are responsible for their own initialization/configuration process, making Rails core's independent from them -sort of a "plug & play" standard. ○ Obviously, we can create our own Railties and extend our application, much like any Rails Gem we know does.
  7. 7. Quick intro to Railties & Engines ○ Read more about Railties: ○ Rails::Railtie - Ruby On Rails API Online http://api.rubyonrails.org/classes/Rails/Railtie.html
  8. 8. Quick intro to Railties & Engines ○ An Engine is a Railtie. ○ Hence, an Engine can do all that that a Railtie can do, and more. ○ Internally, Engine inherits from Railtie, as you imagined.
  9. 9. Quick intro to Railties & Engines ○ Engines are self-contained Rails applications. ○ Any Rails ~> 3 application is an Engine. ○ Engines you plug into your application integrate seamlessly adding their controllers, models, views, routes, etc. as if they were part of the whole thing. ○ They can also be isolated (namespaced) to avoid conflicts with the main application.
  10. 10. And...? Deeper into Engines
  11. 11. Deeper into Engines ○ Engines are the way to extend any Rails 3 application by default. ○ They can be thought of as Plugins (sort of). ○ In fact, the Rails default generator for Engines is: rails plugin new <name> -- <type>. ○ Type can be full or mountable.
  12. 12. Deeper into Engines ○ Mountable Engines ○ Namespace isolated by default. ○ Meaning: no name-clash conflicts with the "host" application. ○ All your controllers, models and routes get isolated inside the namespace. ○ The routes namespace name is defined when mounting the Engine routes in the routes.rb file. ○ This is a conservative approach.
  13. 13. Deeper into Engines ○ Full Engines ○ No namespace isolation; everything you put in it will become available to the host application "as is". ○ Useful if you're adding functionality to existing resources. ○ Because routes are also not isolated, you should take special care when defining them. ○ Could blow up everything if you use common names for classes. Watch out!
  14. 14. Deeper into Engines ○ Read more about Engines: ○ Rails::Engine - Ruby On Rails API Online http://api.rubyonrails.org/classes/Rails/Engine.html ○ Try yourself building an Engine - Ruby on Rails Guides http://guides.rubyonrails.org/engines.html
  15. 15. Last but not least "Gemify" your Engine
  16. 16. Gemify your Engine ○ Check you have correctly defined your . gemspec file. ○ Run gem build <name>.gemspec. ○ Then install it with gem install . /<name>.gem. ○ You can add it to Bundler's Gemfile passing a :path key in your options hash. ○ And, well, that's pretty much everything I wanted to cover here.
  17. 17. Thank you for your time! 2013