============================
Django Step by Step (十七)
============================

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

.. contents:: 目录
.. sectnum::

引言
=====

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

.. _Django: http://www.djangoproject.com/

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

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 方法。

如何设计
==========

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

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

可以从几下以方面考虑：

#. 输出内容

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

#. 输出范围

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

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

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

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

结论
======

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

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