class ResolverMatch [source] func The view function that would be used to serve the URL args The arguments that would be passed to the view function, as parsed from the URL. kwargs The keyword arguments that would be passed to the view function, as parsed from the URL. url_name The name of the URL pattern that matches the URL. app_name The application namespace for the URL pattern that matches the URL. app_names New in Django 1.9. The list of individual nam

resolve(path, urlconf=None) [source] path is the URL path you want to resolve. As with reverse(), you don’t need to worry about the urlconf parameter. The function returns a ResolverMatch object that allows you to access various metadata about the resolved URL. If the URL does not resolve, the function raises a Resolver404 exception (a subclass of Http404) .

get_script_prefix() [source] Normally, you should always use reverse() to define URLs within your application. However, if your application constructs part of the URL hierarchy itself, you may occasionally need to generate URLs. In that case, you need to be able to find the base URL of the Django project within its Web server (normally, reverse() takes care of this for you). In that case, you can call get_script_prefix(), which will return the script prefix portion of the URL for your Django

A clean, elegant URL scheme is an important detail in a high-quality Web application. Django lets you design URLs however you want, with no framework limitations. There’s no .php or .cgi required, and certainly none of that 0,2097,1-1-1928,00 nonsense. See Cool URIs don’t change, by World Wide Web creator Tim Berners-Lee, for excellent arguments on why URLs should be clean and usable. Overview To design URLs for an app, you create a Python module informally called a URLconf (URL configuration).

Django’s template system was overhauled in Django 1.8 when it gained support for multiple template engines. This document complements the release notes with detailed upgrade instructions on some topics. The TEMPLATES settings A new setting was introduced in Django 1.8: TEMPLATES. All existing template-related settings were deprecated. During the deprecation period, Django will create a backwards-compatible TEMPLATES based on the TEMPLATE_* settings if you don’t define it yourself. Here’s how to

While it can be a complex process at times, upgrading to the latest Django version has several benefits: New features and improvements are added. Bugs are fixed. Older version of Django will eventually no longer receive security updates. (see Supported versions). Upgrading as each new Django release is available makes future upgrades less painful by keeping your code base up to date. Here are some things to consider to help make your upgrade process as smooth as possible. Required Reading If

Django natively supports Unicode data everywhere. Providing your database can somehow store the data, you can safely pass around Unicode strings to templates, models and the database. This document tells you what you need to know if you’re writing applications that use data or templates that are encoded in something other than ASCII. Creating the database Make sure your database is configured to be able to store arbitrary string data. Normally, this means giving it an encoding of UTF-8 or UTF-1

Overview When support for time zones is enabled, Django stores datetime information in UTC in the database, uses time-zone-aware datetime objects internally, and translates them to the end user’s time zone in templates and forms. This is handy if your users live in more than one time zone and you want to display datetime information according to each user’s wall clock. Even if your website is available in only one time zone, it’s still good practice to store data in UTC in your database. The ma

This document explains the language syntax of the Django template system. If you’re looking for a more technical perspective on how it works and how to extend it, see The Django template language: for Python programmers. Django’s template language is designed to strike a balance between power and ease. It’s designed to feel comfortable to those used to working with HTML. If you have any exposure to other text-based template languages, such as Smarty or Jinja2, you should feel right at home with

Django’s admindocs app pulls documentation from the docstrings of models, views, template tags, and template filters for any app in INSTALLED_APPS and makes that documentation available from the Django admin. Overview To activate the admindocs, you will need to do the following: Add django.contrib.admindocs to your INSTALLED_APPS. Add url(r'^admin/doc/', include('django.contrib.admindocs.urls')) to your urlpatterns. Make sure it’s included before the r'^admin/' entry, so that requests to /admin