I'm working on a "request's flow through the TG2 stack" diagram and
document.   Here's a quick preview of the stack.


The wsgi server calls the PasteCascade that either serves up static files
from the /public directory, or if there's a 404 from that calls into the
turbogears stack.


The TurboGears processes sets up authentication/authorization stuff, caches,
sessions, routes, etc and utimately calls your controller code.


This is all done by a set of nested WSGI calls, and here's the basic flow.


*WSGI Server*

  *PasteCascade*



*    Static File Server *

or

*    Your Application: *



    *Registry Manager* -- Setup application local object proxies, so that
multiple apps can live in process, but tg.request always points to the right
request.

      *Error Middleware*

        *Database Session Manager*  -- set a request local DBSession

          *Transaction Manager*  -- register a Transaction

            *Authentication*  -- add REMOTE_USER to request for user

              *Authorization*  -- add user permissions and groups to request

                *ToscaWidgets*

                  *Cache*  -- provide hooks to get at the cache

                    *Session*  -- add user session info to the request

                      *Routes*  -- lookup URL requested in routes table and
add it to the request

                        *Custom Middleware* -- whatever you want it to do

                          *TurboGearsApp*  -- find the controller that
should be called

                            *Your Controller Code*  -- returns a string, or
a dictionary

                          *TurboGearsApp * -- if dict returns find a
template engine and render

        *Custom Middleware*

                       *Routes*

                    *Session*  -- if you saved stuff to the session, persist
it.

                  *Cache* -- if information was cached in the request
persist it

                *ToscaWidgets* -- if widgets that require JS or CSS were
used inject it

             * Authorization*

            *Authentication *

          *Transaction Manager*  -- if no errors, commit DB and other
pending transactions

        *Database Session Manager*  -- remove the DBSession

      *Error Middleware* -- If a python error occured handle it.

My ultimate plan is to take this document and explode it out to discussion
of what happens at each WSGI middleware layer, and how to overide the setup
of each of these things, so that people have a clear picture of what's going
on.

Hopefully this snipit helps.   Also, if you have good ideas on how we can
best visually represent all of this, I'd be very interested.

-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to