�ݺ�ߣ

Welcome to Django
The Web framework for Perfectionists with deadlines
Vlad Voskoboynik
November 2012

Introduction to Django
• Leading Python Web Framework

• Good for any service, not just Web apps

Why for Perfectionists?
• Emphasizing clean MVC design

• Django apps are reusable by design – DRY Principle

• Extremely easy to unit-test

Key Features
• ORM • Caching
• Admin • I18N
• URL’s design • Middleware
• Authentication • Unit testing
• Template engine • Integrated GIS
• Reusable apps

Lots of reusable apps
Hundreds of pluggable apps/components exists for almost any
purpose

How do you develop/run?
• Any IDE (vim, Eclipse, PyCharm etc.)

• Django runs on Linux, Apache/NGINX, MySQL/Postgress,
Python

Design philosophies
• Loose coupling
A fundamental goal of Django’s stack is loose coupling. The various layers
of the framework shouldn’t “know” about each other unless absolutely
necessary.
For example, the template system knows nothing about Web requests, the
database layer knows nothing about data display and the view system
doesn’t care which template system a programmer uses.
Although Django comes with a full stack for convenience, the pieces of the
stack are independent of another wherever possible.

• Less code
Django apps should use as little code as possible; they should
lack boilerplate. Django should take full advantage of Python’s
dynamic capabilities, such as introspection.

• Don’t repeat yourself (DRY)
Every distinct concept and/or piece of data should live in one,
and only one, place. Redundancy is bad. Normalization is good.
The framework, within reason, should deduce as much as
possible from as little as possible.

• Explicit is better than implicit
This is a core Python principle listed in PEP 20, and it means
Django shouldn’t do too much “magic.” Magic shouldn’t happen
unless there’s a really good reason for it.

• Model
Models should encapsulate every aspect of an “object,”
following Martin Fowler’s Active Record design pattern.
This is why both the data represented by a model and
information about it (its human-readable name, options like
default ordering, etc.) are defined in the model class; all the
information needed to understand a given model should be
stored in the model.

• The core goals of the database API are:
The database API should allow rich, expressive statements in as
little syntax as possible. It should not rely on importing other
modules or helper objects.
Joins should be performed automatically, behind the scenes,
when necessary.
Every object should be able to access every related object,
systemwide. This access should work both ways.
The framework should make it easy to write custom SQL –
entire statements, or just custom WHERE clauses as custom
parameters to API calls.

• URL design
• Loose coupling
• URLs in a Django app should not be coupled to the underlying
Python code. Tying URLs to Python function names is a Bad
And Ugly Thing.
• Along these lines, the Django URL system should allow URLs
for the same app to be different in different contexts. For
example, one site may put stories at /stories/, while another
may use /news/.

• Infinite flexibility
URLs should be as flexible as possible. Any conceivable URL
design should be allowed.

• Don’t invent a programming language
The template system intentionally doesn’t allow the following:
Assignment to variables
Advanced logic
The goal is not to invent a programming language. The goal is to offer
just enough programming-esque functionality, such as branching and
looping, that is essential for making presentation-related decisions.
The Django template system recognizes that templates are most often
written by designers, not programmers, and therefore should not
assume Python knowledge.
• Safety and security
The template system, out of the box, should forbid the inclusion of
malicious code – such as commands that delete database records.
This is another reason the template system doesn’t allow arbitrary
Python code.
• Extensibility
The template system should recognize that advanced template authors
may want to extend its technology.
This is the philosophy behind custom template tags and filters.

• Templates
A template is simply a text file. It can generate any text-based format
(HTML, XML, CSV, etc.).
A template contains variables, which get replaced with values when
the template is evaluated, and tags, which control the logic of the
template.
Below is a minimal template that illustrates a few basics. Each element
will be explained later in this document.:
{% extends "base_generic.html" %}
{% block title %}{{ section.title }}{% endblock %}
{% block content %} <h1>{{ section.title }}</h1>
{% for story in story_list %}
<h2>
<a href="{{ story.get_absolute_url }}"> {{ story.headline|upper }} </a>
</h2>
<p>{{ story.tease|truncatewords:"100" }}</p>
{% endfor %}
{% endblock %}

Template system
• Separate logic from presentation
We see a template system as a tool that controls presentation
and presentation-related logic – and that’s it. The template
system shouldn’t support functionality that goes beyond this
basic goal.
• Discourage redundancy
The majority of dynamic Web sites use some sort of common
sitewide design – a common header, footer, navigation bar, etc.
The Django template system should make it easy to store those
elements in a single place, eliminating duplicate code.
This is the philosophy behind template inheritance.
• Be decoupled from HTML
The template system shouldn’t be designed so that it only
outputs HTML. It should be equally good at generating other
text-based formats, or just plain text.

Views
• Simplicity
• Writing a view should be as simple as writing a Python function.
Developers shouldn’t have to instantiate a class when a function will
do.
• Use request objects
Views should have access to a request object – an object that stores
metadata about the current request. The object should be passed
directly to a view function, rather than the view function having to
access the request data from a global variable. This makes it light,
clean and easy to test views by passing in “fake” request objects.
• Loose coupling
• A view shouldn’t care about which template system the developer
uses – or even whether a template system is used at all.
• Differentiate between GET and POST
GET and POST are distinct; developers should explicitly use one or the
other. The framework should make it easy to distinguish between GET
and POST data.

• Middleware
Middleware is a framework of hooks into Django’s request/response processing. It’s
a light, low-level “plugin” system for globally altering Django’s input or output.
Each middleware component is responsible for doing some specific function. For
example, Django includes a middleware component, TransactionMiddleware, that
wraps the processing of each HTTP request in a database transaction.
Django ships with some built-in middleware you can use right out of the box.

• Activating middleware
To activate a middleware component, add it to the MIDDLEWARE_CLASSES tuple in
your Django settings.
In MIDDLEWARE_CLASSES, each middleware component is represented by a string:
the full Python path to the middleware’s class name. For example, here’s the
default value created by django-admin.py startproject:

MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware', )

Creating a project

What startproject created ?

Development server:
Python manage.py runserver

Activating the admin site

settings.py

Activating the admin site
urls.py

�ݺ�ߣ

Introduction to django

Recommended

More Related Content

Viewers also liked (19)

Similar to Introduction to django (20)

Introduction to django