- 5.1 Introduction
- 5.2 The Purpose of Views and URL Configurations
- 5.3 Step-by-Step Examination of Django's Use of Views and URL Configurations
- 5.4 Building Tag Detail Webpage
- 5.5 Generating 404 Errors for Invalid Queries
- 5.6 Shortening the Development Process with Django View Shortcuts
- 5.7 URL Configuration Internals: Adhering to App Encapsulation
- 5.8 Implementing the Views and URL Configurations to the Rest of the Site
- 5.9 Class-Based Views
- 5.10 Redirecting the Homepage
- 5.11 Putting It All Together
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.11 Putting It All Together
In Chapter 5, we examined Django views and URL configurations, which make up the Controller of Django’s Model-View-Controller architecture. The Controller acts as the glue between the Model and View. In Django, the Controller receives, selects, processes, and then returns data.
A Django view is any callable that receives an HttpRequest object (with any other additional arguments) and returns an HttpResponse object. Originally, Django recommended using functions as views, but modern Django also provides a canonical way of creating classes to create object views.
To make writing views easier, Django supplies shortcut functions. We saw three shortcuts, starting with get_object_or_404(), which gets an object according to a model class and query while accounting for the possibility that the query will not match a row in the database, in which case it raises a Http404 exception. We then saw the render_to_response() and render(). Both load a template, render the template with a context, and instantiate an HttpReponse object with the result. However, the render() shortcut uses a RequestContext instead of a Context object, allowing Django to run context processors on the RequestContext, effectively adding values for the template to use during the rendering phase. This added functionality is key to certain views and functionality, and thus render() has become the favored shortcut, even if it is marginally slower than render_to_response().
To direct Django to the views the developer writes, Django provides the URL configuration mechanism. The URL configuration is contained in a file pointed to by the project settings. Inside the file, Django expects (by convention) to find the urlpatterns variable, which is a list of RegexURLPattern objects. Each RegexURLPattern object is created by a call to url(), which expects at the very least (1) a regular expression pattern and (2) a reference to a Python callable. A call to url() may also optionally be called with (3) a dictionary of values that are passed as keywords to the view that the resulting RegexURLPattern points to. Finally, url() can receive (4) the keyword argument name, which sets the name of the RegexURLPattern, a feature that will become crucial in the next chapter.
URL configurations may be connected using include(). A URL pattern may include another URL configuration, allowing for the creation of a URL scheme that is a tree, where the root URL configuration specified in the Django project settings is the root of the tree. This feature furthermore allows for app encapsulation, allowing each app to define its own URL patterns, extending those of the project, which include() achieves by truncating the regular expression match from the URL path requested of Django.
In short, the URL configuration directs Django to the view thanks to URL pattens, which contains the logic required to make a webpage.