The main thing to note here is the variable urlpatterns, which Django expects to find in your URLconf module. This variable defines the mapping between URLs and the code that handles those URLs. To add a URL and view to the URLconf, just add a mapping between a URL pattern and the view function. Here\u2019s how to hook in our hello view:<\/p>\n
from django.conf.urls import url\n\nfrom django.contrib import admin\n\nfrom mysite.views import hello \n\nurlpatterns = [ \n\n url(r'^admin\/', admin.site.urls), \n\n url(r'^hello\/\nWe made two changes here:<\/p>\n
- \n
- First, we imported the hello view from its module \u2013 mysite\/views.py, which translates into mysite.views in Python import syntax. (This assumes mysite\/views.py is on your Python path.)<\/li>\n
- Next, we added the line url(r'^hello\/$', hello), to urlpatterns. This line is referred to as a URLpattern. The url() function tells Django how to handle the URL that you are configuring. The first argument is a pattern-matching string (a regular expression; more on this in a bit) and the second argument is the view function to use for that pattern. url() can take other optional arguments as well.<\/li>\n<\/ul>\n
One more important detail we\u2019ve introduced here is that \u2018r\u2018 character in front of the regular expression string. This tells Python that the string is a \u201craw string\u201d \u2013 its contents should not interpret backslashes. In normal Python strings, backslashes are used for escaping special characters \u2013 such as in the string \u201c\\n\u201c, which is a one-character string containing a newline.<\/p>\n
When you add the r to make it a raw string, Python does not apply its backslash escaping \u2013 so, \u201cr'\\n'\u201d is a two-character string containing a literal backslash and a lowercase \u201cn\u201d. There\u2019s a natural collision between Python\u2019s usage of backslashes and the backslashes that are found in regular expressions, so it\u2019s best practice to use raw strings any time you\u2019re defining a regular expression in Django.<\/p>\n
In a nutshell, we just told Django that any request to the URL \/hello\/ should be handled by the hello view function. It\u2019s worth discussing the syntax of this URLpattern, as it may not be immediately obvious. Although we want to match the URL \/hello\/, the pattern looks a bit different than that. Here\u2019s why:<\/p>\n
- \n
- Django removes the slash from the front of every incoming URL before it checks the URLpatterns. This means that our URLpattern doesn\u2019t include the leading slash in \/hello\/. At first, this may seem unintuitive, but this requirement simplifies things \u2013 such as the inclusion of URLconfs within other URLconfs.<\/li>\n
- The pattern includes a caret (^) and a dollar sign ($). These are regular expression characters that have a special meaning: the caret means \u201crequire that the pattern matches the start of the string,\u201d and the dollar sign means \u201crequire that the pattern matches the end of the string.\u201d<\/li>\n<\/ul>\n
This concept is best explained by example. If we had instead used the pattern ^hello\/(without a dollar sign at the end), then any URL starting with \/hello\/ would match, such as \/hello\/foo and \/hello\/bar, not just \/hello\/.<\/p>\n
Similarly, if we had left off the initial caret character (i.e., hello\/$), Django would match any URL that ends with hello\/, such as \/foo\/bar\/hello\/. If we had simply used hello\/, without a caret or dollar sign, then any URL containing hello\/ would match, such as \/foo\/hello\/bar.Thus, we use both the caret and dollar sign to ensure that only the URL \/hello\/ matches \u2013 nothing more, nothing less.<\/p>\n
Most of your URLpatterns will start with carets and end with dollar signs, but it\u2019s nice to have the flexibility to perform more sophisticated matches. You may be wondering what happens if someone requests the URL \/hello (that is, without a trailing slash). Because our URLpattern requires a trailing slash, that URL would not match. However, by default, any request to a URL that doesn\u2019t match a URLpattern and doesn\u2019t end with a slash will be redirected to the same URL with a trailing slash (This is regulated by the APPEND_SLASH Django setting, which is covered in Appendix D).<\/p>\n
The other thing to note about this URLconf is that we\u2019ve passed the hello view function as an object without calling the function. This is a key feature of Python (and other dynamic languages): functions are first-class objects, which means you can pass them around just like any other variables. Cool stuff, eh?<\/p>\n
To test our changes to the URLconf, start the Django development server, by running the command python manage.py runserver from within your Python virtual environment. (If you left it running, that\u2019s fine, too. The development server automatically detects changes to your Python code and reloads as necessary, so you don\u2019t have to restart the server between changes.)<\/p>\n
The server is running at the address http:\/\/127.0.0.1:8000\/, so open up a web browser and go to http:\/\/127.0.0.1:8000\/hello\/. You should see the text \u201cHello world\u201d \u2013 the output of your Django view, as below<\/p>\n
![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/1-380x214.jpg\")
<\/p>\nRegular Expressions<\/h3>\n
Regular expressions (or regexes) are a compact way of specifying patterns in text. While Django URLconfs allow arbitrary regexes for powerful URL-matching capability, you\u2019ll probably use only a few regex patterns in practice. Here\u2019s a small selection of common patterns:<\/p>\n
<\/p>\n
\n\n
\n Symbol<\/strong><\/td>\n Matches<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n . (dot)<\/td>\n Any character<\/td>\n<\/tr>\n \n \\d<\/td>\n Any digit<\/td>\n<\/tr>\n \n [A-Z]<\/td>\n Any character, A-Z (uppercase)<\/td>\n<\/tr>\n \n [a-z]<\/td>\n Any character, a-z (lowercase)<\/td>\n<\/tr>\n \n [A-Za-z]<\/td>\n Any character, a-z (case insensitive)<\/td>\n<\/tr>\n \n +<\/td>\n One or more of the previous expression (e.g., \\d+ matches one or more digit)<\/td>\n<\/tr>\n \n [^\/]+<\/td>\n All characters except forward slash<\/td>\n<\/tr>\n \n ?<\/td>\n Zero or more of the previous expression (e.g., \\d* matches zero or more digits)<\/td>\n<\/tr>\n \n {1,3}<\/td>\n Between one and three (inclusive) of the previous expression<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n, views.home, name='home')Class-based views \n\n 1. Add an import: from other_app.views import Home \n\n2. Add a URL to urlpatterns: url(r'^\n If we ignore the documentation comments at the top of the file, here\u2019s the essence of a URLconf:<\/p>\n
<\/pre>\n
Let\u2019s step through this code one line at a time:<\/p>\n
- \n
- The first line imports two functions from the django.conf.urls module: include which allows you to include a full Python import path to another URLconf module, and url which uses a regular expression to pattern match the URL in your browser to a module in your Django project.<\/li>\n
- The second line calls the function admin from the django.contrib module. This function is called by the include function to load the URLs for the Django admin site.<\/li>\n
- The third line is urlpatterns \u2013 a simple list of url() instances.<\/li>\n<\/ul>\n
The main thing to note here is the variable urlpatterns, which Django expects to find in your URLconf module. This variable defines the mapping between URLs and the code that handles those URLs. To add a URL and view to the URLconf, just add a mapping between a URL pattern and the view function. Here\u2019s how to hook in our hello view:<\/p>\n
<\/pre>\n
We made two changes here:<\/p>\n
- \n
- First, we imported the hello view from its module \u2013 mysite\/views.py, which translates into mysite.views in Python import syntax. (This assumes mysite\/views.py is on your Python path.)<\/li>\n
- Next, we added the line url(r'^hello\/$', hello), to urlpatterns. This line is referred to as a URLpattern. The url() function tells Django how to handle the URL that you are configuring. The first argument is a pattern-matching string (a regular expression; more on this in a bit) and the second argument is the view function to use for that pattern. url() can take other optional arguments as well.<\/li>\n<\/ul>\n
One more important detail we\u2019ve introduced here is that \u2018r\u2018 character in front of the regular expression string. This tells Python that the string is a \u201craw string\u201d \u2013 its contents should not interpret backslashes. In normal Python strings, backslashes are used for escaping special characters \u2013 such as in the string \u201c\\n\u201c, which is a one-character string containing a newline.<\/p>\n
When you add the r to make it a raw string, Python does not apply its backslash escaping \u2013 so, \u201cr'\\n'\u201d is a two-character string containing a literal backslash and a lowercase \u201cn\u201d. There\u2019s a natural collision between Python\u2019s usage of backslashes and the backslashes that are found in regular expressions, so it\u2019s best practice to use raw strings any time you\u2019re defining a regular expression in Django.<\/p>\n
In a nutshell, we just told Django that any request to the URL \/hello\/ should be handled by the hello view function. It\u2019s worth discussing the syntax of this URLpattern, as it may not be immediately obvious. Although we want to match the URL \/hello\/, the pattern looks a bit different than that. Here\u2019s why:<\/p>\n
- \n
- Django removes the slash from the front of every incoming URL before it checks the URLpatterns. This means that our URLpattern doesn\u2019t include the leading slash in \/hello\/. At first, this may seem unintuitive, but this requirement simplifies things \u2013 such as the inclusion of URLconfs within other URLconfs.<\/li>\n
- The pattern includes a caret (^) and a dollar sign ($). These are regular expression characters that have a special meaning: the caret means \u201crequire that the pattern matches the start of the string,\u201d and the dollar sign means \u201crequire that the pattern matches the end of the string.\u201d<\/li>\n<\/ul>\n
This concept is best explained by example. If we had instead used the pattern ^hello\/(without a dollar sign at the end), then any URL starting with \/hello\/ would match, such as \/hello\/foo and \/hello\/bar, not just \/hello\/.<\/p>\n
Similarly, if we had left off the initial caret character (i.e., hello\/$), Django would match any URL that ends with hello\/, such as \/foo\/bar\/hello\/. If we had simply used hello\/, without a caret or dollar sign, then any URL containing hello\/ would match, such as \/foo\/hello\/bar.Thus, we use both the caret and dollar sign to ensure that only the URL \/hello\/ matches \u2013 nothing more, nothing less.<\/p>\n
Most of your URLpatterns will start with carets and end with dollar signs, but it\u2019s nice to have the flexibility to perform more sophisticated matches. You may be wondering what happens if someone requests the URL \/hello (that is, without a trailing slash). Because our URLpattern requires a trailing slash, that URL would not match. However, by default, any request to a URL that doesn\u2019t match a URLpattern and doesn\u2019t end with a slash will be redirected to the same URL with a trailing slash (This is regulated by the APPEND_SLASH Django setting, which is covered in Appendix D).<\/p>\n
The other thing to note about this URLconf is that we\u2019ve passed the hello view function as an object without calling the function. This is a key feature of Python (and other dynamic languages): functions are first-class objects, which means you can pass them around just like any other variables. Cool stuff, eh?<\/p>\n
To test our changes to the URLconf, start the Django development server, by running the command python manage.py runserver from within your Python virtual environment. (If you left it running, that\u2019s fine, too. The development server automatically detects changes to your Python code and reloads as necessary, so you don\u2019t have to restart the server between changes.)<\/p>\n
The server is running at the address http:\/\/127.0.0.1:8000\/, so open up a web browser and go to http:\/\/127.0.0.1:8000\/hello\/. You should see the text \u201cHello world\u201d \u2013 the output of your Django view, as below<\/p>\n
<\/p>\nRegular Expressions<\/h3>\n
Regular expressions (or regexes) are a compact way of specifying patterns in text. While Django URLconfs allow arbitrary regexes for powerful URL-matching capability, you\u2019ll probably use only a few regex patterns in practice. Here\u2019s a small selection of common patterns:<\/p>\n
<\/p>\n
\n\n
\n Symbol<\/strong><\/td>\n Matches<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n . (dot)<\/td>\n Any character<\/td>\n<\/tr>\n \n \\d<\/td>\n Any digit<\/td>\n<\/tr>\n \n [A-Z]<\/td>\n Any character, A-Z (uppercase)<\/td>\n<\/tr>\n \n [a-z]<\/td>\n Any character, a-z (lowercase)<\/td>\n<\/tr>\n \n [A-Za-z]<\/td>\n Any character, a-z (case insensitive)<\/td>\n<\/tr>\n \n +<\/td>\n One or more of the previous expression (e.g., \\d+ matches one or more digit)<\/td>\n<\/tr>\n \n [^\/]+<\/td>\n All characters except forward slash<\/td>\n<\/tr>\n \n ?<\/td>\n Zero or more of the previous expression (e.g., \\d* matches zero or more digits)<\/td>\n<\/tr>\n \n {1,3}<\/td>\n Between one and three (inclusive) of the previous expression<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n, Home.as_view(), name='home')Including another URLconf \n\n1. Import the include() function: from django.conf.urls import url, include \n\n 2. Add a URL to urlpatterns: url(r'^blog\/', include('blog.urls'))\n\n\"\"\"from django.conf.urls import url\n\n from django.contrib import admin urlpatterns = [ \n\n url(r'^admin\/', admin.site.urls),]\n\n\n<\/pre>\n If we ignore the documentation comments at the top of the file, here\u2019s the essence of a URLconf:<\/p>\n
<\/pre>\n
Let\u2019s step through this code one line at a time:<\/p>\n
- \n
- The first line imports two functions from the django.conf.urls module: include which allows you to include a full Python import path to another URLconf module, and url which uses a regular expression to pattern match the URL in your browser to a module in your Django project.<\/li>\n
- The second line calls the function admin from the django.contrib module. This function is called by the include function to load the URLs for the Django admin site.<\/li>\n
- The third line is urlpatterns \u2013 a simple list of url() instances.<\/li>\n<\/ul>\n
The main thing to note here is the variable urlpatterns, which Django expects to find in your URLconf module. This variable defines the mapping between URLs and the code that handles those URLs. To add a URL and view to the URLconf, just add a mapping between a URL pattern and the view function. Here\u2019s how to hook in our hello view:<\/p>\n
<\/pre>\n
We made two changes here:<\/p>\n
- \n
- First, we imported the hello view from its module \u2013 mysite\/views.py, which translates into mysite.views in Python import syntax. (This assumes mysite\/views.py is on your Python path.)<\/li>\n
- Next, we added the line url(r'^hello\/$', hello), to urlpatterns. This line is referred to as a URLpattern. The url() function tells Django how to handle the URL that you are configuring. The first argument is a pattern-matching string (a regular expression; more on this in a bit) and the second argument is the view function to use for that pattern. url() can take other optional arguments as well.<\/li>\n<\/ul>\n
One more important detail we\u2019ve introduced here is that \u2018r\u2018 character in front of the regular expression string. This tells Python that the string is a \u201craw string\u201d \u2013 its contents should not interpret backslashes. In normal Python strings, backslashes are used for escaping special characters \u2013 such as in the string \u201c\\n\u201c, which is a one-character string containing a newline.<\/p>\n
When you add the r to make it a raw string, Python does not apply its backslash escaping \u2013 so, \u201cr'\\n'\u201d is a two-character string containing a literal backslash and a lowercase \u201cn\u201d. There\u2019s a natural collision between Python\u2019s usage of backslashes and the backslashes that are found in regular expressions, so it\u2019s best practice to use raw strings any time you\u2019re defining a regular expression in Django.<\/p>\n
In a nutshell, we just told Django that any request to the URL \/hello\/ should be handled by the hello view function. It\u2019s worth discussing the syntax of this URLpattern, as it may not be immediately obvious. Although we want to match the URL \/hello\/, the pattern looks a bit different than that. Here\u2019s why:<\/p>\n
- \n
- Django removes the slash from the front of every incoming URL before it checks the URLpatterns. This means that our URLpattern doesn\u2019t include the leading slash in \/hello\/. At first, this may seem unintuitive, but this requirement simplifies things \u2013 such as the inclusion of URLconfs within other URLconfs.<\/li>\n
- The pattern includes a caret (^) and a dollar sign ($). These are regular expression characters that have a special meaning: the caret means \u201crequire that the pattern matches the start of the string,\u201d and the dollar sign means \u201crequire that the pattern matches the end of the string.\u201d<\/li>\n<\/ul>\n
This concept is best explained by example. If we had instead used the pattern ^hello\/(without a dollar sign at the end), then any URL starting with \/hello\/ would match, such as \/hello\/foo and \/hello\/bar, not just \/hello\/.<\/p>\n
Similarly, if we had left off the initial caret character (i.e., hello\/$), Django would match any URL that ends with hello\/, such as \/foo\/bar\/hello\/. If we had simply used hello\/, without a caret or dollar sign, then any URL containing hello\/ would match, such as \/foo\/hello\/bar.Thus, we use both the caret and dollar sign to ensure that only the URL \/hello\/ matches \u2013 nothing more, nothing less.<\/p>\n
Most of your URLpatterns will start with carets and end with dollar signs, but it\u2019s nice to have the flexibility to perform more sophisticated matches. You may be wondering what happens if someone requests the URL \/hello (that is, without a trailing slash). Because our URLpattern requires a trailing slash, that URL would not match. However, by default, any request to a URL that doesn\u2019t match a URLpattern and doesn\u2019t end with a slash will be redirected to the same URL with a trailing slash (This is regulated by the APPEND_SLASH Django setting, which is covered in Appendix D).<\/p>\n
The other thing to note about this URLconf is that we\u2019ve passed the hello view function as an object without calling the function. This is a key feature of Python (and other dynamic languages): functions are first-class objects, which means you can pass them around just like any other variables. Cool stuff, eh?<\/p>\n
To test our changes to the URLconf, start the Django development server, by running the command python manage.py runserver from within your Python virtual environment. (If you left it running, that\u2019s fine, too. The development server automatically detects changes to your Python code and reloads as necessary, so you don\u2019t have to restart the server between changes.)<\/p>\n
The server is running at the address http:\/\/127.0.0.1:8000\/, so open up a web browser and go to http:\/\/127.0.0.1:8000\/hello\/. You should see the text \u201cHello world\u201d \u2013 the output of your Django view, as below<\/p>\n
<\/p>\nRegular Expressions<\/h3>\n
Regular expressions (or regexes) are a compact way of specifying patterns in text. While Django URLconfs allow arbitrary regexes for powerful URL-matching capability, you\u2019ll probably use only a few regex patterns in practice. Here\u2019s a small selection of common patterns:<\/p>\n
<\/p>\n
\n\n
\n Symbol<\/strong><\/td>\n Matches<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n . (dot)<\/td>\n Any character<\/td>\n<\/tr>\n \n \\d<\/td>\n Any digit<\/td>\n<\/tr>\n \n [A-Z]<\/td>\n Any character, A-Z (uppercase)<\/td>\n<\/tr>\n \n [a-z]<\/td>\n Any character, a-z (lowercase)<\/td>\n<\/tr>\n \n [A-Za-z]<\/td>\n Any character, a-z (case insensitive)<\/td>\n<\/tr>\n \n +<\/td>\n One or more of the previous expression (e.g., \\d+ matches one or more digit)<\/td>\n<\/tr>\n \n [^\/]+<\/td>\n All characters except forward slash<\/td>\n<\/tr>\n \n ?<\/td>\n Zero or more of the previous expression (e.g., \\d* matches zero or more digits)<\/td>\n<\/tr>\n \n {1,3}<\/td>\n Between one and three (inclusive) of the previous expression<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n, hello),]\n\n\n<\/pre>\n We made two changes here:<\/p>\n
- \n
- First, we imported the hello view from its module \u2013 mysite\/views.py, which translates into mysite.views in Python import syntax. (This assumes mysite\/views.py is on your Python path.)<\/li>\n
- Next, we added the line url(r’^hello\/$’, hello), to urlpatterns. This line is referred to as a URLpattern. The url() function tells Django how to handle the URL that you are configuring. The first argument is a pattern-matching string (a regular expression; more on this in a bit) and the second argument is the view function to use for that pattern. url() can take other optional arguments as well.<\/li>\n<\/ul>\n
One more important detail we\u2019ve introduced here is that \u2018r\u2018 character in front of the regular expression string. This tells Python that the string is a \u201craw string\u201d \u2013 its contents should not interpret backslashes. In normal Python strings, backslashes are used for escaping special characters \u2013 such as in the string \u201c\\n\u201c, which is a one-character string containing a newline.<\/p>\n
When you add the r to make it a raw string, Python does not apply its backslash escaping \u2013 so, \u201cr’\\n’\u201d is a two-character string containing a literal backslash and a lowercase \u201cn\u201d. There\u2019s a natural collision between Python\u2019s usage of backslashes and the backslashes that are found in regular expressions, so it\u2019s best practice to use raw strings any time you\u2019re defining a regular expression in Django.<\/p>\n
In a nutshell, we just told Django that any request to the URL \/hello\/ should be handled by the hello view function. It\u2019s worth discussing the syntax of this URLpattern, as it may not be immediately obvious. Although we want to match the URL \/hello\/, the pattern looks a bit different than that. Here\u2019s why:<\/p>\n
- \n
- Django removes the slash from the front of every incoming URL before it checks the URLpatterns. This means that our URLpattern doesn\u2019t include the leading slash in \/hello\/. At first, this may seem unintuitive, but this requirement simplifies things \u2013 such as the inclusion of URLconfs within other URLconfs.<\/li>\n
- The pattern includes a caret (^) and a dollar sign ($). These are regular expression characters that have a special meaning: the caret means \u201crequire that the pattern matches the start of the string,\u201d and the dollar sign means \u201crequire that the pattern matches the end of the string.\u201d<\/li>\n<\/ul>\n
This concept is best explained by example. If we had instead used the pattern ^hello\/(without a dollar sign at the end), then any URL starting with \/hello\/ would match, such as \/hello\/foo and \/hello\/bar, not just \/hello\/.<\/p>\n
Similarly, if we had left off the initial caret character (i.e., hello\/$), Django would match any URL that ends with hello\/, such as \/foo\/bar\/hello\/. If we had simply used hello\/, without a caret or dollar sign, then any URL containing hello\/ would match, such as \/foo\/hello\/bar.Thus, we use both the caret and dollar sign to ensure that only the URL \/hello\/ matches \u2013 nothing more, nothing less.<\/p>\n
Most of your URLpatterns will start with carets and end with dollar signs, but it\u2019s nice to have the flexibility to perform more sophisticated matches. You may be wondering what happens if someone requests the URL \/hello (that is, without a trailing slash). Because our URLpattern requires a trailing slash, that URL would not match. However, by default, any request to a URL that doesn\u2019t match a URLpattern and doesn\u2019t end with a slash will be redirected to the same URL with a trailing slash (This is regulated by the APPEND_SLASH Django setting, which is covered in Appendix D).<\/p>\n
The other thing to note about this URLconf is that we\u2019ve passed the hello view function as an object without calling the function. This is a key feature of Python (and other dynamic languages): functions are first-class objects, which means you can pass them around just like any other variables. Cool stuff, eh?<\/p>\n
To test our changes to the URLconf, start the Django development server, by running the command python manage.py runserver from within your Python virtual environment. (If you left it running, that\u2019s fine, too. The development server automatically detects changes to your Python code and reloads as necessary, so you don\u2019t have to restart the server between changes.)<\/p>\n
The server is running at the address http:\/\/127.0.0.1:8000\/, so open up a web browser and go to http:\/\/127.0.0.1:8000\/hello\/. You should see the text \u201cHello world\u201d \u2013 the output of your Django view, as below<\/p>\n
<\/p>\nRegular Expressions<\/h3>\n
Regular expressions (or regexes) are a compact way of specifying patterns in text. While Django URLconfs allow arbitrary regexes for powerful URL-matching capability, you\u2019ll probably use only a few regex patterns in practice. Here\u2019s a small selection of common patterns:<\/p>\n
<\/p>\n
\n\n
\n Symbol<\/strong><\/td>\n Matches<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n . (dot)<\/td>\n Any character<\/td>\n<\/tr>\n \n \\d<\/td>\n Any digit<\/td>\n<\/tr>\n \n [A-Z]<\/td>\n Any character, A-Z (uppercase)<\/td>\n<\/tr>\n \n [a-z]<\/td>\n Any character, a-z (lowercase)<\/td>\n<\/tr>\n \n [A-Za-z]<\/td>\n Any character, a-z (case insensitive)<\/td>\n<\/tr>\n \n +<\/td>\n One or more of the previous expression (e.g., \\d+ matches one or more digit)<\/td>\n<\/tr>\n \n [^\/]+<\/td>\n All characters except forward slash<\/td>\n<\/tr>\n \n ?<\/td>\n Zero or more of the previous expression (e.g., \\d* matches zero or more digits)<\/td>\n<\/tr>\n \n {1,3}<\/td>\n Between one and three (inclusive) of the previous expression<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n, views.home, name=’home’)Class-based views \n\n 1. Add an import: from other_app.views import Home \n\n2. Add a URL to urlpatterns: url(r’^\n If we ignore the documentation comments at the top of the file, here\u2019s the essence of a URLconf:<\/p>\n
<\/pre>\n
Let\u2019s step through this code one line at a time:<\/p>\n
- \n
- The first line imports two functions from the django.conf.urls module: include which allows you to include a full Python import path to another URLconf module, and url which uses a regular expression to pattern match the URL in your browser to a module in your Django project.<\/li>\n
- The second line calls the function admin from the django.contrib module. This function is called by the include function to load the URLs for the Django admin site.<\/li>\n
- The third line is urlpatterns \u2013 a simple list of url() instances.<\/li>\n<\/ul>\n
The main thing to note here is the variable urlpatterns, which Django expects to find in your URLconf module. This variable defines the mapping between URLs and the code that handles those URLs. To add a URL and view to the URLconf, just add a mapping between a URL pattern and the view function. Here\u2019s how to hook in our hello view:<\/p>\n
<\/pre>\n
We made two changes here:<\/p>\n
- \n
- First, we imported the hello view from its module \u2013 mysite\/views.py, which translates into mysite.views in Python import syntax. (This assumes mysite\/views.py is on your Python path.)<\/li>\n
- Next, we added the line url(r’^hello\/$’, hello), to urlpatterns. This line is referred to as a URLpattern. The url() function tells Django how to handle the URL that you are configuring. The first argument is a pattern-matching string (a regular expression; more on this in a bit) and the second argument is the view function to use for that pattern. url() can take other optional arguments as well.<\/li>\n<\/ul>\n
One more important detail we\u2019ve introduced here is that \u2018r\u2018 character in front of the regular expression string. This tells Python that the string is a \u201craw string\u201d \u2013 its contents should not interpret backslashes. In normal Python strings, backslashes are used for escaping special characters \u2013 such as in the string \u201c\\n\u201c, which is a one-character string containing a newline.<\/p>\n
When you add the r to make it a raw string, Python does not apply its backslash escaping \u2013 so, \u201cr’\\n’\u201d is a two-character string containing a literal backslash and a lowercase \u201cn\u201d. There\u2019s a natural collision between Python\u2019s usage of backslashes and the backslashes that are found in regular expressions, so it\u2019s best practice to use raw strings any time you\u2019re defining a regular expression in Django.<\/p>\n
In a nutshell, we just told Django that any request to the URL \/hello\/ should be handled by the hello view function. It\u2019s worth discussing the syntax of this URLpattern, as it may not be immediately obvious. Although we want to match the URL \/hello\/, the pattern looks a bit different than that. Here\u2019s why:<\/p>\n
- \n
- Django removes the slash from the front of every incoming URL before it checks the URLpatterns. This means that our URLpattern doesn\u2019t include the leading slash in \/hello\/. At first, this may seem unintuitive, but this requirement simplifies things \u2013 such as the inclusion of URLconfs within other URLconfs.<\/li>\n
- The pattern includes a caret (^) and a dollar sign ($). These are regular expression characters that have a special meaning: the caret means \u201crequire that the pattern matches the start of the string,\u201d and the dollar sign means \u201crequire that the pattern matches the end of the string.\u201d<\/li>\n<\/ul>\n
This concept is best explained by example. If we had instead used the pattern ^hello\/(without a dollar sign at the end), then any URL starting with \/hello\/ would match, such as \/hello\/foo and \/hello\/bar, not just \/hello\/.<\/p>\n
Similarly, if we had left off the initial caret character (i.e., hello\/$), Django would match any URL that ends with hello\/, such as \/foo\/bar\/hello\/. If we had simply used hello\/, without a caret or dollar sign, then any URL containing hello\/ would match, such as \/foo\/hello\/bar.Thus, we use both the caret and dollar sign to ensure that only the URL \/hello\/ matches \u2013 nothing more, nothing less.<\/p>\n
Most of your URLpatterns will start with carets and end with dollar signs, but it\u2019s nice to have the flexibility to perform more sophisticated matches. You may be wondering what happens if someone requests the URL \/hello (that is, without a trailing slash). Because our URLpattern requires a trailing slash, that URL would not match. However, by default, any request to a URL that doesn\u2019t match a URLpattern and doesn\u2019t end with a slash will be redirected to the same URL with a trailing slash (This is regulated by the APPEND_SLASH Django setting, which is covered in Appendix D).<\/p>\n
The other thing to note about this URLconf is that we\u2019ve passed the hello view function as an object without calling the function. This is a key feature of Python (and other dynamic languages): functions are first-class objects, which means you can pass them around just like any other variables. Cool stuff, eh?<\/p>\n
To test our changes to the URLconf, start the Django development server, by running the command python manage.py runserver from within your Python virtual environment. (If you left it running, that\u2019s fine, too. The development server automatically detects changes to your Python code and reloads as necessary, so you don\u2019t have to restart the server between changes.)<\/p>\n
The server is running at the address http:\/\/127.0.0.1:8000\/, so open up a web browser and go to http:\/\/127.0.0.1:8000\/hello\/. You should see the text \u201cHello world\u201d \u2013 the output of your Django view, as below<\/p>\n
<\/p>\nRegular Expressions<\/h3>\n
Regular expressions (or regexes) are a compact way of specifying patterns in text. While Django URLconfs allow arbitrary regexes for powerful URL-matching capability, you\u2019ll probably use only a few regex patterns in practice. Here\u2019s a small selection of common patterns:<\/p>\n
<\/p>\n
\n\n
\n Symbol<\/strong><\/td>\n Matches<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n . (dot)<\/td>\n Any character<\/td>\n<\/tr>\n \n \\d<\/td>\n Any digit<\/td>\n<\/tr>\n \n [A-Z]<\/td>\n Any character, A-Z (uppercase)<\/td>\n<\/tr>\n \n [a-z]<\/td>\n Any character, a-z (lowercase)<\/td>\n<\/tr>\n \n [A-Za-z]<\/td>\n Any character, a-z (case insensitive)<\/td>\n<\/tr>\n \n +<\/td>\n One or more of the previous expression (e.g., \\d+ matches one or more digit)<\/td>\n<\/tr>\n \n [^\/]+<\/td>\n All characters except forward slash<\/td>\n<\/tr>\n \n ?<\/td>\n Zero or more of the previous expression (e.g., \\d* matches zero or more digits)<\/td>\n<\/tr>\n \n {1,3}<\/td>\n Between one and three (inclusive) of the previous expression<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n, Home.as_view(), name=’home’)Including another URLconf \n\n1. Import the include() function: from django.conf.urls import url, include \n\n 2. Add a URL to urlpatterns: url(r’^blog\/’, include(‘blog.urls’))\n\n“””from django.conf.urls import url\n\n from django.contrib import admin urlpatterns = [ \n\n url(r’^admin\/’, admin.site.urls),]\n\n\n\n If we ignore the documentation comments at the top of the file, here\u2019s the essence of a URLconf:<\/p>\n
<\/pre>\n
Let\u2019s step through this code one line at a time:<\/p>\n
- \n
- The first line imports two functions from the django.conf.urls module: include which allows you to include a full Python import path to another URLconf module, and url which uses a regular expression to pattern match the URL in your browser to a module in your Django project.<\/li>\n
- The second line calls the function admin from the django.contrib module. This function is called by the include function to load the URLs for the Django admin site.<\/li>\n
- The third line is urlpatterns \u2013 a simple list of url() instances.<\/li>\n<\/ul>\n
The main thing to note here is the variable urlpatterns, which Django expects to find in your URLconf module. This variable defines the mapping between URLs and the code that handles those URLs. To add a URL and view to the URLconf, just add a mapping between a URL pattern and the view function. Here\u2019s how to hook in our hello view:<\/p>\n
<\/pre>\n
We made two changes here:<\/p>\n
- \n
- First, we imported the hello view from its module \u2013 mysite\/views.py, which translates into mysite.views in Python import syntax. (This assumes mysite\/views.py is on your Python path.)<\/li>\n
- Next, we added the line url(r’^hello\/$’, hello), to urlpatterns. This line is referred to as a URLpattern. The url() function tells Django how to handle the URL that you are configuring. The first argument is a pattern-matching string (a regular expression; more on this in a bit) and the second argument is the view function to use for that pattern. url() can take other optional arguments as well.<\/li>\n<\/ul>\n
One more important detail we\u2019ve introduced here is that \u2018r\u2018 character in front of the regular expression string. This tells Python that the string is a \u201craw string\u201d \u2013 its contents should not interpret backslashes. In normal Python strings, backslashes are used for escaping special characters \u2013 such as in the string \u201c\\n\u201c, which is a one-character string containing a newline.<\/p>\n
When you add the r to make it a raw string, Python does not apply its backslash escaping \u2013 so, \u201cr’\\n’\u201d is a two-character string containing a literal backslash and a lowercase \u201cn\u201d. There\u2019s a natural collision between Python\u2019s usage of backslashes and the backslashes that are found in regular expressions, so it\u2019s best practice to use raw strings any time you\u2019re defining a regular expression in Django.<\/p>\n
In a nutshell, we just told Django that any request to the URL \/hello\/ should be handled by the hello view function. It\u2019s worth discussing the syntax of this URLpattern, as it may not be immediately obvious. Although we want to match the URL \/hello\/, the pattern looks a bit different than that. Here\u2019s why:<\/p>\n
- \n
- Django removes the slash from the front of every incoming URL before it checks the URLpatterns. This means that our URLpattern doesn\u2019t include the leading slash in \/hello\/. At first, this may seem unintuitive, but this requirement simplifies things \u2013 such as the inclusion of URLconfs within other URLconfs.<\/li>\n
- The pattern includes a caret (^) and a dollar sign ($). These are regular expression characters that have a special meaning: the caret means \u201crequire that the pattern matches the start of the string,\u201d and the dollar sign means \u201crequire that the pattern matches the end of the string.\u201d<\/li>\n<\/ul>\n
This concept is best explained by example. If we had instead used the pattern ^hello\/(without a dollar sign at the end), then any URL starting with \/hello\/ would match, such as \/hello\/foo and \/hello\/bar, not just \/hello\/.<\/p>\n
Similarly, if we had left off the initial caret character (i.e., hello\/$), Django would match any URL that ends with hello\/, such as \/foo\/bar\/hello\/. If we had simply used hello\/, without a caret or dollar sign, then any URL containing hello\/ would match, such as \/foo\/hello\/bar.Thus, we use both the caret and dollar sign to ensure that only the URL \/hello\/ matches \u2013 nothing more, nothing less.<\/p>\n
Most of your URLpatterns will start with carets and end with dollar signs, but it\u2019s nice to have the flexibility to perform more sophisticated matches. You may be wondering what happens if someone requests the URL \/hello (that is, without a trailing slash). Because our URLpattern requires a trailing slash, that URL would not match. However, by default, any request to a URL that doesn\u2019t match a URLpattern and doesn\u2019t end with a slash will be redirected to the same URL with a trailing slash (This is regulated by the APPEND_SLASH Django setting, which is covered in Appendix D).<\/p>\n
The other thing to note about this URLconf is that we\u2019ve passed the hello view function as an object without calling the function. This is a key feature of Python (and other dynamic languages): functions are first-class objects, which means you can pass them around just like any other variables. Cool stuff, eh?<\/p>\n
To test our changes to the URLconf, start the Django development server, by running the command python manage.py runserver from within your Python virtual environment. (If you left it running, that\u2019s fine, too. The development server automatically detects changes to your Python code and reloads as necessary, so you don\u2019t have to restart the server between changes.)<\/p>\n
The server is running at the address http:\/\/127.0.0.1:8000\/, so open up a web browser and go to http:\/\/127.0.0.1:8000\/hello\/. You should see the text \u201cHello world\u201d \u2013 the output of your Django view, as below<\/p>\n
<\/p>\nRegular Expressions<\/h3>\n
Regular expressions (or regexes) are a compact way of specifying patterns in text. While Django URLconfs allow arbitrary regexes for powerful URL-matching capability, you\u2019ll probably use only a few regex patterns in practice. Here\u2019s a small selection of common patterns:<\/p>\n
<\/p>\n
\n\n
\n Symbol<\/strong><\/td>\n Matches<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n . (dot)<\/td>\n Any character<\/td>\n<\/tr>\n \n \\d<\/td>\n Any digit<\/td>\n<\/tr>\n \n [A-Z]<\/td>\n Any character, A-Z (uppercase)<\/td>\n<\/tr>\n \n [a-z]<\/td>\n Any character, a-z (lowercase)<\/td>\n<\/tr>\n \n [A-Za-z]<\/td>\n Any character, a-z (case insensitive)<\/td>\n<\/tr>\n \n +<\/td>\n One or more of the previous expression (e.g., \\d+ matches one or more digit)<\/td>\n<\/tr>\n \n [^\/]+<\/td>\n All characters except forward slash<\/td>\n<\/tr>\n \n ?<\/td>\n Zero or more of the previous expression (e.g., \\d* matches zero or more digits)<\/td>\n<\/tr>\n \n {1,3}<\/td>\n Between one and three (inclusive) of the previous expression<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n