Introduction to django


Published on

1 Comment
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to django

  1. 1. Welcome to DjangoThe Web framework for Perfectionists with deadlinesVlad VoskoboynikNovember 2012
  2. 2. Introduction to Django• Leading Python Web Framework• Good for any service, not just Web apps
  3. 3. Why for Perfectionists?• Emphasizing clean MVC design• Django apps are reusable by design – DRY Principle• Extremely easy to unit-test
  4. 4. Key Features• ORM • Caching• Admin • I18N• URL’s design • Middleware• Authentication • Unit testing• Template engine • Integrated GIS• Reusable apps
  5. 5. Lots of reusable appsHundreds of pluggable apps/components exists for almost anypurpose
  6. 6. How do you develop/run?• Any IDE (vim, Eclipse, PyCharm etc.)• Django runs on Linux, Apache/NGINX, MySQL/Postgress, Python
  7. 7. 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.
  8. 8. • 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.
  9. 9. • 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.
  10. 10. • 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.
  11. 11. • 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.
  12. 12. • 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.
  13. 13. • 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 %}
  14. 14. 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.
  15. 15. 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.
  16. 16. • 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 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, )
  17. 17. Creating a project What startproject created ? Development server:Python runserver
  18. 18.
  19. 19. Creating APP
  20. 20. Model
  21. 21. Playing with the API
  22. 22. Activating the admin
  23. 23. Activating the admin
  24. 24. Start developer server