Django Step by Step (十七)

作者:limodou
联系:limodou@gmail.com
版本:0.1
主页:http://wiki.woodpecker.org.cn/moin/NewEdit
BLOG:http://www.donews.net/limodou
版权:FDL

目录

1   引言

经过前面许多讲之后,我想大家应该对 Django 的基本开发概念和过程已经有所了解。那么是时候讲一些关于设计方面的东西。首先要声明,目前 Django 基本上还没有什么设计的教程,而我也只能写一些个人体会。

那么这篇教程的体会就是:View, Template and Templatetag

2   View, Temaplte 和 Tag 之间的关系

View 在 Django 中是用来处理请求的,一个 url 请求上来后经过 Django 的处理首先找到这个 url pattern 对应的 View 模块的某个方法。因此 View 是处理请求的起点,同时,在 View 中的方法需要返回,因此它还是一个请求的终点。因此象 Template 和 Tag 只不过是处理中的某些环节。 View 可处理的范围远大于 Template 而 Tag 则只能用在 Template 中。因此从使用范围上说:View > Template > Tag。

Template 是用来输出内容的,目前在 Django 中你可以用它输出文本之类的东西。但象图片之类的非文本的东西,则只能通过 View 来实现,再有如果想在输出时加入一些特殊的 HttpHeader 的控制也只能在 View 中实现。当然,在大多数情况下我们只处理动态的文本生成,其它许多东西都是静态的。象图片之类的可以通过链接来引用。

Tag 是在 Template 中被使用的。它的作用很多,如控制模板逻辑,还可以输出内容并做转换等。Tag 可以自定义,因此你可以在 Tag 中做几乎你想做的有关内容输出的任何事,如从数据库中取出内容,然后加工,输出,许多事情。

在 Django 中提供了一种方便的方法,可以直接将 url 与模板相对应起来。但并不是说你不需要 View 的参与,而是这个 View 的功能是预先写好的,它的作用很简单,就是在 View 方法中直接渲染一个模板并输出。因此说,看上去好象是直接对应,但实际上还是有 View 的处理。比如:

(r'^ajax/$', 'django.views.generic.simple.direct_to_template',
    {'template': 'ajax/ajax.html'}),

这是在讲 Ajax 的一个 url 的配置,其中使用了 django.views.generic.simple.direct_to_template 这个做好的 View 方法。

3   如何设计

从上面的分析我们可以看出, View, Template, Tag 功能不尽相同,但的确有部分功能的重叠,特别是在文本信息的输出。

如何比较好的选择使用什么来输出呢?

可以从几下以方面考虑:

  1. 输出内容

    HTML或文本内容,可以考虑使用 View + Template + Tag ,其它的考虑使用 View

  2. 输出范围

    如果是多数据源,比如一个首页,可能包含许多不同的内容,如个人信息统计,Blog展示,日历,相关的链接,分类等,这些信息类型不同,如何比较好的处理呢?可以以 View 为主,即数据在 View 中提供,在模板中考虑输出和布局。但有一个问题,重用不方便。因此采用 Tag 可能更适合。因此对于单一或简单数据源可以只采用 View 和 Template 来实现,而对于多数据源可以采用使用 Temaplate 控制布局,Tag 用来输出单数据源信息。

同时对于多数据源的信息还可以考虑使用 Ajax 技术动态的将信息结合在一起。但使用 Ajax 则需要动态与后台交互,将单数据源的信息组织在一起,这样每个来源都是一个 View 的处理。不过这个有些复杂,这里我们不去考虑它。

因此当你设计结构时,首先考虑实现的内容,是文本的,则可以考虑使用 View, Template 和 Tag。

然后再看是否有重用的需要,有的话,将可重用的部分使用 Tag 来实现,而 View 和 Template 作布局和控制。

4   结论

这里我想到一个问题:我一直想使用 Admin 作为我的数据管理的界面。但经过上面的分析,Admin 目前大多数情况下只处理单一数据表,有些包含关系的,比如一对一,多对一,多对多的可以在一个编辑页面中同时处理多个表的记录,但它还是有可能无法满足复杂的多数据源的表现和编辑问题。因此 Admin 应该可以认为是一个缺省的数据库管理界面,而不完全是一个用户管理界面。因此大多数情况下,你仍然需要自定义管理界面,而不能完全依靠 Admin 。除非你的应用简单,同时对于管理界面的要求不高。

解决了这个问题,于是我们不必太留恋 Admin 的功能,我相信会有一些好的解决方案来满足我们的要求,或者就是我们自已来创建这样的项目。