Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.583 materiais280.005 seguidores
Pré-visualização50 páginas
file and find the value named MEDIA_URL, which should be set to an empty 
string. Update the value to reflect the location of your static media: 
MEDIA_URL = '/static/' 
Now, anywhere in your code that you\u2019d like to use these values, you can simply import your settings 
file and call them by name. 
Because our page title and meta tag functions need to be available to our entire project, we\u2019re going to 
create an app that all of our views can use. Create an app in your project called utils. Before we continue, 
make sure that you add this new utils app to your file, under the INSTALLED_APPS section: 
 In our views, we\u2019re going to set up a list of links to our category pages on the sidebar. This 
information is going to be made available to every page, and there\u2019s no reason we need to call it in every 
last one of view functions. There is other information you might want access to as well, such as a default 
page title, or the name of our site. Django handles this dilemma of making some information available to 
all pages with something called context processors. 
Your project already has some context processors installed by default, but you won\u2019t find them in 
your file. To have a look under the hood and see what\u2019s going on here, you need to open 
your file. This file should be in the Django installation directory wherever on your 
system Python is installed, which might vary based on your OS. Under your Python installation, you can 
find it under site-packages/django/conf. 
Don\u2019t feel like looking it up right now? That\u2019s okay. I\u2019ve copied the comments and code out of that 
section and put them here: 
# List of processors used by RequestContext to populate the context. 
# Each one should be a callable that takes the request object as its 
# only parameter and returns a dictionary to add to the context. 
In order to create a valid context processor, you merely need to create a function that, just like a 
view, takes an HttpRequest object, and return a Python dictionary with all the information you need 
available to your templates. When you return a template at the end of any view function, you have the 
option of passing in a RequestContext, which is a glorified set of default variables that you can use in 
your templates. 
Create a new file called inside your utils app directory, and add the 
following code to it: 
from ecomstore.catalog.models import Category 
from ecomstore import settings 
def ecomstore(request): 
 return { 
 'active_categories': Category.objects.filter(is_active=True), 
 'site_name': settings.SITE_NAME, 
 'meta_keywords': settings.META_KEYWORDS, 
 'meta_description': settings.META_DESCRIPTION, 
 'request': request 
Now, you just need to make this particular context processor available to your project. To keep 
things simple, copy the TEMPLATE_CONTEXT_PROCESSORS section out of your file 
and paste it somewhere inside your project\u2019s file, along with the new line for our new 
context processor function: 
With this in place, you can create views that pass in the RequestContext object, and they will have 
access to all of the variables you specify in your ecomstore() context processor function. We\u2019ve set up 
five default variables here, which will be available to any template to which we pass the default 
RequestContext object, which we\u2019ll see in a moment when we code our views. 
Have a look back at the template we created in Chapter 2 called base.html. Look at the three tags in 
the header section. As you can see, the template checks for three variables called page_title, 
meta_keywords, and meta_description. If these are not supplied by our view functions (which we\u2019re 
getting to, I swear), then the template falls back on these variables we just set in our function. 
Now, I\u2019m going to confess one thing here: if you look back at the code that sets the variables, the list 
of active categories really doesn\u2019t belong there. The list itself is going to end up in the side column on 
every page of the site. Ideally, any database calls we make should be encapsulated in that one part of the 
site, and not everywhere, like our site name needs to be. Don\u2019t worry\u2026 in the next chapter, when we 
learn how to create custom template tags, we\u2019re going to get rid of this kludge. For now, you have a list of 
categories to aid in browsing the site. 
Coding Up the Catalog Views 
So, let\u2019s code our view functions! You may be thinking back to the alphabet soup we talked about earlier: 
MVC. Naturally, since this stands for \u201cmodel-view-controller,\u201d it would make sense for you to assume 
that your Django views are the \u201cview\u201d part of that acronym. This isn\u2019t really the case. In the MVC design 
pattern, the controller is responsible for handling the logic in your application. It talks to your models, 
fetches instances of them, and returns to the views. Your view functions will do this, more than act as 
real \u201cviews\u201d in the MVC sense of the word. 
In fact, as ludicrous as it sounds, your templates are really your view layer, while your view functions 
are more your controller layer. Confused yet? Yes? Well, the good news is, it doesn\u2019t really matter. You 
understanding where in the theoretical MVC pattern each part of your project falls isn\u2019t crucial to you 
getting it built. 
Let\u2019s get down to it. Open the file inside your catalog app directory and enter the 
following import statements and three view functions: 
from django.shortcuts import get_object_or_404, render_to_response 
from ecomstore.catalog.models import Category, Product 
from django.template import RequestContext 
def index(request, template_name="catalog/index.html"): 
 page_title = 'Musical Instruments and Sheet Music for Musicians' 
 return render_to_response(template_name, locals(),\ufffd 
def show_category(request, category_slug, template_name="catalog/category.html"): 
 c = get_object_or_404(Category, slug=category_slug) 
 products = c.product_set.all() 
 page_title = 
 meta_keywords = c.meta_keywords 
 meta_description = c.meta_description
 return render_to_response(template_name, locals(),\ufffd 
def show_product(request, product_slug, template_name="catalog/product.html"): 
 p = get_object_or_404(Product, slug=product_slug) 
 categories = p.categories.filter(is_active=True) 
 page_title = 
 meta_keywords = p.meta_keywords 
 meta_description = p.meta_description 
 return render_to_response(template_name, locals(),\ufffd 
These are the views for the home page, category, and product pages. You\u2019ll see that these functions 
are making good use of the page title and meta tag functions we created in the last section. As you know, 
if any of our products