Rails Applications' Life Cycle

Rails applications' life cycle

application_controller.rb

ApplicationController is a parent class to all controllers. Methods declared in it will be available to all controllers for this reason.

ApplicationController is a convenient place to filters that you want to apply to all controllers in your application, or methods that you wish to make available to all of them.

config/environments/*.rb

The files in config/environments/*.rb override settings in the default config/enviornment.rb file depending on what environment your server is running in (development/production). One example is that in development errors are printed to the screen and in production a generic error page is returned. This setting is in config/environments/development.rb

boot.rb

boot.rb is used as part of the rails initialization process. You usually don't need to, and likely shouldn't touch it.

environment.rb

environment.rb is the generic configuration file for your application.

routes.rb

routes.rb is used to define how your application handles requests to specific urls. For example, you may want to have all 404 requests go to a specific action instead of being handled by the default error handler:

map.connect '*path', :controller => 'home', :action => 'on_404'

It is also an important part of implementing a RESTful application.

Where to place initialization & configuration code

Both initialization code and custom configuration data should be placed in enviornment.rb (read the comments in this file). If you want certain code to run during initialization only in development or only in production, place it in config/environments/development.rb or config/environments/production.rb respectively.

Edit:

A good overview on when each of these files is run during initialization is available here:

http://toolmantim.com/articles/environments_and_the_rails_initialisation_process
https://github.com/toolmantim/toolmantim/blob/master/articles/environments_and_the_rails_initialisation_process.haml

Essentially the steps are:

1. The Rails Initializer is loaded (http://api.rubyonrails.org/classes/Rails/Initializer.html)

2. The rails Initializer sets up logging and then loads environment.rb

3. environment.rb loads boot.rb

4. boot.rb sets the RAILS_ROOT constant and adds rails libraries and application code to the LOAD_PATH

5. environment.rb executes Rails::Initializer.run.

6. The rails framework is loaded (ActiveRecord, ActionMailer, etc.)

7. Your environment's specific config file is loaded (config/environments/development.rb.)

8. after_initialize and to_prepare callbacks are executed if you have created any

9. Rails has finished loading and is ready to handle requests

Rails controller lifecycle

Yes, you can rely on a fresh controller instance per request.

RailsGuides:

When your application receives a request, the routing will determine
which controller and action to run, then Rails creates an instance of
that controller and runs the method with the same name as the action.

Ruby web app lifecycle

Ruby is "interpreted" just as PHP is, but this is also a form of compilation. What you might be confusing is that Ruby on Rails and Sinatra, as with most Ruby-based frameworks, are hosted as persistent processes. PHP tends to be interpreted for each request, though accelerators and web server modules do reduce the overhead of this process significantly.

I wouldn't suggest trying to make your own framework as this is a non-trivial task and even as an academic exercise would be of limited value. It's best to study something like Sinatra to see how that's implemented in order to learn more than to start from scratch.

Rails is quite well documented. If you have a specific question about a component of the framework that can't be answered by simply reading the source code, which is usually fairly well organized, you can post that here.

Rails application variable life cycle question

@users is not a global variable it is an instance variable. A new instance of your controller is created to handle each request so the @users for visitor A and visitor B are independent.

Rails Active Record model lifecycle

In practice, as long as you keep a reference to this instance. In most cases - until a request is finished.

class Model
  # most common memoization pattern
  def something
    @cached_result ||= do_query
  end
end

So, when your model will be instantiated (in controller/service/etc), it will be available as long as you can reference it. On the next request, @cached_result will be re-calculated.
If you want to cache something between requests, you can use CacheStore:

class Model
  def something
    Rails.cache.fetch("cache_key") do
      do_query
    end
  end
end

Do not treat cache as permanent store though. But this will allow you to cache something between requests and for some period of time.

btw, @cached_result will be calculated for each model instance. If you do something like Model.where(field: "value") that returns 2+ instances, each of them will do do_query on the first call.

Rails object lifecycle - cross-transaction objects creation and destroy

You can use class variables.

class Connection
  def initialize
    @@connection ||= # Start connectio
  end
end

---

Related Topics