django模板截取字符.docx

django模板截取字符.docx

《django模板截取字符.docx》由会员分享，可在线阅读，更多相关《django模板截取字符.docx（8页珍藏版）》请在冰豆网上搜索。

django模板截取字符

竭诚为您提供优质文档/双击可除

django模板,截取字符

　　篇一：

django的templates设置项（1.8新特性）

　　django的templates设置项（1.8新特性）

　　templates

　　django1.8的新特性

　　一个列表，包含所有在django中使用的模板引擎的设置。

列表中的每一项都是一个字典，包含某个引擎的选项。

　　以下是一个简单的设定，告诉django模板引擎从已安装的应用程序（installedapplications）的templates子目录中读取模板：

　　templates=[

　　{

　　backend:

django.template.backends.django.djangotemplates,app_diRs:

true,

　　},

　　]

　　以下选项对所有引擎（backends）都可用。

backend

　　默认：

无定义

　　使用的模板引擎。

内建的模板引擎有：

　　django.template.backends.django.djangotemplatesdjango.template.backends.jinja2.jinja2

　　通过设置backend为一个完整的（fully-qualified）路径（例如mypackage.whatever.backend），你可以使用非django自带的引擎。

　　name

　　默认：

看下面

　　该模板引擎的别名。

它是一个标识符，让你在渲染时可以选择一个引擎。

别名在所有配置好的模板引擎中必须是唯一的。

　　当未提供值时，默认是定义引擎类的模板名，也即是与backend相邻的最后一部分。

例如如果引擎是mypackage.whatever.backend，那么它的默认名为whatever。

　　diRs默认：

[]（空列表）

　　引擎用于查找模板源文件的目录，按搜索顺序排列。

　　app_diRs

　　默认：

False

　　引擎是否在已安装应用程序（的目录）内查找模板源文件。

options

　　默认：

{}（空字典）

　　传递给该模板引擎（backend）的其他参数。

不同的引擎，可用的参数不一样。

　　template_context_pRocessoRs默认：

　　（"django.contrib.auth.context_processors.auth",

　　"django.template.context_processors.debug",

　　"django.template.context_processors.i18n",

　　"django.template.context_processors.media",

　　"django.template.context_processors.static",

　　"django.template.context_processors.tz",

　　"django.contrib.messages.context_processors.messages"）

　　自1.8版本起，不赞成使用：

　　在一个djangotemplates引擎中的options设置context_processors选项来代替。

　　用于填充在Requestcontext中的上下文的调用函数（callables）的元组。

这些函数获取一个request对象作为它的参数，返（django模板,截取字符）回一个将要填充至上下文项目的字典。

　　django1.8的变化：

　　在django1.8中，内建模板的上下文处理器从django.core.context_processors移至django.template.context_processors。

　　template_debug

　　默认：

False

　　自1.8版本起，不赞成使用：

　　在一个djangotemplates引擎中的options设置debug选项来代替。

　　一个打开/关闭模板调试模式的布尔值。

如果值是true，在模板渲染期间，抛出任何异常都将显示一个可爱的、详情报告的错误页面。

该页面包含该模板相关的代码段，并且使用适当的行高亮。

　　注意如果debug是true，django只会显示可爱的错误页面。

　　参见debug。

　　template_diRs

　　默认：

（）（空列表）

　　自1.8版本起，不赞成使用：

　　在一个djangotemplates引擎中设置diRs选项来代替。

　　django.template.loaders.filesystem.loader搜索模板源代码的路径列表，，按搜索顺序排列。

注意即使在windows中，这些路径也是使用unix风格的正斜杠。

　　参见thedjangotemplatelanguage。

　　template_loadeRs

　　默认：

　　（django.template.loaders.filesystem.loader,

　　django.template.loaders.app_directories.loader）

　　自1.8版本起，不赞成使用：

　　在一个djangotemplates引擎中的options设置loader选项来代替。

　　模板读取器类的元组，用字符串指定。

每个读取器类知道怎样从一个特定源（particularsource）中导入模板。

可选地，也可以使用一个元组来代替使用一个字符串。

元组中的第一项应该是读取器的模块，随后的项是在初始化时传递给读取器。

参见thedjangotemplatelanguage:

forpythonprogrammers。

template_stRing_iF_inValid

　　默认：

（空字符串）

　　自1.8版本起，不赞成使用：

　　在一个djangotemplates引擎中的options设置string_if_invalid选项来代替。

