In the previous installment of "Behind the Scenes", we saw how the control flows from Form to File Storage. Today, we are going to see how the application reacts from request to response.
In this post, we are going to assume that we are using django's inbuilt
runserver. The flow doesn't change much for other WSGI servers
When you invoke the
runserver management command, the command line
options are validated and an instance of
is created and passed the
which is used to create the request object
After the request object is created and the request started signal is
fired, the response is fetched through the
get_response method of the request handler, first the urlconf
location (by default the
urls.py) is setup based on the
settings.ROOT_URLCONF. Then a
compiles the regular expressions in the urlconf file. Next, the request
middlewares are called in the order specified in the
settings.MIDDLEWARE_CLASSES followed by the view middlewares after
matching the view (
callback) function against the compiled regular
expressions from the urlconf. Then the view (
callback) is invoked and
verified that it does not return
None before calling the response
You can see the pictorial representation of the flow below:
Thank you for reading the Agiliq blog. This article was written by thejaswi on Jan 2, 2012 in response .
You can subscribe ⚛ to our blog.
We love building amazing apps for web and mobile for our clients. If you are looking for development help, contact us today ✉.
Would you like to download 10+ free Django and Python books? Get them here