Day11

1.The way to Django

 

　　1.1 The Django's MTV framework：

 

　　　　We have learned ORM framework before last week,and now konwing how to establish ORM  , how Orm manipulating the mysql database, and how Controller layer use the orm (we progarmmed three functions of save()、updata() and select() )

 

 

 　　The same to Django，but here Django use the MTV framework.The Django's orm  is model layer,the traditional View layer acturally corresponded the MVT's template layer

　　　　model layer:Django provides an abstraction layer (the "models")for structuring and manipulating the data of yoru web application

　　　　View layer:Django has the concept of "views" to encapsulate the logic responsible for processing a user's request

　　　　template layer :The template layer provides a designer-friendly syntax for rendering the information to be presented to the user.

　　

　　1.2 The model layer

　　　　1.2.1 Models

　　　　　　A model is the single,definitive source of information about your data. It contains the essential fields and behavios of the data you're storing.Generally,each model maps to a single data table 

　　　　　　The basics:

• • 　　Each model is a Python class that subclasses django.db.models.Model.
  • 　　Each attribute of the model represents a database field.
  • 　　With all of this,Django gives you an automatically-generater database-access API

　　　　

　　　　  1.2.2 Making queries(查询集合)

　　　　　   Once you've created your data models,Django automatically gives you a databases-abstraction API that lets you create , retrieve,update and delete objects.This document explains how to use this API.Refer to the data model reference for full details of all the various model lookup options

 

 　　　　* 1.2.3 Model instance reference

　　　　　　this document describes the details of the Model API.It builds on the material presented in the model and database query guides,so you'll probably want to read and understand those documents before reading.

　　　　　1.2.4 Migrations 

　　　　　　Migrations are Django's way of propagating(传播) changes you make to your models(adding a fields,deleting a model etc.)into your database schema.They're designed to be mostly automatic,but you'll need to konw when to make migrations,when to run them,and the common problems you might run into

 　　　　

　　  1.3 The view layer

　　　　　　1.3.1 The basics:

　　　　　　　　　1.3.1.1 URLconfs:

　　　　　　　　　　　　A clean ,elegant URL scheme is an importan detail in a high-quality Web application.Django lets you design URLs however you want,with no framework Limitaions

　　　　　　　　　 1.3.1.2 Writing views:

　　　　　　　　　　　　A view function,or view for short, is simply a Python function that  takes a Web request and returns a Web response. This response can be the HTML contents of a Web page, or redirect , or a 404 error , or an XML document,or an image...or anything, really. The view itself contains whatever arbitrary logic is necessary to return that response.This code can live anywhere yo want,as long as it's on your Python path.There's no other requirement-no "magic",so to speak.For the sake of putting the code somewhere, the convention is to put views in a file called views,oy,placed in your project or application directory.　　　　　

　　　　　　　　　1.3.1.3 Django  shortcut functions:

　　　　　　　　　　　　The package django.shotcuts collects helper functions and classes that "span" mutiple levels of MVC.In other words,these functions/classes introduce controlled coupling(耦合) conveniance's sake

　　　　　　　　　1.3.1.4 View decorators

　　　　　　　　　　　　Django provides several decorators that can be applied  to views to support various HTTP features(样式，外貌，特征).

　　　　　　　　　 

　　　　　　　1.3.2 Built-in Views

　　　　　　Severak if Django's built-in views are documented in Wiring views as well as elsewhere in the documentation

　　　　　　　　

　　　　　　1.3.3 File Uploads

　　　　　　When Django handles a file upload,the file data ends up placed in rquest.FILES(for more on the request object see the doucumentation for request and response object).This document explains how files are stored on the disk and in memory,and how to customize(定制) the default behavior

 

　　　　　　1.3.4 Class-based views

　　　　　　A view is a callable which takes a request and returns a response.This can be more than just a function, and Django provide an example of some classes which can be used as views.These allow you yo structure your views and reuse code by harnessing(驾驭) inheritance(继承) and mixins(混合).There are also some generic views for simple tasks which we'll go to later,but you may want to design your own structure of reusable views which suits your use case

　　

　　　　　　1.3.5 Generating CSV(Outputting CSV with Django)

　　　　　　This document explains how to output CSV(Comma Separated Values 逗号分隔值)，dynamically(动态地) using Django views.To do this,you can either use the Python CSV library or the DJango template system.

 

　　　　　　1.3.6 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 middlware comphonet,AuthenticationMiddleware,that associates users with requests using sessions.

　　　　　　This document explains how middleware works,how you activate middleware,and how to write your own middleware.Django ships with some built-in middleware you can use right out of the box.They'redoucumented in the built-in middleware reference.

　　　 1.4 The template layer

　　　　　　 1.4.1 The basis 

　　　　　　Being a web framwork ,Django needs a convenient way to generate HTML dynamically.The most common approcah relies on templates.A template contains the static parts of the desired HTML output as well as some special syntax describing how dynamic content will be inserted.

　　　　　　A Django project can be configured with one or several template engines(or even zero if you don't use templates).Django ships built-in backends(后端) for its own template system,creatively called the Django template language(DTL),and for the popular alternative Jinja2.Backends for other template languages may be available from third-parties.

　　　　　　Django defines a standard API for loading and rendering(渲染) templates regardless(不管) of  backend.Loading consists(组成) of finding the template for a given identifier and  preprocessing it,usually compiling(编译) it to an in-memory representation(表示).Rendering means interpolating(内插) the template with context data and returning the resulting string.

　　　　　　The Django template language is Django's own template system.Until Django 1.8 it was the only built-in option available.It's a good template library even though it's fairly(相当) opinionated(自以为是) and sports a few idosysncrasies(特质).If you don't have a pressing(紧迫) reason to choose another backend,you should use the DTL,especially if you're writing a pluggable(可插拔) application and you intend to distribute templates.Django's contrib apps that include templates,like django.contrib.admin ，use the DTL.

　　　　　　For historical resons.both the generic support for template engines and the implemetation of Django template language live in the django.template namespace.