　　当使用了不可用的（比如说拼写错误）变量时模板系统输出的字符串。

参见howinvalidvariablesarehandled。

　　篇二：

django框架学习-templates进阶用法--上

　　也许，你想要自定义和扩展模板引擎，下面会介绍一些关于如何去扩展模板系统的方法，

　　了解一下模板系统的工作原理，同时也会介绍django模板系统中的auto-escapint功能，

　　这是一种安全机制。

　　复习一下模板语言的用法

　　{#模板tag的用法#}

　　{%ifdone%}

　　over

　　{%else%}

　　wait

　　{%endif%}

　　{#模板变量的用法#}

　　nowis{{nowtime}}

　　在views.py中使用模板的时候：

　　1.通过模板名，获得模板对象

　　2.创建context对象，类似字典，用于像模板提供变量实际的值

　　3.使用context对象进行模板的渲染，返回的是html网页的内容

　　使用Requestcontext对上下文内容进行重用

　　当渲染一个模板的时候，我们通常使用的是django.template.context的对象，

　　这里要介绍另外一个它的子类，django.template.Requestcontext，

　　Requestcontext提供了一种把不同的context内容中公共的部分提取出来的方法，

　　让context的内容重用。

　　下面来看例子：

　　1.context版

　　fromdjango.templateimportloader,context

　　fromdjango.httpimporthttpResponse

　　defview_1（request）:

　　#...

　　t=loader.get_template（template1.html）

　　c=context（{

　　app:

myapp,

　　user:

request.user,

　　ip_address:

request.meta[Remote_addR],

　　message:

iamview1.

　　}）

　　returnhttpResponse（t.render（c））

　　defview_2（request）:

　　#...

　　t=loader.get_template（template2.html）

　　c=context（{

　　app:

myapp,

　　user:

request.user,

　　ip_address:

request.meta[Remote_addR],

　　message:

iamthesecondview.

　　}）

　　returnhttpResponse（t.render（c））

　　可以看到两个context的内容有些是重复的。

比如app,user,ip_address

　　2.下面改写成Requestcontext版

　　fromdjango.templateimportloader,Requestcontext

　　fromdjango.httpimporthttpResponse

　　#使用contextprocessro去提供一些context内容中公共的部分，也就是返回一个字典而已。

defcustom_proc（request）:

　　"acontextprocessorthatprovidesapp,userandip_address."return{

　　app:

myapp,

　　user:

request.user,

　　ip_address:

request.meta[Remote_addR]

　　}

　　defview_1（request）:

　　#...

　　t=loader.get_template（template1.html）

　　#创建方式不同，需要提供的参数有三个，request对象，字典类型，processors可选c=Requestcontext（request,{message:

iamview1.},

　　processors=[custom_proc]）

　　returnhttpResponse（t.render（c））

　　defview_2（request）:

　　#...

　　t=loader.get_template（template2.html）

　　c=Requestcontext（request,{message:

iamthesecondview.},processors=[custom_proc]）

　　returnhttpResponse（t.render（c））

　　可以看到所谓的contextprocessors其实就是一个函数，参数为request，

　　返回一个字典类型。

这就是它所做的所有的事。

在这里custom_proc返回的

　　是包含共同的那三个参数的字典

　　Requestcontext构造函数中的第三个参数processors是可选的，可以是

　　多个custom_proc函数的列表或是元组，在这里我们只传递了一个，可以为多个。

　　结合Requestcontext使用render_to_response函数直接返回httpResponse对象

　　returnrender_to_response（template2.html,

　　{message:

iamthesecondview.},

　　context_instance=Requestcontext（request,processors=[custom_proc]））以上代码就可以一步到位。

　　但是又引入了另一个问题，在每次使用render_to_response函数时，都要向

　　Requestcontext指定所需要的contextprocessors，因为这个原因，

　　django又给

　　我们提供了全局的processors，它默认是被传递给Requestcontext对象的，这个设置对应的是d:

\python27\lib\site-packages\django\conf\global_setings.py文件

　　中template_context_pRocessoRs属性,这样使用Requestcontext的时候，就

　　不需要每次指定processors了。

　　我现在使用的是django-1.4，所以路径是在这里，貌似以前的版本是直接在工程

　　文件夹下的settings.py文件，上面都是一些processors函数的字符串表示，下面

　　介绍一些常用的默认被打开的processors提供的参数：

　　django.contrib.auth.context_processors.auth

　　user:

当前登入的用户名

　　perms：

用户所有的权限

　　django.core.context_processors.debug

　　debug：

是否打开

　　debug模式

　　sql_queries：

{sql:

...,time:

...}形式的字典信息，显示执行的每一个sql查询和

　　它执行所需的时间。

从django的源码可以看出要使用这个processors

　　，需要首先打开调

　　试模式，其次需要是你的ip在initeRnal_ips元组中。

　　initeRnal_ips是什么东西？

　　它在之前的global_settings.py文件中，目前是一个空的元组，应该是用来安全认证的设置（猜测）。

　　django.core.context_processors.request这就是request对象的processors，估计是直接返回request对象。

　　源代码和想像的一样。

　　一些关于自定义全局processors的建议：

　　1.确保你的每个processor只对应一小部分的功能需要的数据，这样才能保证重用性更强，组合方式更多，不会太重复。

　　2.一旦定义了全局processor，那么它将对使用Requestcontext的所有模板文件可见，

　　所以需要注意模板变量名字的选择，一种比较好的作法是全局processor中的变量全部使用大写。

　　3.习惯把processors函数放在名为context_processors.py文件中，命名习惯而已。

只要你在template_context_pRocessoRs元组中写对你的路径就可以。

　　篇三：

django的模板和静态文件设置

　　1.在工程目录下创建一个新的目录叫做templates。

这个目录用于存放django模板文件。

　　可以在这个目录下，创建与app名称相对应的文件夹，用于存放每个app的模板文件。

在settings.py文件中，找到templates列表，在templates列表中有一个diR:

[]，在里面加上模板路径即可。

　　2.动态路径

　　settings.py文件里包含了一个变量base_diR.这个变量会保存settings.py文件的路径.这里面用了一个特殊的__file__属性,它能获取模块的绝对路径.然后通过调用os.path.dirname（）来提供绝对路径的目录.再次调用os.path.dirname（）我们回得到上层的目录。

　　template_path=os.path.join（base_diR,templates）

　　我们用os.path.join（）函数来连接basw_diR变量和templates,

　　3.设置静态媒体目录

　　设置静态媒体，需要设立存储它们的目录。

在工程目录里创建static的目录。

在settings.py文件，需要设置两个变量static_uRl和staticFiles_diRs。

static_uRl定义了当django运行时，django应用寻找静态媒体的地址。

例如

　　【static_uRl=/static/】，static_uRl设置成/static/,我们就可以通过http:

//127.0.0.1:

8000/static/来访问它了。

　　static_uRl定义了web服务链接媒体的uRl地址，staticFiles_diRs允许定义新的static目录。

像template_diRs元组一样.staticFiles_diRs需要static目录的绝对路径.使用base_diR变量来创建static_path.例如：

staticFiles_diRs=（os.path.join（base_diR,static）,）

　　4.静态媒体文件和模板

　　使用静态媒体，需要在模板文件中加入标签{%loadstatic%}，才可以使用{%static"rango.jpg"%}在模板里调用static文件.django模板标签用{}来表示.在这个例子里我们用static标签,它将会把static_uRl和rango.jpg连接起来。

如下所示：

在模板里使用静态媒体你需要调用{%static%}函数，如下是在模板里添加

　　javascript,css:

　　5.静态媒体服务

　　第一个变量media_uRl定义了基地址.如果把media_uRl设置为/media/意味着上传uRl为http:

//127.0.0.1:

8000/media/.media_Root用来告诉django你的上传文件保存在电脑的哪个位置.在上边的例子中,我们用5.1章节设置的pRoject_path变量和/media/连接.就变成了绝对路径/tango_with_django_project/media/.实例如下：

　　media_uRl=/media/

　　media_Root=os.path.join（base_diR,media）

　　urls.py需要修改设置：

　　通过导入django.conf的settings模块我们可以得到我们项目里settings.py文件的变量.接下来的条件判断语句判断django是否处在debug模式.如果debug被设定为true,那么就会在urlpatterns加入uRl匹配模式.所有以media/开头的青豆都会传递给django.views.static视图.这个视图将会把上传的媒体传给你。

urls.py需要添加如下内容：

　　fromdjango.confimportsettings

　　#undeRneathyoururlpatternsdefinition,addthefollowingtwolines:

ifsettings.debug:

　　urlpatterns+=patterns（

　　django.views.static,

　　（r^media/（p　　.*）,

　　serve,

　　{document_root:

settings.media_Root}）,）