How Django handles a request
When a user requests a page from the Django site, the following is the algorithm that the Django system decides which Python code to follow:
1:django determines the root urlconf module to use. Typically, this value is the root_urlconf setting, but if the incoming HttpRequest object has a URLCONF property
(through the Middleware request processing setting), this value is used to replace the root_urlconf setting.
2:django loads the Python module and looks for the available urlpatterns. It is a python list of django.conf.urls.url () instances.
3:django matches each URL pattern in turn, stopping at the first mode that matches the requested URL.
4: Once one of the regular expression matches, Django will import and invoke the given view, which is a simple Python function (or a class-based view). The view will have the following parameters:
- A HttpRequest instance.
- If a matching regular expression returns a group that is not named, the contents of the regular expression match are provided to the view as positional parameters.
- A keyword parameter consists of a named group that matches a regular expression, but can be overridden by an optional parameter kwargs the Django.conf.urls.url ().
5: If there is no match to the regular expression, or if an exception is thrown in the procedure, Django will invoke an appropriate error-handling view.
such as handler404,handler500,handler403. We can also customize the corresponding error view to override the provided default error handling view.
Named and unnamed groups
For example:
URL (r ' ^articles/([0-9]{4})/$ ', views.year_archive)--No named regular expression
URL (r ' ^ Articles/(? P<YEAR>[0-9]{4})/$ ', views.year_archive)---named regular expression
in a Python regular expression, the syntax for naming a regular expression group is (?). P<name>pattern), where name is the name of the group, pattern is the mode to match. The
actually works the same, with only one subtle difference: The captured value is passed to the view function as a keyword parameter rather than as a positional parameter.
This means that your urlconf will be clearer and less prone to errors in parameter order problems.
For example: The/ARTICLES/2005/request will call Views.month_archive (Request, year= ' 2005 ') function instead of views.month_archive (Request, ' 2005 ').
Contains other Urlconfs.
1:include submodule urlconf, when matched, Django removes the matching part of the URL and sends the remaining string to the included urlconf for further processing
For example: URL (r ' ^polls/', include (' Polls.urls ', namespace= "polls"))
2: Use a list of URL () instances to remove duplicate portions of the URL configuration, for example:
URL (r ' ^polls/', include ([
URL (r ' ^history/$ ', views.history),
URL (r ' ^permissions/$ ', views.permissions),
URL (r ' ^edit/$ ', Views.edit),
])),
The personal feeling here is that it looks like the code is clear.
Reverse parsing of URLs
Reverse parsing is the URL that is associated with the Django view's identity and the value of the parameter that will be passed to it.
This avoids hard-coding these URLs so that if the URL changes at a later stage, as long as the view's identity does not change, the content of the modified urlconf will not have any other effect.
Where URLs are required, Django provides different tools for URL inversion for different levels:
- In the template: Use the URL template tag.
- In Python code: Use the Django.core.urlresolvers.reverse () function.
- In higher-level code related to handling Django model instances: Use the Get_absolute_url () method.
For example: Urlpatterns is so mapped: URL (r ' ^articles/([0-9]{4})/$ ', views.year_archive, name= ' news-year-archive ')
In HTML you can reverse this: <li><a href= "{% url ' news-year-archive ' yearvar%} ' >{{Yearvar}}
This is handled in Python code: Return httpresponseredirect (Reverse (' news-year-archive ', args= (year,)))
Naming the URL pattern
The URL namespace allows you to reverse the unique named URL pattern, even if different apps use the same URL name. It's a good practice for third-party apps to always use URLs with namespaces (as we did in the tutorial).
Similarly, it allows you to reverse the URL in case one app has multiple instance deployments. In other words, because multiple instances of an application share the same named URL, the namespace provides a way to differentiate between these named URLs
Apply namespace: It represents the name of the app being deployed. Each instance of an app has the same app namespace
Instance namespace: It represents a specific instance of the app. The namespace of the instance should be unique across all of your projects. However, the namespace of an instance can be the same as the namespace that is applied. It is used to represent the default instance of an app
Django URL Processing