• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introduction to django
 

Introduction to django

on

  • 264 views

 

Statistics

Views

Total Views
264
Views on SlideShare
264
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Introduction to django Introduction to django Presentation Transcript

    • Welcome to DjangoThe Web framework for Perfectionists with deadlinesVlad VoskoboynikNovember 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 appsHundreds of pluggable apps/components exists for almost anypurpose
    • How do you develop/run?• Any IDE (vim, Eclipse, PyCharm etc.)• Django runs on Linux, Apache/NGINX, MySQL/Postgress, Python
    • Design philosophies• Loose couplingA fundamental goal of Django’s stack is loose coupling. The various layersof the framework shouldn’t “know” about each other unless absolutelynecessary.For example, the template system knows nothing about Web requests, thedatabase layer knows nothing about data display and the view systemdoesn’t care which template system a programmer uses.Although Django comes with a full stack for convenience, the pieces of thestack are independent of another wherever possible.
    • • Less codeDjango apps should use as little code as possible; they shouldlack boilerplate. Django should take full advantage of Python’sdynamic 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 aspossible from as little as possible.• Explicit is better than implicitThis is a core Python principle listed in PEP 20, and it meansDjango shouldn’t do too much “magic.” Magic shouldn’t happenunless there’s a really good reason for it.
    • • ModelModels 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 andinformation about it (its human-readable name, options likedefault ordering, etc.) are defined in the model class; all theinformation needed to understand a given model should bestored in the model.
    • • The core goals of the database API are:The database API should allow rich, expressive statements in aslittle syntax as possible. It should not rely on importing othermodules 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 customparameters 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 flexibilityURLs should be as flexible as possible. Any conceivable URLdesign should be allowed.
    • • Don’t invent a programming languageThe template system intentionally doesn’t allow the following:Assignment to variablesAdvanced logicThe goal is not to invent a programming language. The goal is to offerjust enough programming-esque functionality, such as branching andlooping, that is essential for making presentation-related decisions.The Django template system recognizes that templates are most oftenwritten by designers, not programmers, and therefore should notassume Python knowledge.• Safety and securityThe template system, out of the box, should forbid the inclusion ofmalicious code – such as commands that delete database records.This is another reason the template system doesn’t allow arbitraryPython code.• ExtensibilityThe template system should recognize that advanced template authorsmay want to extend its technology.This is the philosophy behind custom template tags and filters.
    • • TemplatesA 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 whenthe template is evaluated, and tags, which control the logic of thetemplate.Below is a minimal template that illustrates a few basics. Each elementwill 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 presentationWe see a template system as a tool that controls presentationand presentation-related logic – and that’s it. The templatesystem shouldn’t support functionality that goes beyond thisbasic goal.• Discourage redundancyThe majority of dynamic Web sites use some sort of commonsitewide design – a common header, footer, navigation bar, etc.The Django template system should make it easy to store thoseelements in a single place, eliminating duplicate code.This is the philosophy behind template inheritance.• Be decoupled from HTMLThe template system shouldn’t be designed so that it onlyoutputs HTML. It should be equally good at generating othertext-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 objectsViews should have access to a request object – an object that storesmetadata about the current request. The object should be passeddirectly to a view function, rather than the view function having toaccess 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 POSTGET and POST are distinct; developers should explicitly use one or theother. The framework should make it easy to distinguish between GETand POST data.
    • • MiddlewareMiddleware is a framework of hooks into Django’s request/response processing. It’sa light, low-level “plugin” system for globally altering Django’s input or output.Each middleware component is responsible for doing some specific function. Forexample, Django includes a middleware component, TransactionMiddleware, thatwraps 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 middlewareTo activate a middleware component, add it to the MIDDLEWARE_CLASSES tuple inyour 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 thedefault 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
    • settings.py
    • Creating APP
    • Model
    • Playing with the API
    • Activating the admin sitesettings.py
    • Activating the admin siteurls.py
    • Start developer server