Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.583 materiais280.005 seguidores
Pré-visualização50 páginas
fun. We are going to create the product and category models and the database in 
this section, but first, you need to do something else. 
You need to determine what information you need to store about your products.
I could jump right in and start droning on about how you can store strings, numbers, dates, and 
boolean fields (I\u2019ll get to that in a minute, I promise), but before you start thinking about your data in 
terms of data types, the way engineers and DBAs like to do, I want you to put this book down and reflect 
on what you need. 
As mentioned as the start of this chapter, the value of your site to customers hinges on the data. 
That is the logical start for things. Unfortunately, the data hinges on your ability to figure out what data 
you need to track. In terms of your products, you want to think long and hard about the information you 
need your system to have on each product. If you have 200 products that you want to sell on your site at 
launch time, you really don\u2019t want to put in 200 products only to figure out that you\u2019ve forgotten one key 
field, like meta keywords for SEO for each product. You\u2019d then have to go back and add these for each of 
your 200 products. Oops. 
You might have realized that your products require more than just the two tables for categories and 
products that we\u2019re going to create in this book. Forget about how you\u2019re going to normalize your data 
for right now. Forget about relationships. Forget about what the maximum length of your product 
names will be. 
Sure, it\u2019s tough to develop the user interface without your data, and it can be tough to think about 
what your site data needs to be to get the user interface you want. The simplest solution to this 
chicken-and-the-egg nightmare is to forget about your database for right now and focus on the 
product page itself. 
So put down this book and pull up your favorite tool for creating a visual representation of your 
product page. It may be Photoshop, Dreamweaver, or GIMP. Personally, I find that using a piece of 
paper and a pencil is the most efficient way of getting something down quickly, as it allows you to 
quickly make edits. It\u2019s the least intrusive way of letting the creative side of your brain express itself 
because you\u2019re sketching on paper, and you\u2019re not interacting with a computer while you do it. 
Sketching also lets you get the ideas from your head to paper as quickly as possible. It\u2019s important not to 
underestimate just how quickly ideas come to your brain and, on the flip side of the same coin, realize 
how quickly you can lose them. You might be interrupted in the process of creating another Photoshop 
layer, and if you didn\u2019t get that one fabulous idea down, it might be gone forever. 
What we\u2019re doing here is a process that\u2019s sometimes referred to as paper prototyping. While paper 
prototyping generally involves the informal creation of an interface that can be shown to prospective 
users in order to gain feedback on its usability, it has other uses as well. The best thing about 
designing things in this fashion is that it\u2019s quick and easily amenable, in case you don\u2019t get everything 
right the first time. 
I\u2019m going to create a quick sketch of my product page, and I suggest you do the same. Think of a 
product you plan to sell and draw the basic layout, complete with a photo and any other information. 
My only guidance about what you draw is this: think about an e-commerce store where you really liked 
the experience, and try to base it on that. You don\u2019t need to copy it exactly, but try and capture the same 
essence. Just be sure you create something you like, and that you think your customers will like too. 
The results of my sketching can be seen in Figure 3-1.
Figure 3-1. A rough sketch of the content of our site\u2019s product page. 
The point of this exercise is simple: to determine what your database needs to store about its 
products by looking at the front-end first. Database creation is fairly cut and dry, and there\u2019s not a whole 
lot of room for creativity. Taking this approach at least engages you for a little while. 
After you\u2019ve created the sketch, look it over and see what kinds of information it contains. One thing 
you\u2019ll note about mine is that it has a \u201cwas\u201d price and a \u201cnow\u201d price. This is one important detail that we 
might have missed if we hadn\u2019t drawn the sketch; we might have just stored one single price and only 
realized much later, after lots of other work had already been done, that we need to store two prices. (Of 
course, that wouldn\u2019t be a terribly difficult fix...but you\u2019ll want to be thorough.) 
Start to jot down a list of the things you see on the page, and make any additional notes about the 
information you might need. It doesn\u2019t have to be a formal spec... just some free-form, stream-of-
consciousness scribbling will do just fine. It should also include anything you don\u2019t see on your sketch 
that you might need to store, such as meta tag content. 
My list looks something like this: 
\u2022 Name of product 
\u2022 Brand name 
\u2022 Product SKU 
\u2022 Which categories is the product in? 
\u2022 Price 
\u2022 Sale price, plus old price 
\u2022 Product image 
\u2022 Meta description 
\u2022 Meta keywords 
\u2022 Quantity in stock 
\u2022 Date product was created 
\u2022 Date product was last updated 
\u2022 Product status (active or inactive)
This list is simple enough, and thankfully, it\u2019s also very easy to translate this into the Python code 
that will set up our database. Before we get to that, let\u2019s make a quick list going over the required fields 
for our category pages. You\u2019re welcome to a sketch for these pages as well, but I\u2019m just going to create a 
list of items, like our product: 
\u2022 Name of category 
\u2022 Category description 
\u2022 Meta keywords 
\u2022 Meta description 
\u2022 Date category was created 
\u2022 Date category was last updated 
\u2022 Category status (active or inactive) 
Set aside your two lists of data that you want to store, and let\u2019s talk about what your databases can 
store for you. It won\u2019t be that tedious\u2026I promise. 
Model Field Data Types 
Databases can store different types of data in different fields, which fall into four basic categories. The 
first type, and the most important, are strings, or character data. This is the most important data your 
web application will store because search engines like content, and content typically takes the form of 
text. The users shopping on your site will be using text to make buying decisions, and will submit text to 
your site in the form of product reviews that will help other users make decisions as well. Because strings 
are so important, there are a few different kinds of fields you can use to store this data in your relational 
database. The following is a list of field types that store string data, and a brief description of when you 
should use each: 
\u2022 CharField: used to store text that is less than or equal to some determinate 
length. For example, you might determine that your longest product name is 147 
characters long. In that case, you should use a CharField for your product name 
and set its length to be 175 characters or so. 
\u2022 TextField: used to store large amounts of text that you don\u2019t want restricted by 
length. Product descriptions are a perfect example; they may contain any amount 
of descriptive content or HTML for formatting, and you want this. You want to 
provide enough information to your customers so they can make an informed 
decision\u2026 as well as give search engines lots of content to index. 
\u2022 SlugField: a specialized text field that is designed to be used in URLs. When a 
user requests a product page, they\u2019ll access a URL