This chapter is from the book
This chapter is from the book
This chapter is from the book
1.6 Defining the Project in Part I
The purpose of Django Unleashed is to teach Django by example. The goal of Part I of this book is to teach you the core fundamentals of Django, the parts of the system required by every website, and how MVC (mostly) applies to that system. To accomplish these tasks, we begin building a website that is self-contained to Django: we purposefully avoid any external libraries built for Django in order to better focus on the framework itself. At each step of the building process, you are introduced to a new Django feature, providing insight into the framework. By the end of Part I, these insights will allow you to see exactly how Django operates and adheres to MVC. Note that the book builds on this project all the way through Part III. Even then, the goal is not to build a production-quality website but rather to teach you via example. We nonetheless discuss how to begin and build a production website in Chapter 30.
1.6.1 Selecting Django and Python Versions
Django 1.8 is the latest and greatest Django version and is what every new project should use. Although this book includes informative notes about older versions, please do not use deprecated versions for new projects because these versions do not receive security updates.
Django 1.8 supports Python 2.7 and Python 3.2+ (Python 3.2, Python 3.3, and Python 3.4). When starting a new project, developers are left with the choice of which Python version to use for their project. The choice, unfortunately, is not as simple as picking the latest version.
Python 3 is the future, as Python 2.7 is officially the last Python 2 version. For a website to work for as long as possible, it becomes desirable to create Django websites in Python 3. However, Python 2 is still commonly used, as Django has only officially supported Python 3 since version 1.6, released in November 2013. What’s more, enterprise Linux systems still ship with Python 2 as the default, and tools and libraries built for Django may still require Python 2 (as our site in Parts I, II, III is self-contained to Django, we do not need to worry about this decision yet, but we return to the issue in Chapter 30).
When creating reusable tools for a Django project, the gold standard is thus to write code that works in both Python 3 and Python 2. The easiest way to do this is to write code intended for Python 3 and then make it backward compatible with Python 2.7.
Our project is a simple website not aimed at being reused. In light of this and the many guides written about writing Python code that runs in both 2 and 3, our project will be built to run only in Python 3. Specifically, we use Python 3.4 (there is no technological reason to choose 3.2 or 3.3 over 3.4). This will further allow us to focus on Django itself and not get distracted by compatibility issues.
1.6.2 Project Specifications
Website tutorials have gone through phases. Tutorials started by teaching developers how to build blogs. Some disparaged these yet-another-blog tutorials as being passé. Writers switched first to building forums, then polls, and finally to-do lists.
In the real world, if you needed any of these applications, you would download an existing project such as WordPress or sign up for a service such as Medium. Rather than weeks of development, you would have a website by the end of an afternoon. It might not be as you envisioned your perfect site, but it would be good enough.
One of Django’s major strengths is its precision. Django allows for the rapid creation of unusual websites that work exactly as the developer desires. It is in your interest for this book to build a website that is not available on the Internet already. The difficulty with building an unusual website is that the material tends to be less accessible.
Given the approachable nature of a blog, we will build a blog with special features. A blog is a list of articles, or blog posts, published on a single site and organized by date. Blog authors may choose to write about anything in each post, but they usually stick to a general theme throughout the entire blog. Our blog focuses on news relating to technology startup businesses. The goal is to help publicize startups to blog readers.
The problem with most blogs is that their topics are not well organized. Blogging platforms typically label blog posts with tags, leading writers to create tags for each item they blog about. A blog about startups would likely have a tag for each startup written about. We use Django to improve our blog’s topic organization.
In our website, we expand blog functionality by codifying the creation of startups. Each startup will be its own object, not a tag. The advantage of making startups their own objects is that it allows us to add special information about them. We can now display information related to the business. We can list a description and a date, and we can even link to external articles written about the startup. These capabilities would not be possible if the startup were simply a tag.
Furthermore, we may organize startups with the same tags we use to label the blog posts. For example, we may label Startup A with the Mobile and Video Games tags. We could then tag Startup B with Mobile and Enterprise. These categories make organizing data simple but flexible. If we browse to the Mobile tag, the website uses that tag to list both Startup A and Startup B as well as any blog posts with the tag. For our website, we also enable blog posts to be directly connected to startup objects. Blog posts will thus exist for news about the site itself or to announce news about startups in our system. Our website makes startups far more discoverable than a regular blog website would.
In Part I, we focus on the most basic features. We create the blog, startup, and tagging system in Django. The goal is to make Django’s core, features necessary to every website, as evident as possible.
In Part II, we allow authenticated users to log in. The public will be able to read any of the content of the website. Authenticated users will be able to submit articles, startups, and tags. These content suggestions will be reviewable by you, the site administrator.
In Part III, we allow for tag inheritance. If we write a blog post about Startup A, the tags labeling the startup will now also label the blog post.
It benefits us to list the webpages we will build in Part I:
- A page to list tags
- A page to list startups
- A page to list blog posts
- A page for each tag
- A page for each startup
- A page for each blog post (which also lists news articles)
- A page to add a new tag
- A page to add a new startup
- A page to add a new blog post
- A page to add and connect news articles to blog posts