There are a couple of things going on here that you haven\u2019t yet seen. First, there\u2019s request.GET. This is how you access GET data from Django; POST data is accessed through a similar request.POST object. These objects behave exactly like standard Python dictionaries.<\/p>\n
What\u2019s GET and POST Data?<\/strong> – GET and POST are the two methods that browsers use to send data to a server. Most of the time, you\u2019ll see them in HTML form tags:<\/p>\n This instructs the browser to submit the form data to the URL \/books\/search\/ using the GET method. There are important differences between the semantics of GET and POST that we won\u2019t get into right now, but see http:\/\/www.w3.org\/2001\/tag\/doc\/whenToUseGet.html if you want to learn more. So the line:<\/p>\n looks for a GET parameter named q and returns an empty string if that parameter wasn\u2019t submitted.<\/p>\n Note that we\u2019re using the get() method on request.GET, which is potentially confusing. The get() method here is the one that every Python dictionary has. We\u2019re using it here to be careful: it is not safe to assume that request.GET contains a ‘q’ key, so we use get(‘q’, ”) to provide a default fallback value of ” (the empty string). If we merely accessed the variable using request.GET[‘q’], that code would raise a KeyError if q wasn\u2019t available in the GET data.<\/p>\n Second, what about this Q business? Q objects are used to build up complex queries \u2014 in this case, we\u2019re searching for any books where either the title or the name of one of the authors matches the search query. Technically, these Q objects comprise a QuerySet.<\/p>\n In these queries, icontains is a case-insensitive search that uses the SQL LIKE operator in the underlying database.<\/p>\n Since we\u2019re searching against a many-to-many field, it\u2019s possible for the same book to be returned more than once by the query (e.g., a book with two authors who both match the search query). Adding .distinct() to the filter lookup eliminates any duplicate results. Hopefully by now what this does is fairly obvious. However, there are a few subtleties worth pointing out: The form\u2019s action is ., which means \u201cthe current URL.\u201d This is a standard best practice: don\u2019t use separate views for the form page and the results page; use a single one that serves the form and search results.<\/p>\n We reinsert the value of the query back into the <input>. This lets readers easily refine their searches without having to retype what they searched for. Everywhere query and book is used, we pass it through the escape filter to make sure that any potentially malicious search text is filtered out before being inserted into the page. It\u2019s vital that you do this with any user-submitted content! Otherwise you open your site up to cross-site scripting (XSS) attacks.<\/p>\n However, we don\u2019t need to worry about harmful content in your database lookups \u2014 we can simply pass the query into the lookup as is. This is because Django\u2019s database layer handles this aspect of security for you.<\/p>\n Now we have a working search. A further improvement would be putting a search form on every page (i.e., in the base template); we\u2019ll let you handle that one yourself.<\/p>\n So why the distinction?<\/p>\n Because both request.GET and request.POST have additional methods that normal dictionaries don\u2019t have. We\u2019ll get into these in a short while. You might have encountered the similar term \u201cfile-like objects\u201d \u2013 Python objects that have a few basic methods, like read(), that let them act as stand-ins for \u201creal\u201d file objects.<\/p>\n HTML forms are the backbone of interactive web sites, from the simplicity of Google\u2019s single search box to ubiquitous blog comment submission forms, to complex custom data-entry interfaces. We will cover how you can use Django to access user-submitted form data, validate it and do something with it. Along the way, we\u2019ll cover HttpRequest and Form objects.<\/p>\n Recall that each view function takes an HttpRequest object as its first parameter, as in our hello() view:<\/p>\n HttpRequest objects, such as the variable request here, have a number of interesting attributes and methods that you should familiarize yourself with, so that you know what\u2019s possible. You can use these attributes to get information about the current request (i.e., the user\/web browser that\u2019s loading the current page on your Django-powered site), at the time the view function is executed. Always use these attributes\/methods instead of hard-coding URLs in your views. This makes for more flexible code that can be reused in other places. A simplistic example:<\/p>\n request.META is a Python dictionary containing all available HTTP headers for the given request \u2013 including the user\u2019s IP address and user agent (generally the name and version of the web browser). Note that the full list of available headers depends on which headers the user sent and which headers your web server sets. Some commonly available keys in this dictionary are:<\/p>\n Note that because request.META is just a basic Python dictionary, you\u2019ll get a KeyError exception if you try to access a key that doesn\u2019t exist. (Because HTTP headers are external data \u2013 that is, they\u2019re submitted by your users\u2019 browsers \u2013 they shouldn\u2019t be trusted, and you should always design your application to fail gracefully if a particular header is empty or doesn\u2019t exist.) You should either use a try\/except clause or the get() method to handle the case of undefined keys:<\/p>\n Another good way to see what sort of information that the request object contains is to look closely at the Django error pages when you crash the system \u2013 there is a wealth of useful information in there, including all the HTTP headers and other request objects (request.path for example).<\/p>\n Beyond basic metadata about the request, HttpRequest objects have two attributes that contain information submitted by the user: request.GET and request.POST. Both of these are dictionary-like objects that give you access to GET and POST data. POST data generally is submitted from an HTML <form>, while GET data can come from a <form> or the query string in the page\u2019s URL.<\/p>\n Dictionary-like objects<\/strong> – When I say request.GET and request.POST are \u201cdictionary-like\u201d objects, I mean that they behave like standard Python dictionaries but aren\u2019t technically dictionaries under the hood. For example, request.GET and request.POST both have get(), keys() and values() methods, and you can iterate over the keys by doing for key in request.GET.<\/p>\n Continuing the ongoing example of books, authors and publishers, let\u2019s create a simple view that lets users search our book database by title. Generally, there are two parts to developing a form: the HTML user interface and the backend view code that processes the submitted data. The first part is easy; let\u2019s just set up a view that displays a search form. When you used startapp to create your books app, Django created a new views.py file for you in your \\books folder. Go ahead and add a new view to this file:<\/p>\n Next step is to create the template, however we first need to create a couple of new folders for the template. If you haven\u2019t changed it, the ‘APP_DIRS’ in your settings file is set to True. This means that Django will search all of your apps for a folder named \\templates.<\/p>\n Create a new \\templates folder inside your books app folder. Then go ahead and create another folder inside the new \\templates folder and call it books. Your final folder structure will be books\\templates\\books\\.<\/p>\n This inner books folder is important for namespacing your templates. Because Django will search all apps for a matching template, creating a namespace for the app templates ensures that Django uses the correct template if two apps used the same template name.<\/p>\n Create the following search_form.html file and save it to your new folder:<\/p>\n Now we need to create a URLconf so Django can find our new view. Inside your books folder, create a new urls.py file (startapp doesn\u2019t create this file). Add the following URL pattern to this new urls.py:<\/p>\n (Note that we\u2019re importing the views module directly, instead of something like from books.views import search_form, because the former is less verbose.<\/p>\n One last thing \u2013 when Django searches for URL patterns, it will only search the base mysite\\urls.py file, unless we explicitly include the URL patterns from other apps. So let\u2019s go ahead and modify our site urlpatterns:<\/p>\n This new URL pattern must be added to the end of the urlpatterns list. This is because the r'^' regex sends everything to books.urls, so we want to make sure none of the other patterns match, before sending Django to check books\\urls.py for a matching pattern.<\/p>\n Now, if you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, you\u2019ll see the search interface (Figure 6.1). Simple enough.<\/p>\n Try submitting the form, though, and you\u2019ll get a Django 404 error. The form points to the URL \/search\/, which hasn\u2019t yet been implemented. Let\u2019s fix that with a second view function:<\/p>\n Query String Parameters<\/strong> - Because GET data is passed in the query string (e.g., \/search\/?q=django), you can use request.GET to access query string variables. In introduction of Django\u2019s URLconf system, I compared Django\u2019s pretty URLs to more traditional PHP\/Java URLs such as \/time\/plus?hours=3 and said I\u2019d show you how to do the latter.<\/p>\n Now you know how to access query string parameters in your views (like hours=3 in this example) \u2013 use request.GET. POST data works the same way as GET data \u2013 just use request.POST instead of request.GET. What\u2019s the difference between GET and POST?<\/p>\n Use GET when the act of submitting the form is just a request to \u201cget\u201d data. Use POST whenever the act of submitting the form will have some side effect \u2013 changing data, or sending an e-mail, or something else that\u2019s beyond simple display of data. In our book search example, we\u2019re using GET because the query doesn\u2019t change any data on our server.<\/p>\n Now that we\u2019ve verified request.GET is being passed in properly, let\u2019s hook the user\u2019s search query into our book database (again, in views.py):<\/p>\n A couple of notes on what we did here:<\/p>\n This is a very simple way to do a book search. I wouldn\u2019t recommend using a simple icontains query on a large production database, as it can be slow. (In the real world, you\u2019d want to use a custom search system of some sort. Search the web for open-source full-text search to get an idea of the possibilities.)<\/p>\n We pass books, a list of Book objects, to the template. To get our new search form working, let\u2019s create the search_results.html file:<\/p>\n Note usage of the pluralize template filter, which outputs an \u201cs\u201d if appropriate, based on the number of books found.<\/p>\n Now, when you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, your search term should return a more useful result below figure.<\/p>\n Improving Our Simple Form-Handling Example<\/strong> - As in previous chapters, I\u2019ve shown you the simplest thing that could possibly work. Now I\u2019ll point out some problems and show you how to improve it. First, our search() view\u2019s handling of an empty query is poor \u2013 we\u2019re just displaying a \u201cPlease submit a search term.\u201d message, requiring the user to hit the browser\u2019s back button. This is horrid and unprofessional, and if you ever actually implement something like this in the wild, your Django privileges will be revoked.<\/p>\n It would be much better to redisplay the form, with an error above it, so that the user can try again immediately. The easiest way to do that would be to render the template again, like this:<\/p>\n Note that I\u2019ve included search_form() here so you can see both views in one place. Here, we\u2019ve improved search() to render the search_form.html template again, if the query is empty. And because we need to display an error message in that template, we pass a template variable. Now we can edit search_form.html to check for the error variable:<\/span><\/p>\n We can still use this template from our original view, search_form(), because search_form() doesn\u2019t pass error to the template \u2013 so the error message won\u2019t show up in that case (Figure 6-4).<\/p>\n With this change in place, it\u2019s a better application, but it now begs the question: is a dedicated search_form() view really necessary? As it stands, a request to the URL \/search\/ (without any GET parameters) will display the empty form (but with an error). We can remove the search_form() view, along with its associated URLpattern, as long as we change search() to hide the error message when somebody visits \/search\/ with no GET parameters:<\/p>\n def search(request): In this updated view, if a user visits \/search\/ with no GET parameters, they\u2019ll see the search form with no error message. If a user submits the form with an empty value for 'q', they\u2019ll see the search form with an error message. And, finally, if a user submits the form with a non-empty value for 'q', they\u2019ll see the search results.<\/p>\n We can make one final improvement to this application, to remove a bit of redundancy. Now that we\u2019ve rolled the two views and URLs into one and \/search\/ handles both search-form display and result display, the HTML <form> in search_form.html doesn\u2019t have to hard-code a URL. Instead of this:<\/p>\n It can be changed to this:<\/p>\n The action=\"\" means \u201cSubmit the form to the same URL as the current page.\u201d With this change in place, you won\u2019t have to remember to change the action if you ever hook the search() view to another URL.<\/p>\n, views.search_form),\n]<\/pre>\n (Note that we\u2019re importing the views module directly, instead of something like from books.views import search_form, because the former is less verbose.<\/p>\n One last thing \u2013 when Django searches for URL patterns, it will only search the base mysite\\urls.py file, unless we explicitly include the URL patterns from other apps. So let\u2019s go ahead and modify our site urlpatterns:<\/p>\n This new URL pattern must be added to the end of the urlpatterns list. This is because the r'^' regex sends everything to books.urls, so we want to make sure none of the other patterns match, before sending Django to check books\\urls.py for a matching pattern.<\/p>\n Now, if you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, you\u2019ll see the search interface (Figure 6.1). Simple enough.<\/p>\n Try submitting the form, though, and you\u2019ll get a Django 404 error. The form points to the URL \/search\/, which hasn\u2019t yet been implemented. Let\u2019s fix that with a second view function:<\/p>\n Query String Parameters<\/strong> - Because GET data is passed in the query string (e.g., \/search\/?q=django), you can use request.GET to access query string variables. In introduction of Django\u2019s URLconf system, I compared Django\u2019s pretty URLs to more traditional PHP\/Java URLs such as \/time\/plus?hours=3 and said I\u2019d show you how to do the latter.<\/p>\n Now you know how to access query string parameters in your views (like hours=3 in this example) \u2013 use request.GET. POST data works the same way as GET data \u2013 just use request.POST instead of request.GET. What\u2019s the difference between GET and POST?<\/p>\n Use GET when the act of submitting the form is just a request to \u201cget\u201d data. Use POST whenever the act of submitting the form will have some side effect \u2013 changing data, or sending an e-mail, or something else that\u2019s beyond simple display of data. In our book search example, we\u2019re using GET because the query doesn\u2019t change any data on our server.<\/p>\n Now that we\u2019ve verified request.GET is being passed in properly, let\u2019s hook the user\u2019s search query into our book database (again, in views.py):<\/p>\n A couple of notes on what we did here:<\/p>\n This is a very simple way to do a book search. I wouldn\u2019t recommend using a simple icontains query on a large production database, as it can be slow. (In the real world, you\u2019d want to use a custom search system of some sort. Search the web for open-source full-text search to get an idea of the possibilities.)<\/p>\n We pass books, a list of Book objects, to the template. To get our new search form working, let\u2019s create the search_results.html file:<\/p>\n Note usage of the pluralize template filter, which outputs an \u201cs\u201d if appropriate, based on the number of books found.<\/p>\n Now, when you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, your search term should return a more useful result below figure.<\/p>\n Improving Our Simple Form-Handling Example<\/strong> - As in previous chapters, I\u2019ve shown you the simplest thing that could possibly work. Now I\u2019ll point out some problems and show you how to improve it. First, our search() view\u2019s handling of an empty query is poor \u2013 we\u2019re just displaying a \u201cPlease submit a search term.\u201d message, requiring the user to hit the browser\u2019s back button. This is horrid and unprofessional, and if you ever actually implement something like this in the wild, your Django privileges will be revoked.<\/p>\n It would be much better to redisplay the form, with an error above it, so that the user can try again immediately. The easiest way to do that would be to render the template again, like this:<\/p>\n Note that I\u2019ve included search_form() here so you can see both views in one place. Here, we\u2019ve improved search() to render the search_form.html template again, if the query is empty. And because we need to display an error message in that template, we pass a template variable. Now we can edit search_form.html to check for the error variable:<\/span><\/p>\n We can still use this template from our original view, search_form(), because search_form() doesn\u2019t pass error to the template \u2013 so the error message won\u2019t show up in that case (Figure 6-4).<\/p>\n With this change in place, it\u2019s a better application, but it now begs the question: is a dedicated search_form() view really necessary? As it stands, a request to the URL \/search\/ (without any GET parameters) will display the empty form (but with an error). We can remove the search_form() view, along with its associated URLpattern, as long as we change search() to hide the error message when somebody visits \/search\/ with no GET parameters:<\/p>\n def search(request): In this updated view, if a user visits \/search\/ with no GET parameters, they\u2019ll see the search form with no error message. If a user submits the form with an empty value for 'q', they\u2019ll see the search form with an error message. And, finally, if a user submits the form with a non-empty value for 'q', they\u2019ll see the search results.<\/p>\n We can make one final improvement to this application, to remove a bit of redundancy. Now that we\u2019ve rolled the two views and URLs into one and \/search\/ handles both search-form display and result display, the HTML <form> in search_form.html doesn\u2019t have to hard-code a URL. Instead of this:<\/p>\n It can be changed to this:<\/p>\n The action=\"\" means \u201cSubmit the form to the same URL as the current page.\u201d With this change in place, you won\u2019t have to remember to change the action if you ever hook the search() view to another URL.<\/p>\n, views.search_form),\nurl(r'^search\/\n Query String Parameters<\/strong> - Because GET data is passed in the query string (e.g., \/search\/?q=django), you can use request.GET to access query string variables. In introduction of Django\u2019s URLconf system, I compared Django\u2019s pretty URLs to more traditional PHP\/Java URLs such as \/time\/plus?hours=3 and said I\u2019d show you how to do the latter.<\/p>\n Now you know how to access query string parameters in your views (like hours=3 in this example) \u2013 use request.GET. POST data works the same way as GET data \u2013 just use request.POST instead of request.GET. What\u2019s the difference between GET and POST?<\/p>\n Use GET when the act of submitting the form is just a request to \u201cget\u201d data. Use POST whenever the act of submitting the form will have some side effect \u2013 changing data, or sending an e-mail, or something else that\u2019s beyond simple display of data. In our book search example, we\u2019re using GET because the query doesn\u2019t change any data on our server.<\/p>\n Now that we\u2019ve verified request.GET is being passed in properly, let\u2019s hook the user\u2019s search query into our book database (again, in views.py):<\/p>\n A couple of notes on what we did here:<\/p>\n This is a very simple way to do a book search. I wouldn\u2019t recommend using a simple icontains query on a large production database, as it can be slow. (In the real world, you\u2019d want to use a custom search system of some sort. Search the web for open-source full-text search to get an idea of the possibilities.)<\/p>\n We pass books, a list of Book objects, to the template. To get our new search form working, let\u2019s create the search_results.html file:<\/p>\n Note usage of the pluralize template filter, which outputs an \u201cs\u201d if appropriate, based on the number of books found.<\/p>\n Now, when you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, your search term should return a more useful result below figure.<\/p>\n Improving Our Simple Form-Handling Example<\/strong> - As in previous chapters, I\u2019ve shown you the simplest thing that could possibly work. Now I\u2019ll point out some problems and show you how to improve it. First, our search() view\u2019s handling of an empty query is poor \u2013 we\u2019re just displaying a \u201cPlease submit a search term.\u201d message, requiring the user to hit the browser\u2019s back button. This is horrid and unprofessional, and if you ever actually implement something like this in the wild, your Django privileges will be revoked.<\/p>\n It would be much better to redisplay the form, with an error above it, so that the user can try again immediately. The easiest way to do that would be to render the template again, like this:<\/p>\n Note that I\u2019ve included search_form() here so you can see both views in one place. Here, we\u2019ve improved search() to render the search_form.html template again, if the query is empty. And because we need to display an error message in that template, we pass a template variable. Now we can edit search_form.html to check for the error variable:<\/span><\/p>\n We can still use this template from our original view, search_form(), because search_form() doesn\u2019t pass error to the template \u2013 so the error message won\u2019t show up in that case (Figure 6-4).<\/p>\n With this change in place, it\u2019s a better application, but it now begs the question: is a dedicated search_form() view really necessary? As it stands, a request to the URL \/search\/ (without any GET parameters) will display the empty form (but with an error). We can remove the search_form() view, along with its associated URLpattern, as long as we change search() to hide the error message when somebody visits \/search\/ with no GET parameters:<\/p>\n def search(request): In this updated view, if a user visits \/search\/ with no GET parameters, they\u2019ll see the search form with no error message. If a user submits the form with an empty value for 'q', they\u2019ll see the search form with an error message. And, finally, if a user submits the form with a non-empty value for 'q', they\u2019ll see the search results.<\/p>\n We can make one final improvement to this application, to remove a bit of redundancy. Now that we\u2019ve rolled the two views and URLs into one and \/search\/ handles both search-form display and result display, the HTML <form> in search_form.html doesn\u2019t have to hard-code a URL. Instead of this:<\/p>\n It can be changed to this:<\/p>\n The action=\"\" means \u201cSubmit the form to the same URL as the current page.\u201d With this change in place, you won\u2019t have to remember to change the action if you ever hook the search() view to another URL.<\/p>\n, views.search_form),\n]<\/pre>\n (Note that we\u2019re importing the views module directly, instead of something like from books.views import search_form, because the former is less verbose.<\/p>\n One last thing \u2013 when Django searches for URL patterns, it will only search the base mysite\\urls.py file, unless we explicitly include the URL patterns from other apps. So let\u2019s go ahead and modify our site urlpatterns:<\/p>\n This new URL pattern must be added to the end of the urlpatterns list. This is because the r’^’ regex sends everything to books.urls, so we want to make sure none of the other patterns match, before sending Django to check books\\urls.py for a matching pattern.<\/p>\n Now, if you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, you\u2019ll see the search interface (Figure 6.1). Simple enough.<\/p>\n Try submitting the form, though, and you\u2019ll get a Django 404 error. The form points to the URL \/search\/, which hasn\u2019t yet been implemented. Let\u2019s fix that with a second view function:<\/p>\n Query String Parameters<\/strong> – Because GET data is passed in the query string (e.g., \/search\/?q=django), you can use request.GET to access query string variables. In introduction of Django\u2019s URLconf system, I compared Django\u2019s pretty URLs to more traditional PHP\/Java URLs such as \/time\/plus?hours=3 and said I\u2019d show you how to do the latter.<\/p>\n Now you know how to access query string parameters in your views (like hours=3 in this example) \u2013 use request.GET. POST data works the same way as GET data \u2013 just use request.POST instead of request.GET. What\u2019s the difference between GET and POST?<\/p>\n Use GET when the act of submitting the form is just a request to \u201cget\u201d data. Use POST whenever the act of submitting the form will have some side effect \u2013 changing data, or sending an e-mail, or something else that\u2019s beyond simple display of data. In our book search example, we\u2019re using GET because the query doesn\u2019t change any data on our server.<\/p>\n Now that we\u2019ve verified request.GET is being passed in properly, let\u2019s hook the user\u2019s search query into our book database (again, in views.py):<\/p>\n A couple of notes on what we did here:<\/p>\n This is a very simple way to do a book search. I wouldn\u2019t recommend using a simple icontains query on a large production database, as it can be slow. (In the real world, you\u2019d want to use a custom search system of some sort. Search the web for open-source full-text search to get an idea of the possibilities.)<\/p>\n We pass books, a list of Book objects, to the template. To get our new search form working, let\u2019s create the search_results.html file:<\/p>\n Note usage of the pluralize template filter, which outputs an \u201cs\u201d if appropriate, based on the number of books found.<\/p>\n Now, when you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, your search term should return a more useful result below figure.<\/p>\n Improving Our Simple Form-Handling Example<\/strong> – As in previous chapters, I\u2019ve shown you the simplest thing that could possibly work. Now I\u2019ll point out some problems and show you how to improve it. First, our search() view\u2019s handling of an empty query is poor \u2013 we\u2019re just displaying a \u201cPlease submit a search term.\u201d message, requiring the user to hit the browser\u2019s back button. This is horrid and unprofessional, and if you ever actually implement something like this in the wild, your Django privileges will be revoked.<\/p>\n It would be much better to redisplay the form, with an error above it, so that the user can try again immediately. The easiest way to do that would be to render the template again, like this:<\/p>\n Note that I\u2019ve included search_form() here so you can see both views in one place. Here, we\u2019ve improved search() to render the search_form.html template again, if the query is empty. And because we need to display an error message in that template, we pass a template variable. Now we can edit search_form.html to check for the error variable:<\/span><\/p>\n We can still use this template from our original view, search_form(), because search_form() doesn\u2019t pass error to the template \u2013 so the error message won\u2019t show up in that case (Figure 6-4).<\/p>\n With this change in place, it\u2019s a better application, but it now begs the question: is a dedicated search_form() view really necessary? As it stands, a request to the URL \/search\/ (without any GET parameters) will display the empty form (but with an error). We can remove the search_form() view, along with its associated URLpattern, as long as we change search() to hide the error message when somebody visits \/search\/ with no GET parameters:<\/p>\n def search(request): In this updated view, if a user visits \/search\/ with no GET parameters, they\u2019ll see the search form with no error message. If a user submits the form with an empty value for ‘q’, they\u2019ll see the search form with an error message. And, finally, if a user submits the form with a non-empty value for ‘q’, they\u2019ll see the search results.<\/p>\n We can make one final improvement to this application, to remove a bit of redundancy. Now that we\u2019ve rolled the two views and URLs into one and \/search\/ handles both search-form display and result display, the HTML <form> in search_form.html doesn\u2019t have to hard-code a URL. Instead of this:<\/p>\n It can be changed to this:<\/p>\n The action=”” means \u201cSubmit the form to the same URL as the current page.\u201d With this change in place, you won\u2019t have to remember to change the action if you ever hook the search() view to another URL.<\/p>\n, views.search),\n]\n\n# books\/views.py\n\nfrom django.http import HttpResponse\n\n# …\n\ndef search(request):\nif ‘q’ in request.GET:\nmessage = ‘You searched for: %r’ % request.GET[‘q’]\nelse:\nmessage = ‘You submitted an empty form.’\nreturn HttpResponse(message)\n\nFor the moment, this merely displays the user\u2019s search term, so we can make sure the data is being submitted to\n Django properly, and so you can get a feel for how the search term flows through the system\n (Figure 6-2).\n\n Query String Parameters<\/strong> – Because GET data is passed in the query string (e.g., \/search\/?q=django), you can use request.GET to access query string variables. In introduction of Django\u2019s URLconf system, I compared Django\u2019s pretty URLs to more traditional PHP\/Java URLs such as \/time\/plus?hours=3 and said I\u2019d show you how to do the latter.<\/p>\n Now you know how to access query string parameters in your views (like hours=3 in this example) \u2013 use request.GET. POST data works the same way as GET data \u2013 just use request.POST instead of request.GET. What\u2019s the difference between GET and POST?<\/p>\n Use GET when the act of submitting the form is just a request to \u201cget\u201d data. Use POST whenever the act of submitting the form will have some side effect \u2013 changing data, or sending an e-mail, or something else that\u2019s beyond simple display of data. In our book search example, we\u2019re using GET because the query doesn\u2019t change any data on our server.<\/p>\n Now that we\u2019ve verified request.GET is being passed in properly, let\u2019s hook the user\u2019s search query into our book database (again, in views.py):<\/p>\n A couple of notes on what we did here:<\/p>\n This is a very simple way to do a book search. I wouldn\u2019t recommend using a simple icontains query on a large production database, as it can be slow. (In the real world, you\u2019d want to use a custom search system of some sort. Search the web for open-source full-text search to get an idea of the possibilities.)<\/p>\n We pass books, a list of Book objects, to the template. To get our new search form working, let\u2019s create the search_results.html file:<\/p>\n Note usage of the pluralize template filter, which outputs an \u201cs\u201d if appropriate, based on the number of books found.<\/p>\n Now, when you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, your search term should return a more useful result below figure.<\/p>\n Improving Our Simple Form-Handling Example<\/strong> – As in previous chapters, I\u2019ve shown you the simplest thing that could possibly work. Now I\u2019ll point out some problems and show you how to improve it. First, our search() view\u2019s handling of an empty query is poor \u2013 we\u2019re just displaying a \u201cPlease submit a search term.\u201d message, requiring the user to hit the browser\u2019s back button. This is horrid and unprofessional, and if you ever actually implement something like this in the wild, your Django privileges will be revoked.<\/p>\n It would be much better to redisplay the form, with an error above it, so that the user can try again immediately. The easiest way to do that would be to render the template again, like this:<\/p>\n Note that I\u2019ve included search_form() here so you can see both views in one place. Here, we\u2019ve improved search() to render the search_form.html template again, if the query is empty. And because we need to display an error message in that template, we pass a template variable. Now we can edit search_form.html to check for the error variable:<\/span><\/p>\n We can still use this template from our original view, search_form(), because search_form() doesn\u2019t pass error to the template \u2013 so the error message won\u2019t show up in that case (Figure 6-4).<\/p>\n With this change in place, it\u2019s a better application, but it now begs the question: is a dedicated search_form() view really necessary? As it stands, a request to the URL \/search\/ (without any GET parameters) will display the empty form (but with an error). We can remove the search_form() view, along with its associated URLpattern, as long as we change search() to hide the error message when somebody visits \/search\/ with no GET parameters:<\/p>\n def search(request): In this updated view, if a user visits \/search\/ with no GET parameters, they\u2019ll see the search form with no error message. If a user submits the form with an empty value for ‘q’, they\u2019ll see the search form with an error message. And, finally, if a user submits the form with a non-empty value for ‘q’, they\u2019ll see the search results.<\/p>\n We can make one final improvement to this application, to remove a bit of redundancy. Now that we\u2019ve rolled the two views and URLs into one and \/search\/ handles both search-form display and result display, the HTML <form> in search_form.html doesn\u2019t have to hard-code a URL. Instead of this:<\/p>\n It can be changed to this:<\/p>\n The action=”” means \u201cSubmit the form to the same URL as the current page.\u201d With this change in place, you won\u2019t have to remember to change the action if you ever hook the search() view to another URL.<\/p>\n, views.search_form),\n]\n (Note that we\u2019re importing the views module directly, instead of something like from books.views import search_form, because the former is less verbose.<\/p>\n One last thing \u2013 when Django searches for URL patterns, it will only search the base mysite\\urls.py file, unless we explicitly include the URL patterns from other apps. So let\u2019s go ahead and modify our site urlpatterns:<\/p>\n This new URL pattern must be added to the end of the urlpatterns list. This is because the r’^’ regex sends everything to books.urls, so we want to make sure none of the other patterns match, before sending Django to check books\\urls.py for a matching pattern.<\/p>\n Now, if you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, you\u2019ll see the search interface (Figure 6.1). Simple enough.<\/p>\n Try submitting the form, though, and you\u2019ll get a Django 404 error. The form points to the URL \/search\/, which hasn\u2019t yet been implemented. Let\u2019s fix that with a second view function:<\/p>\n Query String Parameters<\/strong> – Because GET data is passed in the query string (e.g., \/search\/?q=django), you can use request.GET to access query string variables. In introduction of Django\u2019s URLconf system, I compared Django\u2019s pretty URLs to more traditional PHP\/Java URLs such as \/time\/plus?hours=3 and said I\u2019d show you how to do the latter.<\/p>\n Now you know how to access query string parameters in your views (like hours=3 in this example) \u2013 use request.GET. POST data works the same way as GET data \u2013 just use request.POST instead of request.GET. What\u2019s the difference between GET and POST?<\/p>\n Use GET when the act of submitting the form is just a request to \u201cget\u201d data. Use POST whenever the act of submitting the form will have some side effect \u2013 changing data, or sending an e-mail, or something else that\u2019s beyond simple display of data. In our book search example, we\u2019re using GET because the query doesn\u2019t change any data on our server.<\/p>\n Now that we\u2019ve verified request.GET is being passed in properly, let\u2019s hook the user\u2019s search query into our book database (again, in views.py):<\/p>\n A couple of notes on what we did here:<\/p>\n This is a very simple way to do a book search. I wouldn\u2019t recommend using a simple icontains query on a large production database, as it can be slow. (In the real world, you\u2019d want to use a custom search system of some sort. Search the web for open-source full-text search to get an idea of the possibilities.)<\/p>\n We pass books, a list of Book objects, to the template. To get our new search form working, let\u2019s create the search_results.html file:<\/p>\n Note usage of the pluralize template filter, which outputs an \u201cs\u201d if appropriate, based on the number of books found.<\/p>\n Now, when you run the development server and visit http:\/\/127.0.0.1:8000\/search-form\/, your search term should return a more useful result below figure.<\/p>\n Improving Our Simple Form-Handling Example<\/strong> – As in previous chapters, I\u2019ve shown you the simplest thing that could possibly work. Now I\u2019ll point out some problems and show you how to improve it. First, our search() view\u2019s handling of an empty query is poor \u2013 we\u2019re just displaying a \u201cPlease submit a search term.\u201d message, requiring the user to hit the browser\u2019s back button. This is horrid and unprofessional, and if you ever actually implement something like this in the wild, your Django privileges will be revoked.<\/p>\n It would be much better to redisplay the form, with an error above it, so that the user can try again immediately. The easiest way to do that would be to render the template again, like this:<\/p>\n Note that I\u2019ve included search_form() here so you can see both views in one place. Here, we\u2019ve improved search() to render the search_form.html template again, if the query is empty. And because we need to display an error message in that template, we pass a template variable. Now we can edit search_form.html to check for the error variable:<\/span><\/p>\n We can still use this template from our original view, search_form(), because search_form() doesn\u2019t pass error to the template \u2013 so the error message won\u2019t show up in that case (Figure 6-4).<\/p>\n With this change in place, it\u2019s a better application, but it now begs the question: is a dedicated search_form() view really necessary? As it stands, a request to the URL \/search\/ (without any GET parameters) will display the empty form (but with an error). We can remove the search_form() view, along with its associated URLpattern, as long as we change search() to hide the error message when somebody visits \/search\/ with no GET parameters:<\/p>\n def search(request): In this updated view, if a user visits \/search\/ with no GET parameters, they\u2019ll see the search form with no error message. If a user submits the form with an empty value for ‘q’, they\u2019ll see the search form with an error message. And, finally, if a user submits the form with a non-empty value for ‘q’, they\u2019ll see the search results.<\/p>\n We can make one final improvement to this application, to remove a bit of redundancy. Now that we\u2019ve rolled the two views and URLs into one and \/search\/ handles both search-form display and result display, the HTML <form> in search_form.html doesn\u2019t have to hard-code a URL. Instead of this:<\/p>\n It can be changed to this:<\/p>\n The action=”” means \u201cSubmit the form to the same URL as the current page.\u201d With this change in place, you won\u2019t have to remember to change the action if you ever hook the search() view to another URL.<\/p>\n\n\n<form action=\"\/books\/search\/\" method=\"get\"><\/pre>\n
query = request.GET.get('q', '')<\/pre>\n
\nThere\u2019s still no template for this search view, however. This should do the trick:<\/p>\n<!DOCTYPE HTML PUBLIC \"-\/\/W3C\/\/DTD HTML 4.01\/\/EN\">\n<html lang=\"en\">\n<head>\n<title>Search{% if query %} Results{% endif %}<\/title>\n<\/head>\n<body>\n<h1>Search<\/h1>\n<form action=\".\" method=\"GET\">\n<label for=\"q\">Search: <\/label>\n<input type=\"text\" name=\"q\" value=\"{{ query|escape }}\">\n<input type=\"submit\" value=\"Search\">\n<\/form>\n\n{% if query %}\n<h2>Results for \"{{ query|escape }}\":<\/h2>\n\n{% if results %}\n<ul>\n{% for book in results %}\n<li>{{ book|escape }}<\/l1>\n{% endfor %}\n<\/ul>\n{% else %}\n<p>No books found<\/p>\n{% endif %}\n{% endif %}\n<\/body>\n<\/html><\/pre>\nHTML Forms<\/h3>\n
Getting Data from the Request Object<\/h3>\n
from django.http import HttpResponse\n\ndef hello(request):\nreturn HttpResponse(\"Hello world\")<\/pre>\n
\nInformation About the URL
\nHttpRequest objects contain several pieces of information about the currently requested URL.<\/p>\n\n\n
\n Attribute\/method <\/strong><\/td>\n Description <\/strong><\/td>\n Example<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n request.path<\/td>\n The full path, not including the domain but including the leading slash.<\/td>\n \u201c\/hello\/\u201c<\/td>\n<\/tr>\n \n request.get_host()<\/td>\n The host (i.e., the \u201cdomain,\u201d in common parlance).<\/td>\n \u201c127.0.0.1:8000\u201d or \u201cwww.example.com\u201c<\/td>\n<\/tr>\n \n request.get_full_path()<\/td>\n The path, plus a query string (if available).<\/td>\n \u201c\/hello\/?print=true\u201c<\/td>\n<\/tr>\n \n request.is_secure()<\/td>\n True if the request was made via HTTPS. Otherwise, False.<\/td>\n True or False<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n # BAD!\ndef current_url_view_bad(request):\nreturn HttpResponse(\"Welcome to the page at \/current\/\")\n\n# GOOD\ndef current_url_view_good(request):\nreturn HttpResponse(\"Welcome to the page at %s\"\n% request.path)\n\n<\/pre>\n
Other Information About the Request<\/span><\/h3>\n
\n
# BAD!\ndef ua_display_bad(request):\nua = request.META['HTTP_USER_AGENT'] # Might raise KeyError!\nreturn HttpResponse(\"Your browser is %s\" % ua)\n\n# GOOD (VERSION 1)\ndef ua_display_good1(request):\ntry:\nua = request.META['HTTP_USER_AGENT']\nexcept KeyError:\nua = 'unknown'\nreturn HttpResponse(\"Your browser is %s\" % ua)\n\n# GOOD (VERSION 2)\ndef ua_display_good2(request):\nua = request.META.get('HTTP_USER_AGENT', 'unknown')\nreturn HttpResponse(\"Your browser is %s\" % ua)\n\nI encourage you to write a small view that displays all of the request.META data so you can get to know what\u2019s in there. Here\u2019s what that view might look like:\n\ndef display_meta(request):\nvalues = request.META \nhtml = []\nfor k in sorted(values):\nhtml.append('<tr><td>%s<\/td><td>%s<\/td><\/tr>' % (k, values[k]))\nreturn HttpResponse('<table>%s<\/table>' % '\\n'.join(html))<\/pre>\nInformation About Submitted Data<\/h3>\n
A Simple Django Form-Handling Example<\/h3>\n
# \\books\\views.py\n\nfrom django.shortcuts import render\n\ndef search_form(request):\nreturn render(request, 'books\/search_form.html')<\/pre>\n
# mysite_project\\mysite\\books\\templates\\books\\search_form.html\n\n<html>\n<head>\n<title>Search<\/title>\n<\/head>\n<body>\n<form action=\"\/search\/\" method=\"get\">\n<input type=\"text\" name=\"q\">\n<input type=\"submit\" value=\"Search\">\n<\/form>\n<\/body>\n<\/html><\/pre>\n
# mysite\\books\\urls.py\n\nfrom django.conf.urls import url\nfrom books import views\n\nurlpatterns = [\nurl(r'^search-form\/\n
# mysite\\urls.py\n\nfrom django.conf.urls import include, url\n\nurlpatterns = [\n# ...\nurl(r'^', include('books.urls')),\n]<\/pre>\n![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/25-1.jpg\")
<\/p>\n# books\/urls.py\n\nurlpatterns = [\nurl(r'^search-form\/\n
\n
# BAD!\ndef bad_search(request):\n# The following line will raise KeyError if 'q' hasn't been submitted!\nmessage = 'You searched for: %r' % request.GET['q']\nreturn HttpResponse(message)<\/pre>\n
from django.http import HttpResponse\nfrom django.shortcuts import render\nfrom books.models import Book\n\ndef search(request):\nif 'q' in request.GET and request.GET['q']:\nq = request.GET['q']\nbooks = Book.objects.filter(title__icontains=q)\nreturn render(request, 'books\/search_results.html',\n{'books': books, 'query': q})\nelse:\nreturn HttpResponse('Please submit a search term.')<\/pre>\n\n
# \\books\\templates\\books\\search_results.html\n\n<html> \n<head> \n<title>Book Search<\/title> \n<\/head> \n<body> \n<p>You searched for: <strong>{{ query }}<\/strong><\/p>\n\n{% if books %} \n<p>Found {{ books|length }} book{{ books|pluralize }}.<\/p>\n<ul> \n{% for book in books %} \n<li>{{ book.title }}<\/li> \n{% endfor %} \n<\/ul> \n{% else %} \n<p>No books matched your search criteria.<\/p> \n{% endif %} \n<\/body>\n<\/html><\/pre>\n![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/27.jpg\")
<\/p>\nfrom django.shortcuts import render\nfrom django.http import HttpResponse\nfrom books.models import Book\n\ndef search_form(request):\nreturn render(request, 'books\/search_form.html')\n\ndef search(request):\nerror = False\nif 'q' in request.GET:\nq = request.GET['q']\nif not q:\nerror = True\nelse:\nbooks = Book.objects.filter(title__icontains=q)\nreturn render(request, 'books\/search_results.html', {'books': books, 'query': q})\nreturn render(request, 'books\/search_form.html', {'error': error})\n\n\n<\/pre>\n<html>\n<head>\n<title>Search<\/title>\n<\/head>\n<body>\n{% if error %}\n<p style=\"color: red;\">Please submit a search term.<\/p>\n{% endif %}\n<form action=\"\/search\/\" method=\"get\">\n<input type=\"text\" name=\"q\">\n<input type=\"submit\" value=\"Search\">\n<\/form>\n<\/body>\n<\/html><\/pre>\n![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/29.jpg\")
<\/p>\n
\nerror = False
\nif 'q' in request.GET:
\nq = request.GET['q']\nif not q:
\nerror = True
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, 'books\/search_results.html', {'books': books, 'query': q})
\nreturn render(request, 'books\/search_form.html', {'error': error})<\/p>\n<form action=\"\/search\/\" method=\"get\"><\/pre>\n
<form action=\"\" method=\"get\"><\/pre>\n
<\/pre>\n
<\/p>\n<\/pre>\n
\n
<\/pre>\n
<\/pre>\n
\n
<\/pre>\n
<\/p>\n<\/pre>\n
<\/pre>\n
<\/p>\n
\nerror = False
\nif 'q' in request.GET:
\nq = request.GET['q']\nif not q:
\nerror = True
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, 'books\/search_results.html', {'books': books, 'query': q})
\nreturn render(request, 'books\/search_form.html', {'error': error})<\/p>\n<\/pre>\n
<\/pre>\n
\n
<\/pre>\n
<\/pre>\n
\n
<\/pre>\n
<\/p>\n<\/pre>\n
<\/pre>\n
<\/p>\n
\nerror = False
\nif 'q' in request.GET:
\nq = request.GET['q']\nif not q:
\nerror = True
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, 'books\/search_results.html', {'books': books, 'query': q})
\nreturn render(request, 'books\/search_form.html', {'error': error})<\/p>\n<\/pre>\n
<\/pre>\n
<\/pre>\n
<\/p>\n<\/pre>\n
\n
<\/pre>\n
<\/pre>\n
\n
<\/pre>\n
<\/p>\n<\/pre>\n
<\/pre>\n
<\/p>\n
\nerror = False
\nif ‘q’ in request.GET:
\nq = request.GET[‘q’]\nif not q:
\nerror = True
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, ‘books\/search_results.html’, {‘books’: books, ‘query’: q})
\nreturn render(request, ‘books\/search_form.html’, {‘error’: error})<\/p>\n<\/pre>\n
<\/pre>\n
![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/30.jpg\")
\nin short<\/span>\n\n
<\/pre>\n
<\/pre>\n
\n
<\/pre>\n
<\/p>\n<\/pre>\n
<\/pre>\n
<\/p>\n
\nerror = False
\nif ‘q’ in request.GET:
\nq = request.GET[‘q’]\nif not q:
\nerror = True
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, ‘books\/search_results.html’, {‘books’: books, ‘query’: q})
\nreturn render(request, ‘books\/search_form.html’, {‘error’: error})<\/p>\n<\/pre>\n
<\/pre>\n
<\/pre>\n
<\/p>\n<\/pre>\n
\n
<\/pre>\n
<\/pre>\n
\n
<\/pre>\n
<\/p>\n<\/pre>\n
<\/pre>\n
<\/p>\n
\nerror = False
\nif ‘q’ in request.GET:
\nq = request.GET[‘q’]\nif not q:
\nerror = True
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, ‘books\/search_results.html’, {‘books’: books, ‘query’: q})
\nreturn render(request, ‘books\/search_form.html’, {‘error’: error})<\/p>\n<\/pre>\n
<\/pre>\n