railties
DESCRIPTION
Recently I have been porting an app into Rails 3 and probably you have also been poking this new Rails 3 with ruby 1.9.2. Therefore I would like to discuss a bit more about Rails 3 itself. Particularly, things under railties lib directory covering classes such as Railtie, Engine, Application and will go through initialization with initializers. Along the way I'll show some examples how you can use this knowledge in your own gem or plugin. Nothing too fancy but should be useful for developing your next RailsTRANSCRIPT
If you like go a bit more in depth, please read Piotr Sarnacki article:
http://piotrsarnacki.com/2010/06/18/rails-internals-railties/
Anyhow, here is my slides for meetup.
puts 'Hello!'
Early days...Not so early days...
Recent days......or just short shameless self presentation.
Presentation is about:
Railtie and it's responsibiltyEngine and Application classes
Initialization
...and one more thing ;-)
Credits and thanks goes to:
Rails 3 source codeRails 3 edge guides
José Valim and other Devise developersPiotr Sarnacki and his summer work/blog
http://piotrsarnacki.comOwn experience during summer in Barcelona
What's the responsibility of Railites:
Glues all togetherHandles all bootstrapping process
Provides rails command line interfaceProvides rails generators core
What about class Railtie?railties/lib/rails/railtie.rb
Class Railtie is the core of the Rails Framework and provides several hooks to extend Rails and/or
modify the initialization process.
Creating your own Railtie
# APP/Gemfilegem 'my_gem'
# GEM/lib/my_gem.rbrequrie 'my_gem/railtie' if defined?(Rails)
# GEM/lib/my_gem/railtie.rbmodule MyGem class Railtie < Rails::Railtie endend
What about Engine class?
First, don't get confused with Engine plugin.Rails 3 Engine class is quite different thing.
Engine is just subclass of Railtie
# railties/lib/rails/engine.rbmodule Rails class Engine < Railtie endend
Available paths in an Engine
class MyEngine < Rails::Engine paths.app = "app" paths.app.controllers = "app/controllers" paths.app.helpers = "app/helpers" paths.app.models = "app/models" paths.app.views = "app/views" paths.lib = "lib" paths.lib.tasks = "lib/tasks" paths.config = "config" paths.config.initializers = "config/initializers" paths.config.locales = "config/locales" paths.config.routes = "config/routes.rb" end
Use middleware in initialization
# lib/my_gem/railtie.rb class MyRailtie < Rails::Railtie initializer "my_railtie.initialization" do |app| app.middleware.use MyRailtie::Middleware endend
One more thing :-)
What to expect from Rails 3.1?
What, not excited?
Anyhow, heavy lifting done by Piotr Sarnacki in his time with Ruby Summer of Code.
At the moment treat his work as any other Rails edge code, I'm sure he welcomes any feedback.
What to expect from Rails 3.1?
* Engine is now rack application * Added middleware stack to Engine* Engine can now load plugins* Engine can load its own environment file* Added helpers to call engines' route helpers from application and vice versa
What to expect from Rails 3.1?
* Task for copying plugins' and engines' migrations to application's db/migrate directory* Changed ActionDispatch::Static to allow handling multiple directories* Added namespace() method to Engine, which sets Engine as isolated* Include all helpers from plugins and shared engines in application
Good news
It looks Rails 3.1 will probably be very friendly for multible/mountable apps.
Bad news
Please, don't go crazy with mountable apps,even with Rails 3.1
In my reality it's a pipe dream to create and use very high level dependencies.
However there is nish
Take a look how Devise works and what kind workflow/attitude José Valim has.
He has given a nice introduction about this topic in Barcelona, probably there will be something on online as well.
Thank you for you time!
Any questions or comments?
Just in case, here is my profiles:Github.com/priitTwitter.com/priithttp://priit.mx.ee