Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

A story about gemified engines

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.

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.
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.

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.
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.

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.
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.
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!