Nitro request handling overview

I figured this would come in handy for folks trying to get what’s going
on in Nitro, including myself.

A request comes in at a certain adapter (mongrel, fcgi, …).
(raw/adapter/<…>.rb)

The adapter creates a new Context object and fills it with whatever is
in the request : parameters, cookies, and the QUERY_STRING

It calls handle_context (AdapterHandlerMixin raw/adapter.rb)

This calls dispath_context (Dispatcher raw/dispatcher.rb)

The Dispatcher consults the Router, determines the controller class, the
name of the action ‘super method’, any parameters and the format.

The super method is named #{action}super, this method calls the
method #{action} and the action view method, which is basically the
compiled form of the template : #{action}
#{format}___view.

This all is given back to the adapter. It sets
Thread[:CURRENT_CONTROLLER] to the controller class, and creates a new
Controller instance. It sends ‘render_action’ to the controller with the
action ‘super method’ name and any parameters.

render_action is defined in the Render module which is mixed into
controllers. It basically wraps the action rendering in some error
handling. (raw/controller/render)

At this point the controller will receive the #{action}___super method.
If it doesn’t exist yet it will trigger method_missing in Publishable,
which is mixed into controllers. (raw/controller/publishable).

Publishable will call on the Compiler to compile the necessary
super/view methods and resend the message.

The super method is pretty much boiler plate. It calls the actual action
method (the one you write yourself) and the #{action}___#{format}___view
method. It also calls a ‘before’ and an ‘after’ hook in the current
Format, and possibly caches the output at the end.

The view method is generated by locating the template (if any) and
running it through the format’s filter pipeline :
format.filter_template(template_text). The result is ruby code which is
plugged into the controller as the #{action}___#{format}___view method.

(ab)


Arne B.
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
[email protected]

The Dispatcher consults the Router, determines the controller class, the
name of the action ‘super method’, any parameters and the format.

I need a better name to replace ‘super’. Suggestions are welcome!

-g.

origin - source - provider

George M. wrote:

The Dispatcher consults the Router, determines the controller
class, the
name of the action 'super method', any parameters and the format.

I need a better name to replace ‘super’. Suggestions are welcome!

-g.
“awesome” :wink:

I think super is probably as good as any, but freely associating I get:

root, base, default, first-available

… and perhaps “over” – the “overmethod”

Robert M. schreef:

George M. wrote:

I need a better name to replace ‘super’. Suggestions are welcome!

root, base, default, first-available

… and perhaps “over” – the “overmethod”

I was just thinking of “master”, the action its master method. The word
isn’t in use yet in OOP, Ruby or Nitro (AFAIK), and it fits well with
what the method does. It’s basically the guy in charge who delegates to
others to do the real work.

Thinking of it, boss or PHB might also be good :wink:

(ab)


Arne B.
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
[email protected]

is this thread still unravelling?

… if it is superiior call it the the “boss”, “guru”, “king”

there must be one free ‘superior’-inferior word some place :smiley:

smiling

well, if this method is actually delagating then the one giving the
orders
is the “superior”, thus the shortened version to “super”. my only other
thought would be parent.

-Chris