The Django Structure - from urlconf to view, to model...

This is a continuation of the Capturing Learning Django project.

Just some more explanation for question nr. 4... I'm coming back to these questions since I want to document the process of learning. So even though I'm going back to some of the questions, capturing the progress is also important... However, I'll only post the new stuff from now on.

4. Django uses some kind of structure to tell the application where to look for links. How does this hierarchy work? What is actually put into the different files?


Got some more answers to this issue. I'll now try to explain what happens in my app. A more illustrative picture is attached below.

I have a blog, under /djangoblog/blog. So I input http://127.0.0.1:8000/blog in my browser. Then:

1. A URL call matches a URL in the urls.py file which is in /djangoblog/urls.py
   
2. In the urls.py file, I have this line: (r'^blog/', include('djangoblog.blog.urls')), which redirects to /djangoblog/blog.urls.py
3. In there, one of the lines is
   
• (r'^$','archive_index', dict(info_dict, template_name='blog/list.html')),
• This line fits the url pattern ...8000/blog ... because of ^$ which matches an empty string after the /blog.
• This line redirects to blog/list.html
4. Then my template blog/list.html takes over. It resides in djangoblog/templates/blog/list.html. I think Django can find it automatically from there since I've configured the templates in the settings.py-file.
   
• This file starts with {% extends 'base.html' %}, and thus first loads my base.html template, which is found in djangoblog/templates/base.html
• This list.html file then says to the browser what is shown. It's an html-file! The special thing is is that it's also full of Django/python.
5. The Django/Python calls, such as:

   {{ object.pub_date|date:"D d M Y" }}

   , then call up the methods from the djangoblog/blog/models.py-file.
6. That's it. The model is the actual Python code that says what the page shows.
   

It seems the explanation above is missing views. So with views, the urlconf actually calls a function in the views.py file:

1. In my urlconf, I have for example:

(r'^polls/(?P<poll_id\d+)/$, 'learness2.polls.views.detail'),

That means that for all url's that follow that pattern, the detail function in the views.py file will be revoked. If for example the url that is called is 'polls/2/', the function is called like this: detail (request=, poll_id='2')

This is the picture that I found about the issue in http://www.webmonkey.com/tutorial/Use_URL_Patterns_and_Views_in_Django, by designer and Coder Jeff Croft:

However, according to my experience, you could also draw it like this, to visualize how the URL request moves in the Django app: