Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.414 materiais278.198 seguidores
Pré-visualização50 páginas
can control which products show up to the user. This easily gives 
you control over which products you are going to present to your user as soon as they arrive at your site, 
much like you might create a display filled with products in the front window of a retail shop. 
But what about bestsellers? Shouldn\u2019t you just use your order history and actually show people what 
products are actually bestsellers? Sure, you could do this, but there are a couple of problems with that 
approach. First, as your site grows and you start storing more and more order history, querying the order 
tables to determine which products have historically moved the most units will slow things down. A lot. 
That, and if you\u2019re displaying your bestselling products somewhere prominent, like in a side column 
on every page, more users are likely to click on them and purchase them than the non-bestsellers. This 
creates a sort of feedback loop that makes your site\u2019s \u201cbestseller\u201d list very resistant to change, and 
believe me, you\u2019re going to want to change it at some point in the future. Accept that you need to tell this 
small fib to your customers and allow yourself to have more control. Don\u2019t over think it because your 
customers won\u2019t really care, so long as you are offering a list of bestsellers that adds value to their 
experience using your site. 
The last, and by far the most important, piece of code in your Product model is the last field we 
declare before creating the inner Meta class. Have a long, hard look: 
categories = models.ManyToManyField(Category) 
This is the field that defines the relationship between your Product and Category models. 
Remember the discussion earlier about many-to-many relationships, about associating each product 
with many categories, and vice versa? This one line of code is the workhorse that makes all of that 
happen. When you run the script to create your two tables for products and categories, a third table will 
be created to manage and hold the relationships between the two models. This enables you to assign a 
product to as many different categories as you\u2019d like. 
We\u2019ve created the relationship by creating a field that we\u2019re calling categories in our Product 
model, and although this happens to match the name of the categories table we created, bear in mind 
that you can call it whatever you\u2019d like. The name \u201ccategories\u201d was just logical, so I used it. Also, there 
will never be a categories field in the product table in your database. It\u2019s just something you declare in 
the model to set up the relationship. 
One caveat worth pointing out is that the Category model class declaration needs to come before the 
Product model class. You\u2019re passing in \u201cCategory\u201d, the name of your Category model, as an argument to 
the ManyToManyField, and if the Category class comes after this line of code, Django won\u2019t understand 
where this model is coming from, and you\u2019ll get an error when you try to sync up your database. 
The Django Admin Interface 
Now that you have a couple of models to put data in, let\u2019s set up the Django admin interface so that you 
can start adding categories and products! This requires that we do a couple of things. First, we need to 
install the apps that Django requires for us to use the admin interface. Second, we need to create some 
code that informs the admin interface about our models. 
The first item just requires a few small configuration changes to our file. Remember 
those four lines of code that I had you comment out in the last chapter, under the INSTALLED_APPS 
section? We\u2019re going to uncomment those same lines out, as we\u2019re going to need them now. Open the 
file and edit that section, removing the \u2018#\u2019 characters, and add the extra two lines: 
Notice that you\u2019ve added a line specifying your Django catalog app in your project, and another 
line right below that to install the admin interface. The other four that you\u2019ve uncommented out are also 
very necessary to making the admin site work. Since the admin interface is behind a login, we need to 
enable sessions so that you can create a user, and then track their login using a cookie. (We\u2019ll cover 
sessions more in the next chapter.) 
You\u2019ll need to be able to navigate to your admin interface once it\u2019s up and running, and for that, 
you\u2019ll need to make a quick edit to your project\u2019s file. Open it, locate the lines near the top 
related to the admin interface, and uncomment them: 
# Uncomment the next two lines to enable the admin: 
from django.contrib import admin 
Make sure that you also remove the extra space between the hash (#) character and the start of the 
line. Remember, Python is quite moody about indentations! Next, scroll down and uncomment the line 
within your urlpatterns tuple: 
# Uncomment the next line to enable the admin: 
(r'^admin/', include(, 
With these changes made, you just need to tell your Django project about the models you want 
available through the admin interface, which we\u2019re going to do in the next section. 
Product and Category Admins 
Registering your models with the admin site requires us to create a new file, in your catalog app 
directory, called Create this file now, and add the following code to it. We\u2019ll go through this 
code shortly: 
from django.contrib import admin 
from ecomstore.catalog.models import Product, Category 
from ecomstore.catalog.forms import ProductAdminForm 
class ProductAdmin(admin.ModelAdmin): 
 form = ProductAdminForm 
 # sets values for how the admin site lists your products 
 list_display = ('name', 'price', 'old_price', 'created_at', 'updated_at',) 
 list_display_links = ('name',) 
 list_per_page = 50 
 ordering = ['-created_at']
 search_fields = ['name', 'description', 'meta_keywords', 'meta_description'] 
 exclude = ('created_at', 'updated_at',) 
 # sets up slug to be generated from product name 
 prepopulated_fields = {'slug' : ('name',)} 
# registers your product model with the admin site, ProductAdmin) 
class CategoryAdmin(admin.ModelAdmin): 
 #sets up values for how admin site lists categories 
 list_display = ('name', 'created_at', 'updated_at',) 
 list_display_links = ('name',) 
 list_per_page = 20 
 ordering = ['name'] 
 search_fields = ['name', 'description', 'meta_keywords', 'meta_description'] 
 exclude = ('created_at', 'updated_at',) 
 # sets up slug to be generated from category name 
 prepopulated_fields = {'slug' : ('name',)}, CategoryAdmin) 
The code in our file contains two class declarations, one for each model. Each one 
subclasses admin.ModelAdmin, and there is a handful of fields we\u2019ve set on each one. These fields relate 
to customizing the appearance and functionality of the admin interface. We\u2019ll look at each of them 
list_display, list_display_links, list_per_page, ordering, and search_fields all control 
the functionality of the admin interface. The admin interface will create a list of your categories and 
products for you to browse, and here, we\u2019re customizing how they appear in that list. list_display is a 
Python tuple that takes the list of fields you would like to appear on the listing page for each item. 
list_display_links is a tuple that takes a list of fields that you want to be hyperlinks that will take to 
you an \u201cEdit Item\u201d page. list_per_page