Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.666 materiais280.874 seguidores
Pré-visualização50 páginas
have blank title or meta data, our project will fall back on the defaults. Other than 
that, what you\u2019re seeing should make sense. 
We are using another Django shortcut here: get_object_or_404. Typically, if a user enters a URL 
for a product or category slug that doesn\u2019t exist, it will raise a DoesNotExist exception in your Django 
project. We\u2019d much rather pass along an informative and courteous message to the user letting them 
know they\u2019ve tried to access a page that doesn\u2019t exist, by returning a 404 Page Not Found. This is exactly 
what get_object_or_404 does. Pass in the name of one of your model classes, as well as any arguments 
used to look up the particular record you want. If it looks up the given category or product by its slug and 
does not find a match, it will raise a 404 exception that our Django project can use to present a slick 
\u201cPage Not Found\u201d error to the end user. 
We\u2019re also making heavier use of our render_to_response() function in this chapter. We\u2019re 
passing in three arguments instead of just the one. The first is the name of each template, through the 
template_name variable, which we haven\u2019t created yet, but will be coding in the next section. Because 
we\u2019re using a variable name as a keyword argument to our view function, the actual view code itself isn\u2019t 
cluttered up with the name of the template.(save for its inclusion in the view\u2019s list of arguments). 
The second is a function called locals(), which is a useful shortcut when returning a response to 
the user. As the second argument, you could create a dictionary listing all of the variables that your view 
function is passing into the template, such as page_title, c, and so forth. However, this is a lot of typing 
that can get old quickly. The locals() function sucks up all the variables you\u2019ve declared in your 
function, creates a Python dictionary out of them, and makes them available to your template, without 
you needing to explicitly list all of them. 
The last argument passed in is called context_instance. This takes a RequestContext object that 
can contain any variables you might want to pass to multiple pages. As you can see, we\u2019re just passing in 
the RequestContext object created by the ecomstore() function we created in the last section. Any 
view that passes in this RequestContext will have a list of active categories, a site name, default meta 
keywords and description, and the request object variables made available to it. 
Creating the Template Files 
So, now all we need to do to see some pages is create the templates. Let\u2019s make a quick change to our 
base.html file so that we\u2019re using our context variable to set the location of the CSS file. Open it and 
change the link tag in your site\u2019s head to look like this: 
<link rel=&quot;Stylesheet&quot; type=&quot;text/css&quot; href=&quot;{{ MEDIA_URL }}css.css&quot; /> 
Here, you\u2019re updating your page to make use of the MEDIA_URL you entered into your 
file. Now, where is that coming from? We didn\u2019t add it to our context processor function, so how is our
template able to use it? As it turns out, the MEDIA_URL value is already passed to your template, via the 
following context processor: 
So, you can easily change the location of your static content when you deploy, and you won\u2019t lose 
the link to your CSS. 
Now we\u2019re going to create three new ones, to correspond with our three views. We\u2019re interested in 
keeping our application manageable, especially as it gets much larger. Right now, you should only have 
two or three template files in your templates directory, but as you start adding new apps and new 
models, the number of them may start to grow by leaps and bounds. To keep things organized, we\u2019re 
going to adopt a practice of organizing our templates by the app to which they belong. So, create a new 
directory in your templates folder called catalog, and create three new HTML files in it: index.html, 
category.html, and product.html. 
index.html will be the simplest one for us to do, so open that file first and add the following code to it: 
{% extends &quot;catalog.html&quot; %} 
{%block content %} 
<h1>Welcome to Modern Musician!</h1> 
{% endblock %} 
As you can see, we\u2019re merely extending our catalog.html template from the last chapter, and 
adding a very brief welcome header to greet the user. The home page is the most important page on your 
site, since it will give the user an overview of everything your site has to offer, and will help them 
determine whether or not they should stick around. 
For this reason, it\u2019s usually prudent to save the planning of your home page for last, after you\u2019ve 
decided what content your site will include. You might end up adding news articles, a blog, a shopping 
cart, wish lists, user accounts, and so forth. We\u2019ll be adding some of those items, and later come back to 
presenting all of this to the user at the end, when we\u2019ve finished most of our site. For now, since we\u2019re 
not yet live, we can stand to leave a simple welcome message as a placeholder for things to come. 
Next, let\u2019s move on to the category page. Open up category.html and enter the following code: 
{% extends &quot;catalog.html&quot; %} 
{% block content %} 
 <h1>{{ }}</h1> 
 {{ c.description }} 
 <br /><br /> 
 {% for p in products %} 
 <div class=&quot;product_thumbnail&quot;> 
 <a href=&quot;{{ p.get_absolute_url }}&quot;> 
 <img src=&quot;{{ MEDIA_URL }}images/products/thumbnails/{{ p.image 
}}&quot; \ufffd 
 alt=&quot;{{ }}&quot; class=&quot;bn&quot; /> 
 <br /> 
 {{ }} 
 {% endfor %} 
{% endblock %}
As you can see, things are starting to get a little juicier in our templates. This one is pretty clear: we 
have a couple of variables that are displaying information about our categories, and a Django template 
{% for %} loop that runs through our products and displays a thumbnail, with the image, for each one. 
We haven\u2019t set up the image folders quite yet. 
Now, let\u2019s do the category page last. Open your product.html file and enter this code: 
{% extends &quot;catalog.html&quot; %} 
{% block content %} 
 <div class=&quot;product_image&quot; > 
 <img src=&quot;{{ MEDIA_URL }}images/products/main/{{ p.image }}&quot; alt=&quot;{{ 
}}&quot; /> 
 <h1>{{ }}</h1> 
 Brand: <em>{{ p.brand }}</em> 
 <br /><br /> 
 SKU: {{ p.sku }} 
 <br /> 
 In categor{{ categories.count|pluralize:&quot;y,ies&quot; }}: 
 {% for c in categories %} 
 <a href=&quot;{{ c.get_absolute_url }}&quot;>{{ }}</a> 
 {% if not forloop.last %}, {% endif %} 
 {% endfor %} 
 <br /><br /> 
 {% if p.sale_price %} 
 Was: <del>$ {{ p.old_price }}</del> 
 <br /> 
 Now: $ {{ p.price }} 
 {% else %} 
 Price: $ {{ p.price }} 
 {% endif %} 
 <br /><br /> 
 [add to cart button] 
 <br /><br /> 
 <div class=&quot;cb&quot;><br /><br /></div> 
 <h3>Product Description</h3> 
 {{ p.description }} 
{% endblock %} 
There\u2019s a little bit more going on here. We\u2019re using a few template variables, some if blocks, and a 
couple other things you might not have seen before. Below the product name, we\u2019re listing as links the 
categories that the product is in. We\u2019re basing the appearance of our \u201cIn categories\u201d text by using a Django 
template filter. Filters let you format the output of variables at the point you display them in the page. 
For example, let\u2019s say you have a variable supplied by a site user that could potentially contain 
malicious JavaScript that could make your site vulnerable to Cross-Site Scripting attacks. You can use a 
template filter