views:

187

answers:

6

Where can i get the technical manuals/details of how django internals work, i.e. i would like to know when a request comes in from a client;

  • which django function receives it?
  • what middleware get called?
  • how is the request object created? and what class/function creates it?
  • What function maps the request to the necessary view?
  • How does your code/view get called

? etc...

Paul.G

+8  A: 

"Use the source, Luke." The beauty of open source software is that you can view (and modify) the code yourself.

Ned Deily
+1. usually this is a non-useful answer; but Django source is __very__ readable.
Javier
Agreed. Source code on large projects is typically difficult to understand unless you actually contribute to it on a regular basis. But Django is highly modular and easy to focus on one particular element to study.
Soviut
Yes, it is. And certainly one should start with excellent on-line documentation as Soviut points out. But, for the level of detail implied by the question, there's no substitute for looking at the code.
Ned Deily
+1  A: 

I doubt there are technical manuals on the subject. It might take a bit of digging, but the API documentation and the source code are your best bets for reliable, up-to-date information.

Sam DeFabbia-Kane
A: 

The documentation often goes into detail when it has to in order to explain why things work the way they do. One of Django's design goals is to not rely on "magic" as much as possible. However, whenever Django does assume something (template locations within apps, for example) its clearly explained why in the documentation and it always occurs predictably.

Most of your questions would be answered by implementing a single page.

  1. A request is made from the client for a particular url.
  2. The url resolves what view to call based on the url pattern match.
  3. The request is passed through the middleware.
  4. The view is called and explicitly passed the request object.
  5. The view explicitly calls the template you specify and passes it the context (variables) you specify.
  6. Template context processors, if there are any, then add their own variables to the context.
  7. The context is passed to the template and it is rendered.
  8. The rendered template is returned to the client.

Django Documentation

Django Book

Soviut
+7  A: 

Besides reading the source, here's a few articles I've tagged and bookmarked from a little while ago:

I've found James Bennet's blog to be a a great source for information about django workings. His book, Practical Django Projects, is also a must read -- though it isn't focused on internals, you'll still learn about how django works.

ars
Oh yeah, James Bennet's blog is great. I've bookmarked a lot of pages from there. He's a really good writer, very clear.
hughdbrown
+6  A: 

Easiest way to understand the internals of django, is by reading a book specifically written for that.

Read Pro Django. It provides you a good in depth understanding of the meta programming first and demonstrates how it is used in django models, to create them dynamically.

It deals similarly with many other python concepts and how django uses it.

Lakshman Prasad
Yes, this is a must read !
Pierre-Jean Coudert
I agree. This book shows you some of the advanced Python techniques that Django employs to provide the useful framework that it is.
Brian Neal
+3  A: 

Simply reading the source might be a bit overwhelming, especially since the upper-most part is a bit confusing (how the webserver hands off the request to Django code). I find a good way to get started reading the code is to set a debugger breakpoint in your view function:

def time(request):
    import pdb; pdb.set_trace() 
    return HttpResponse(blah blah)

then hit your URL. When the debugger breaks at your breakpoint, examine the stack:

(Pdb) where
  c:\abcxyzproject\django\core\management\commands\runserver.py(60)inner_run()
-> run(addr, int(port), handler)
  c:\abcxyzproject\django\core\servers\basehttp.py(698)run()
-> httpd.serve_forever()
  c:\python25\lib\socketserver.py(201)serve_forever()
-> self.handle_request()
  c:\python25\lib\socketserver.py(222)handle_request()
-> self.process_request(request, client_address)
  c:\python25\lib\socketserver.py(241)process_request()
-> self.finish_request(request, client_address)
  c:\python25\lib\socketserver.py(254)finish_request()
-> self.RequestHandlerClass(request, client_address, self)
  c:\abcxyzproject\django\core\servers\basehttp.py(560)__init__()
-> BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  c:\python25\lib\socketserver.py(522)__init__()
-> self.handle()
  c:\abcxyzproject\django\core\servers\basehttp.py(605)handle()
-> handler.run(self.server.get_app())
  c:\abcxyzproject\django\core\servers\basehttp.py(279)run()
-> self.result = application(self.environ, self.start_response)
  c:\abcxyzproject\django\core\servers\basehttp.py(651)__call__()
-> return self.application(environ, start_response)
  c:\abcxyzproject\django\core\handlers\wsgi.py(241)__call__()
-> response = self.get_response(request)
  c:\abcxyzproject\django\core\handlers\base.py(92)get_response()
-> response = callback(request, *callback_args, **callback_kwargs)
> c:\abcxyzproject\abcxyz\helpers\views.py(118)time()
-> return HttpResponse(
(Pdb)

Now you can see a summary of the path from the deepest part of the web server to your view function. Use the "up" command to move up the stack, and the "list" and "print" command to examine the code and variables at those stack frames.

Ned Batchelder