This is a Work In Progress by a Ruby Nuby. If you have better info, please lend a hand. In particular, see “Open Questions”, below…
Web Server Startup
WHen the request comes in, it gets handed off to the Rails “dispatcher”. Dispatcher is a small script used to let Rails communicate with different servers – you have a separate dispatchers for mod_ruby, FastCGI and CGI.
The dispatcher file loads an appropriate dispatcher class from Rails, which, in turn, loads your application, by loading “@app/co”http://wiki.rubyonrails.org/rails/pages/UnderstandingDefaultFileUsage/versions/new/129nfig/environment.rb">http://wiki.rubyonrails.org/rails/pages/UnderstandingDefaultFileUsage/versions/new/129nfig/environment.rb". This file, in turn, loads main Rails classes - ActionPack, ActionMailer, and ActiveRecord. "environment.rb@", will also require “app/config/environments/{development, production, test}.rb” depending of the environment you are using now, and “app/config/routes.rb” which configure the way URLs are rewritten in your application. Upon ActiveRecord initialization, AR reads “app/config/database.yml” and establishes the connection to the database.
What the Web Server Sees…
All HTTP (Hypertext Transport Protocol) URLs (Uniform Resource Locators) begin with “http://”. So, the web server sees a URL of the form
http://<host>[:<port>]/<path>
The “<host>” field, in general, specifies the machine which will handle the request. This will typically be a domain name (e.g., “rubyonrails.com”) or an IP address (e.g., “127.0.0.1”). An intervening colon and a port number (e.g., “:3000”) may follow; if not, port 80 is assumed.
All of this has gotten us to a particular HTTP server on a particular host.
Everything after this point is parsed by the server and (perhaps) a subsidiary application such as Rails. Some number of nodes may precede the Rails portion of the URL. For the remainder of this note, everything before the Rails portion of the URL will be expressed as “http...”.
What the Rails App Sees…
The typical URLs that a Rails app sees are of the form
http.../<controller>/<action>[/<id>]
For example, the URL “http.../stone/polish/42” would be handled as follows:
An instance of “StoneController” will be created.
The defining code for this controller resides in “app/controllers/stone_controller.rb”. Typically, the controller will operate with objects will be subclassed from “ActiveRecord”. If so, table “stones” will be used, by default, and the relevant file from – “app/models/stone.rb” will be loaded automatically. Because an “id” (42) has been specified, that record will be retrieved.
Note: Code in “app/controllers/application.rb” is loaded for ALL controllers. Other controllers are loaded only when a request needs them – so a Rails application is loading controllers gradually, not at once upon initialization.
If the “polish” method is defined for “StoneController”, it will be run.
If the controller needs to access (other) model data, it will call on methods defined (for the appropriate objects) in “app/models/*”.
Appropriate view helpers and templates will be “expanded”.
Helper code in “app/helpers/application_helper.rb” is loaded for all templates. If “app/helpers/stone_helper.rb” contains an appropriate module (e.g., StoneHelper), the module’s code will be loaded.
If a template for the requested view (e.g., “app/views/stone/polish.r{ht,x}ml”) is present, it will be “expanded”. That is, included Ruby code will be executed, etc. In general, results of this will be included in the output “document”.
The document will be handed off to the web server.
For a simple web page or XML file, this is the end of the story. However, if the page included a form, more magic occurs. Specifically, the parameters from the POSTed response are instantiated into the params (controller) and @params (view) variable, allowing code in the controller and view to access the form that was POSTed, including doing things like saving it to the database.
http.../<file>
This form of URL causes files in “app/public” to be displayed, usually bypassing the Rails application altogether (the files are served by your web-server).
Note: Dynamic reloading
Rails application is loaded into the server only once (when the server is started). After that it will automatically reload your changed source files (only in “development environment”) by simply using a Ruby load statement, which will replace the old classes with their new versions. Please note that you need to restart the server so thate changes in “app/config/environment.rb” can take effect. When you are running your application in production environment the code only gets reloaded whenl you restart your web server manually.