URLconfs—Django’s Navigator

There’s one last piece to the Django framework puzzle—the critical communication pathway that matches a request on the client-side with a project resource (the arrows between the view and the template in Figure 3.3). Like all web applications, Django uses Uniform Resource Locators (URLs) to match content with a request.

Django’s urls package provides dozens of functions and classes for working with different URL formats, name resolution, exception handling and other navigational utilities. However, at its most basic, it allows you to map a URL to a function or class within your Django project.

A Django URL configuration (or URLconf for short) matches a unique URL with a project resource. You can think of it being like matching a person’s name with their address. Except in Django, we’re not matching a street address—we’re matching a Python path using Python’s dot notation.

Assuming you’re not familiar with dot notation, it’s a common idiom in object-oriented programming. I like to think of the dot like a point because the dot points to something. With Python, the dot operator points to the next object in the object chain.

In Django classes, the object chain is like this:

package.module.class.method

Or with functions:

package.module.function.attribute

Some real-life examples:

• forms.Form points to the Form class in the forms package.
• events.apps.EventsConfig points to the EventsConfig class in the apps sub-package of the events package (i.e., the apps.py file in your events app).
• django.conf.urls points to the urls package inside the conf package inside Django, which is also a Python package!

This can sometimes get a bit confusing, but if you remember to join the dots (sorry, a bad pun there), you can usually find out what the dot operator is referring to.

With a URLconf, the path points to a function or class inside a module (.py file). Let’s look at our Django project diagram again (Figure 3.5).

Figure 3.5: Finding functions and classes with Django’s URLconfs.

To create a URLconf, we use the path() function. The first part of the function is the URL, so in Figure 3.5 the URL is app1/. The path() function then maps this URL to app1.views.some_view().

Assuming your site address is http://www.mycoolsite.com, in plain English we’re saying:

“When someone navigates to http://www.mycoolsite.com/app1/, run the some_view() function inside app1’s views.py file”

Note a URL doesn’t have to map to a view—it can map to any module in your Django app. For example, you may have a set of wireless environmental sensors that post data back to the server. You could have a custom module called sensors.py that has a function or class to record the sensor data to your database, all without ever touching a view.

And that’s all there is to it. Of course, URLconfs can do a lot more than map a static URL to a function or class, but if you can understand the basics—that Django’s incredibly fast and powerful navigation system is based on the simple concept of matching a URL with a resource—then you have all you need to tie all your Django apps together into a navigable web project.