from django.http import HttpResponse\nimport datetime\n\u00a0def current_datetime(request):\n\u00a0\u00a0\u00a0 now = datetime.datetime.now()\n\u00a0\u00a0\u00a0 html = \"<html><body>It is now %s.<\/body><\/html>\" % now\n\u00a0\u00a0\u00a0 return HttpResponse(html)<\/pre>\nLet\u2019s change this view to use Django\u2019s template system. At first, you might think to do something like this:<\/p>\n
from django.template import Template, Context\nfrom django.http import Http\nResponse\nimport datetime\ndef current_datetime(request):\n\u00a0\u00a0\u00a0 now = datetime.datetime.now()\n\u00a0\u00a0\u00a0 t = Template(\"<html><body>It is now {{ current_date\n }}.<\/body><\/html>\")\n\u00a0\u00a0\u00a0 html = t.render(Context({'current_date': now}))\n\u00a0\u00a0\u00a0 return HttpResponse(html)\n\n<\/pre>\nSure, that uses the template system, but it doesn\u2019t solve the problems we pointed out in the introduction of this chapter. Namely, the template is still embedded in the Python code. Let\u2019s fix that by putting the template in a separate file, which this view will load.<\/p>\n
You might first consider saving your template somewhere on your filesystem and using Python\u2019s built-in file-opening functionality to read the contents of the template. Here\u2019s what that might look like, assuming the template was saved as the file \/home\/djangouser\/templates\/mytemplate.html:<\/p>\n
from django.template import Template, \nContextfrom django.http import HttpResponse\nimport datetime\ndef current_datetime(request):\n\u00a0 \u00a0\u00a0now = datetime.datetime.now()\n\u00a0\u00a0\u00a0 # Simple way of using templates from the filesystem.\n\u00a0\u00a0\u00a0 # This doesn't account for missing files!\n\u00a0\u00a0\u00a0 fp = open('\/home\/djangouser\/templates\/mytemplate.html')\n\u00a0\u00a0\u00a0 t = Template(fp.read())\n\u00a0\u00a0\u00a0 fp.close()\n\u00a0\u00a0\u00a0 html = t.render(Context({'current_date': now}))\n\u00a0\u00a0\u00a0 return HttpResponse(html)<\/pre>\nThis approach, however, is inelegant for these reasons:<\/p>\n
- \n
- It doesn\u2019t handle the case of a missing file. If the file html doesn\u2019t exist or isn\u2019t readable, the open() call will raise an IOError exception.<\/li>\n
- It hard-codes your template location. If you were to use this technique for every view function, you\u2019d be duplicating the template locations. Not to mention it involves a lot of typing!<\/li>\n
- It includes a lot of boring boilerplate code. You\u2019ve got better things to do than to write calls to open(), read(), and fp.close() each time you load a template.<\/li>\n<\/ul>\n
To solve these issues, we\u2019ll use template loading<\/em> and template directories<\/em>.<\/em><\/p>\n
Template Loading<\/strong><\/p>\n
Django provides a convenient and powerful API for loading templates from the filesystem, with the goal of removing redundancy both in your template-loading calls and in your templates themselves. In order to use this template-loading API, first you\u2019ll need to tell the framework where you store your templates. The place to do this is in your settings file \u2013 the settings.py file that I mentioned last chapter, when I introduced the ROOT_URLCONF setting. If you\u2019re following along, open your settings.py and find the TEMPLATES setting. It\u2019s a list of configurations, one for each engine:<\/p>\n
TEMPLATES = [\n{\n'BACKEND': 'django.template.backends.django.DjangoTemplates',\n'DIRS': [],\n'APP_DIRS': True,\n'OPTIONS': {\n# ... some options here ...\n},\n},\n]<\/pre>\nBACKEND is a dotted Python path to a template engine class implementing Django\u2019s template backend API. The built-in backends are django.template.backends.django.DjangoTemplates and django.template.backends.jinja2.Jinja2.<\/p>\n
Since most engines load templates from files, the top-level configuration for each engine contains three common settings:<\/p>\n
- \n
- DIRS defines a list of directories where the engine should look for template source files, in search order.<\/li>\n
- APP_DIRS tells whether the engine should look for templates inside installed applications. By convention, when APPS_DIRS is set to True, DjangoTemplates looks for a \\templates subdirectory in each of the INSTALLED_APPS. This allows the template engine to find application templates even if DIRS is empty.<\/li>\n
- OPTIONS contains backend-specific settings.<\/li>\n<\/ul>\n
Template Directories<\/h3>\n
DIRS, by default, is an empty list. To tell Django\u2019s template-loading mechanism where to look for templates, pick a directory where you\u2019d like to store your templates and add it to DIRS, like so:<\/p>\n
'DIRS': [\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 '\/home\/html\/templates\/site',\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 '\/home\/html\/templates\/default',\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ],<\/pre>\n
There are a few things to note:<\/p>\n
- \n
- Unless you are building a very simple program with no apps, you are better off leaving DIRS empty. The default settings file configures APP_DIRS to True, so you are better off having a \u201ctemplates\u201d subdirectory in your Django app.<\/li>\n
- If you want to have a set of master templates at project root, e.g. mysite\\templates, you do need to set DIRS, like so:<\/li>\n<\/ul>\n
\u00a0\u00a0\u00a0\u00a0\u00a0 'DIRS': [os.path.join(BASE_DIR, 'templates')],<\/pre>\n
- \n
- Your templates directory does not have to be called templates \u2013 Django doesn\u2019t put any restrictions on the names you use \u2013 but it makes your project structure much easier to understand if you stick to convention.If you don\u2019t want to go with the default, or can\u2019t for some reason, you can specify any directory you want, as long as the directory and templates within that directory are readable by the user account under which your web server runs.<\/li>\n
- If you\u2019re on Windows, include your drive letter and use Unix-style forward slashes rather than backslashes, as follows:<\/li>\n<\/ul>\n
\u00a0\u00a0 'DIRS':\u00a0\u00a0\u00a0\u00a0\u00a0\n [\u00a0\u00a0\u00a0\u00a0\u00a0 \n 'C:\/www\/django\/templates',\u00a0\u00a0\u00a0\u00a0 \n \u00a0]<\/pre>\n
As we have not yet created a Django app, I am going to use a very simple configuration to demonstrate how template loading works. First, you will have to set DIRS to [os.path.join(BASE_DIR,’templates’)] as per the example above. Your settings file should now look like this:<\/p>\n
TEMPLATES = [\n {\n 'BACKEND': 'django.template.backends.django.DjangoTemplates',\n 'DIRS': [os.path.join(BASE_DIR,'templates')],\n 'APP_DIRS': True,\n 'OPTIONS': {<\/pre>\nWith DIRS set, the next thing to do is create a \\templates directory inside your root \\mysite folder. When you are finished, your folder structure should look like this:<\/span><\/p>\n
\\mysite_project\u00a0\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \\mysite\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \\mysite\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \\templates\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 manage.py<\/pre>\n
Next step is to change the view code to use Django\u2019s template-loading functionality rather than hard-coding the template paths. Returning to our current_datetime view, let\u2019s change it like so:<\/p>\n
#mysite\\mysite\\views.py\n\nfrom django.template.loader import get_template\nfrom django.http import HttpResponse\nimport datetime\n\ndef current_datetime(request):\nnow = datetime.datetime.now()\nt = get_template('current_datetime.html')\nhtml = t.render({'current_date': now})\nreturn HttpResponse(html)<\/pre>\nGenerally, you will use a Django template loader rather than using the low-level template API as in the previous examples. In this example, we\u2019re using the function django.template.loader.get_template() rather than loading the template from the filesystem manually. The get_template() function takes a template name as its argument, figures out where the template lives on the filesystem, opens that file, and returns a compiled Template object.<\/p>\n
Also note the difference between the render() method here and the previous examples. In the previous examples we are calling django.template.Template.render, which requires you to pass in a Context object. get_template() returns a backend-dependent Template from django.template.backends.base.Template, in which the render() method only accepts a dictionary object, not a Context object.<\/p>\n
Our template in this example is current_datetime.html, but there\u2019s nothing special about that .html extension. You can give your templates whatever extension makes sense for your application, or you can leave off extensions entirely.<\/p>\n
To determine the location of the template on your filesystem, get_template() will look in order:<\/p>\n
- \n
- If APP_DIRS is set to True, and assuming you are using the DTL, it will look for a \/templates directory in the current app.<\/li>\n
- If it does not find your template in the current app, get_template() combines your template directories from DIRS with the template name that you pass to get_template() and steps through each of them in order until it finds your template. For example, if the first entry in your DIRS is set to ‘\/home\/django\/mysite\/templates’, the above get_template() call would look for the template \/home\/django\/mysite\/templates\/current_datetime.html.<\/li>\n
- If get_template() cannot find the template with the given name, it raises a TemplateDoesNotExist exception.<\/li>\n<\/ul>\n
To see what a template exception looks like, fire up the Django development server again by running python manage.py runserver within your Django project\u2019s directory. Then, point your browser at the page that activates the current_datetime view (e.g., http:\/\/127.0.0.1:8000\/time\/). Assuming your DEBUG setting is set to True and you haven\u2019t yet created a current_datetime.html template, you should see a Django error page highlighting the TemplateDoesNotExist error<\/p>\n
![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/5.jpg\")
<\/p>\nThis error page is similar to the one explained earlier, with one additional piece of debugging information: a \u201cTemplate-loader postmortem\u201d section. This section tells you which templates Django tried to load, along with the reason each attempt failed (e.g., \u201cFile does not exist\u201d). This information is invaluable when you\u2019re trying to debug template-loading errors.<\/p>\n
To solve our missing template problem, let\u2019s create the current_datetime.html file using the following template code:<\/p>\n
# \\mysite_project\\mysite\\templates\\current_datetime.html\n\n<html>\n<body>\nIt is now {{ current_date }}\n<\/body>\n<\/html>\nIt is now {{ current_date }}.<\/pre>\nSave this file to the \\mysite\\templates directory you created previously. Refresh the page in your web browser, and you should see the fully rendered page<\/p>\n
render()<\/h3>\n
So far, I\u2019ve shown you how to load a template, fill a Context and return an HttpResponse object with the result of the rendered template. Next step was to optimize it to use get_template() instead of hard-coding templates and template paths.<\/p>\n
Django\u2019s developers recognized that, because this is such a common idiom, Django needed a shortcut that could do all this in one line of code. This shortcut is a function called render(), which lives in the module django.shortcuts. Most of the time, you\u2019ll be using render() rather than loading templates and creating Context and HttpResponse objects manually \u2013 however, it\u2019s useful to remember the complete process because it does come in handy for some non-standard use-cases.<\/p>\n
Here\u2019s the ongoing current_datetime example rewritten to use render():<\/p>\n
from django.shortcuts import render\nimport datetime\n\ndef current_datetime(request):\nnow = datetime.datetime.now()\nreturn render(request, 'current_datetime.html', {'current_date': now})<\/pre>\nWhat a difference! Let\u2019s step through the code changes:<\/p>\n
- \n
- We no longer have to import get_template, Template, Context, or HttpResponse. Instead, we import django.shortcuts.render. The import datetime remains.<\/li>\n
- Within the current_datetime function, we still calculate now, but the template loading, context creation, template rendering, and HttpResponse creation are all taken care of by the render() call. Because render() returns an HttpResponse object, we can simply return that value in the view.<\/li>\n<\/ul>\n
The first argument to render() is the request, the second is the name of the template to use. The third argument, if given, should be a dictionary to use in creating a Context for that template. If you don\u2019t provide a third argument, render() will use an empty dictionary.<\/p>\n
Template Subdirectories<\/h3>\n
It can get unwieldy to store all of your templates in a single directory. You might like to store templates in subdirectories of your template directory, and that\u2019s fine.<\/p>\n
In fact, I recommend doing so; some more advanced Django features (such as the generic views system) expect this template layout as a default convention. It also gives your templates their own namespace, the utility of which we will explore later in the book when we start building Django apps.<\/p>\n
Storing templates in subdirectories of your template directory is easy. In your calls to get_template(), just include the subdirectory name and a slash before the template name, like so:<\/p>\n
\u00a0\u00a0\u00a0 t = get_template('dateapp\/current_datetime.html')<\/pre>\nBecause render() is a small wrapper around get_template(), you can do the same thing with the second argument to render(), like this:<\/p>\n
return render(request, 'dateapp\/current_datetime.html', {'current_date': now})<\/pre>\nThere\u2019s no limit to the depth of your subdirectory tree. Feel free to use as many subdirectories as you like. As with all other methods in this chapter, Windows users must remember to use forwardslashes (\/) in path names, not backslashes (\\).<\/p>\n
The include Template Tag<\/h3>\n
Now that we\u2019ve covered the template-loading mechanism, we can introduce a built-in template tag that takes advantage of it: {% include %}.<\/p>\n
This tag allows you to include the contents of another template. The argument to the tag should be the name of the template to include, and the template name can be either a variable or a hard-coded (quoted) string, in either single or double quotes.<\/p>\n
Anytime you have the same code in multiple templates, consider using an {% include %} to remove the duplication. These two examples include the contents of the template nav.html. The examples are equivalent and illustrate that either single or double quotes are allowed:<\/p>\n
{% include 'nav.html' %}\n{% include \"nav.html\" %}<\/pre>\nThis example includes the contents of the template includes\/nav.html:<\/p>\n
{% include 'includes\/nav.html' %}<\/pre>\nThis example includes the contents of the template whose name is contained in the variable template_name:<\/p>\n
{% include template_name %}<\/pre>\nthe {% include %} tag also allows relative paths:<\/p>\n
{% include '.\/nav.html' %}\n{% include '..\/nav_base.html' %}\n\n\n<\/pre>\nAs in get_template(), the file name of the template is determined by either adding the path to the \\templates directory in the current Django app (if APPS_DIR is True) or by adding the template directory from DIRS to the requested template name. Included templates are evaluated with the context of the template that\u2019s including them.<\/p>\n
For example, consider these two templates:<\/p>\n
# mypage.html\n\n<html>\n<body>\n{% include \"includes\/nav.html\" %}\n<h1>{{ title }}<\/h1>\n<\/body>\n<\/html>\n\n# includes\/nav.html\n\nYou are in: {{ current_section }}<\/pre>\nIf you render mypage.html with a context containing current_section, then the variable will be available in the \u201cincluded\u201d template, as you would expect.<\/p>\n
If, in an {% include %} tag, a template with the given name isn\u2019t found, Django will do one of two things:<\/p>\n