Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.609 materiais280.238 seguidores
Pré-visualização50 páginas
the top, is a variable called DEBUG. 
You\u2019ll notice that right now, it\u2019s set to True. 
This is one thing you need to change before deploying, and when you do, Django will, among lots of 
other things, display a custom generic \u201cSorry, we encountered an unexpected error!\u201d page to display to 
the users of your site. The two most common errors are the 404 Page Not Found error, which is returned 
when a customer makes a request for a URL that doesn\u2019t exist, and the 500 Internal Server error, which 
occurs if Django raises an exception. The default files that are shown in this case lie in the root templates 
folder of the Django source, and are aptly named 404.html and 500.html. 
Ensuring that DEBUG is set to True is good for security, as these generic template files prevent your 
users from easily finding out that you\u2019re using Django, or reading the traceback of your site\u2019s code that 
potentially gets displayed on an error page in debug mode. However, you need to have this information 
accessible to you somewhere, if for no other reason than to let you know where an exception occurred 
and any details you might need to fix it. This is the reason we\u2019ve taken the trouble to log these errors to 
our database.
One last thing: now that you know how to make a page, you might be tempted to jump in and start 
creating your \u201cPrivacy Policy\u201d or \u201cContact\u201d pages. Hold off on that. There\u2019s a much easier way, using a 
Django app called flatpages, which will help you do this without needing to create a bunch of static 
template files. We\u2019ll come back to that later in the book. 
A Word (or Two) About URLs 
Before we jump into coding our models and adding lots of templates to inherit from our catalog.html 
template, let\u2019s talk about URLs. The creators of Django didn\u2019t like messy URLs in their pages. If you\u2019ve 
ever tried to type in a URL in by hand that looks something like:
then you know just how terrible and unreadable these can be. Django handles the mapping of 
cleaner URLs to its pages in a very simple way. If you\u2019ve ever used Apache\u2019s mod_rewrite7 to make your 
URLs look better, Django has a very similar functionality built in. The only difference is that in Django, 
the mapping is handled at the level of your web application and not by the web server. This is 
particularly useful when you\u2019re dealing with a shared hosting environment, and you\u2019re not allowed to 
tweak the Apache conf files directly. 
Let\u2019s take a quick look at URLs. You added the one line for the /catalog/ page earlier: 
urlpatterns = patterns('', 
 #other commented code here 
 (r'^catalog/$', 'views.home'), 
Each entry in the patterns tuple takes a regular expression and the name of the view function to call 
as its arguments. I sense that some of you might be a little taken aback by the first part. Regular 
expressions? Aren\u2019t those things really hard? And isn\u2019t Django supposed to make things easier on us? 
In response to all three of those questions: yes. Regular expressions are pretty tricky to get the 
hang of. My advice to you is not to worry about it, since most of what you\u2019ll be doing will only involve 
a small handful of regular expression tips and tricks. And for the most part, when a problem arises 
that isn\u2019t covered in this book, a little Googling around for the answer will probably get you what 
you\u2019re looking for. 
We set a lot of important groundwork in this chapter. We created our Django application, configured 
exception logging to our database, and set up a hierarchy of templates for most of our site\u2019s pages. We 
now have a basic site layout and appearance that will act as a simple interface while we set up all of the 
back-end architecture in the next chapter, where we\u2019ll create the product catalog with a category 
structure and even some stuff customers can browse. 
In the next chapter, we\u2019re going to put our database to good use, and create categories and 
products. Then we\u2019ll really sink our teeth into creating content for our site by creating their 
corresponding pages.
C H A P T E R 3 
\u25a0 \u25a0 \u25a0 
Models for Sale 
Imagine walking into your favorite traditional brick and mortar store. It may be a book store, a retail 
clothing outlet, or perhaps even a music shop that sells CDs. You know what to expect when you walk in 
the door; you probably plan to turn and go right to one particular section that has the goods you want to 
peruse. But, imagine that when you first enter the store, you notice something very askew: all of the 
shelves are empty. There are no products anywhere in sight. 
Since you really like this store, you\u2019re very curious about what\u2019s going on, so you walk over to the 
purveyor and ask them: what gives? Where\u2019d all of their stuff go? 
To which the owner of the store replies: \u201cIt\u2019s in the back room. Due to technical difficulties, I can\u2019t 
let you look at it right now.\u201d And, after a long hearty laugh at this absurd response, most of us would 
probably let our feet do the talking and leave pretty quickly. 
Regardless of what kind of e-commerce store you\u2019re creating, and what type of product you want to 
sell online, there is one fundamental truth you need to get your brain wrapped around: the importance 
of your data. You might have a massive warehouse filled with products that are ready to move and make 
you a hefty profit margin, but when it comes to selling, you need to give your customers access to your 
products. In the offline retail world, that\u2019s obviously the purpose of a storefront; to allow your customers 
to browse (and purchase) your products. 
In an e-commerce store, your web application is acting like the physical store, but without your 
data, it would be an empty shell. It\u2019s like the imaginary store you just entered in daydream-land with all 
those empty shelves. Your data is the interface that lets your customers find and buy what they want. 
And, like a real store, you have to protect your data just as you would your products because they can be 
mangled, destroyed, or even stolen. (We\u2019ll look at safeguards against the latter threat in this chapter, and 
the others throughout the book.) 
In this chapter, we\u2019re going to set up your database with your product data. This isn\u2019t actually as 
difficult as it may sound. Creating the tables in your database is as easy as writing some basic Python 
classes with the fields you want each table to have and then running a command to create the tables. 
That is one of the beautiful things about Django: the database layer is abstracted away behind Django\u2019s 
object-relational mapper (ORM). This allows you to access data with some very simple Python code that 
will not take you long to write. 
After that, we\u2019ll create our first Django app. A Django app is a block of Django code that performs 
some function, which may be coupled with your project or used across multiple projects. For example, 
one Django app may be created within your project to control the site\u2019s news articles. Your app would 
contain your models for the articles and article categories, as well as the views that control how the 
content is displayed to your users. Once that\u2019s in place, we\u2019ll take a closer look at how the Django admin 
interface greatly reduces the amount of work you need to do in order to start administering your product 
catalog via a web interface. Then, we\u2019ll cover how the data gets from your database to the pages of your 
web site, writing view functions that pull the