Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.517 materiais279.343 seguidores
Pré-visualização50 páginas
the regular expression (r'^$'), this is the URL 
entry that matches your home page URL. Because you now have the $ character determining where the 
end of the string is, it will only match a URL that is empty after the 
After this home page match, we then pass it the name of the home page view function: 'index'. 
There\u2019s a little bit of a mystery here. How does our site know where the index() function resides? 
The answer lies in the first line in our catalog file. While this is an empty string in our root 
file, here we\u2019ve specified 'ecomstore.catalog.views'. In effect, this translates to \u201cpreface every URL 
view function we specify with this location in our application.\u201d This means that these three views all 
reside in this file, and instead of having to type out the full location each time, we can just type it once, at 
the beginning of the patterns() function. 
The category regular expression bears a little bit more examination. Sure, there\u2019s still ^ and $ 
characters, but there\u2019s a whole lot of stuff between them: 
(r'^category/(?P<category_slug>[-\w]+)/$', \ufffd 
 'show_category', { 
The syntax of using parentheses that start out with \u201c?P\u201d is the syntax for using a named argument in 
your view function. This tells your application that in this part of the URL, you expect to receive some 
text that should be a category slug. You denote the name of the argument in angled brackets (< >), 
followed by a regular expression that should tell your pattern what kind of content your named 
argument might contain. In this case, [-\w]+ matches any number of letters, numbers, or hyphens\u2026 
exactly the characters your slug field might contain. 
So, navigating to the URL: 
is the same as calling your view function, by hand, like this: 
show_category(request, category_slug=\u201dmy-category-name\u201d, \ufffd 
After passing in the name of the view function (show_category) in your URL entry, there are two 
more arguments here, the likes of which we haven\u2019t seen before. The first one is a dictionary we\u2019re 
passing in, which can contain any view function arguments you want to make available to that particular 
view. We are passing in the name of the template we\u2019re planning to return to the view function, instead 
of hard-coding it in the render_to_response() function. 
The last one is a little strange: 'catalog_category'. What gives? Go back to your category model 
class definition and find the get_absolute_url() function: 
 def get_absolute_url(self): 
 return ('catalog_category', (), { 'category_slug': self.slug }) 
As you can see, the first argument here matches the last mysterious argument back in our URL 
definition. This is mapping the get_absolute_url() function to your file, so that whenever
you call it, it looks up the location of the category in your file. Therefore, if you want to change 
the format of the URL where your categories are located, you would just need to update your 
file and your project will automatically take care of updating all of the hyperlinks on your site (provided, 
of course, that you\u2019re using the get_absolute_url() method). 
The product URL entry is pretty much the same as the category one. Just make you understand how 
the internal plumbing is working, and how get_absolute_url() is determining how to construct its links. 
File Not Found and Custom 404s 
In the last chapter, we briefly covered the template files that are used when your project encounters an 
error. You\u2019ve equipped your project to return 404s when it doesn\u2019t find a category, and while the Django 
default 404.html template would work just fine, let\u2019s set up a custom template so that our \u201cNot Found\u201d 
page is consistent in appearance with the rest of the site. Create a file called in the root of your 
project and enter the following 404 function definition into it: 
from django.shortcuts import render_to_response 
from django.template import RequestContext 
def file_not_found_404(request): 
 page_title = 'Page Not Found' 
 return render_to_response('404.html', locals(),\ufffd 
Now, create a file called 404.html in your templates directory and put the following code into it: 
{% extends &quot;catalog.html&quot; %} 
{% block content %} 
 The page or resource you requested was not found. 
 We apologize for the inconvenience. 
 Please go back and check to make sure you typed in the URL correctly. 
{% endblock %} 
Next, open up the file in the root of your project and, below the urlpatterns variable, put 
the following line of code: 
handler404 = 'ecomstore.views.file_not_found_404' 
Now, when your site encounters a 404, it will return this template you just created. Note that this 
won\u2019t be visible to you, or your site users, until you change the DEBUG variable in your file 
from True to False. Your project assumes that while in development, your project will be in debug 
mode, and that during development you\u2019ll want to read those spiffy and verbose error messages that a 
404 would give you. 
While it may seem unnatural to you at first, you\u2019ll get into a quick flow, in which you\u2019ll create your 
URL, create your view, and then create your templates. Once you\u2019ve gotten into the habit, creating pages 
with Django will go quickly.
So, after all of that delightful coding work, we now have a small e-commerce catalog. We went over the 
basics of model creation, setting up relationships between you models, and learned the very basics about 
database design. We created product and category models, set up the admin interface for each one, added 
a few of each, and got the views, templates, and URLs set up so that users can browse our products. In the 
process, we learned more about how to set up URLs, pass arguments into view functions, and the great 
amount of flexibility that Django templates give you in creating your user interface. 
In the next chapter, we\u2019re going to set up our own custom shopping cart so that users can start 
aggregating our products for eventual checkout.
C H A P T E R 4 
\u25a0 \u25a0 \u25a0 
The Shopping Cart 
Anyone who\u2019s ever done any shopping, either on the Internet or off, understands the concept of a 
shopping cart. It allows customers browsing your products to aggregate some products from your 
catalog and then, once they\u2019ve gotten everything they want to buy, go through the checkout process with 
all the items in their shopping cart. 
In this chapter, we\u2019re going to create a shopping cart on our site, to which users can add the 
products in our catalog. We\u2019re going to create the shopping cart page, where they can review their 
selections, adjust any purchase quantities, or remove any items before beginning the checkout process. 
In doing so, we\u2019ll take a much closer look at the Django templating system and what you can do to 
extend Django\u2019s templating system with your own custom template filters and template tags. 
Shopping Cart Requirements 
Before we get to coding up our shopping cart models and creating our templates, let\u2019s write a quick spec 
outlining the basics of our cart requirements, and talk a little bit about the purpose of sessions. 
I\u2019m going to do a quick write-up to serve as an overview of the functionality that our shopping cart 
requires. Feel free to do your own and remember, yours might end up looking a whole lot different than 
mine for lots of different reasons. The only piece of advice I\u2019m going to give