What is the sequence of events that happen when you get a page

Question

I am trying to figure out the sequence of events that occur between when rails receives a get / post command and the page is being served. I was just trying to display the sequence myself, and I realized that I didn’t understand which scripts even started first, so I would like to clarify this in my head.

thank you very much

John

Answer 1

The request is sent to the route mapping, which parses the URL, analyzes the configuration of /routes.rb and, if the URL matches the route, it looks for the controller file whose name matches the controller part of the URL (for example, http: // localhost / categories will look for DomainController)

Then one of two things happens:

• If you use the Rails secure route, the route marker uses heuristics to determine which of the 7 actions to call: GET on the last multiple part maps to the index; GET is mapped to the identification part after the plural is displayed for display (for example, category / 1 or category / something or category / 1-something); The POST for the last multiple part is displayed for creation; PUT for the identification part after the plural is displayed for updating; DELETE to the same URL is displayed for destruction; new and edit are displayed in GET for categories / new and categories / edit.
  • If you have a custom action, you must have a method in the controller object with the same name.

The selected action is executed, and then Rails either displays the template / file / action specified in the render call in the action, or searches for a file with the same name as the action, and ends with .html.erb (by default) in the app / views directory /.

Simple

Answer 2

Rails does quite a few things, a good way to get a decent overview is to read the document "Action Controller Overview" in the rails guides: http://guides.rubyonrails.org/action_controller_overview.html

The basic structure:

• rack middleware
• routing
• filters
• controller code
• rendering
• filters

But rails also do many things on their own. It automatically determines which response you want based on your accept headers, and / or manually specify what type of response you want, with a file ending with / blog / 1.xml. Rails also magically creates a well-formatted hash parameter by parsing parameters like user [name] = foo to {: user => {: name => "foo"}}. Rails also has built-in exception handling and some nice things to prevent cross-site request forgery and more, so check out the controller overview to find out.