The Django Book

Search

�索

The Web is all about search. Two of the Nets biggest success stories, Google and Yahoo, built their multi-billion-dollar businesses around search. Nearly every site sees a large percentage of traffic coming to and from its search pages. Often the difference between the success or failure of a site is the quality of its search. So it looks like wed better add some searching to our fledgling books site, no?

在web应用上，有两个关于�索获得巨大�功的故事：Google和Yahoo，通过�索，他们建立了几�亿美元的业务。几乎�个网站都有很大的比例访问��自这两个�索引擎。甚至，一个网站是��功�决于其站内�索的质�。因此，在我们这个网站添加�索功能看起�好一些。

Well start by adding the search view to our URLconf (mysite.urls ). Recall that this means adding something like (r'^search/$', 'mysite.books.views.search') to the set of URL patterns.

开始，在URLconf (mysite.urls )添加�索视图。添加类似 (r'^search/$','mysite.books.views.search') 设置URL模�。

Next, well write this search view into our view module (mysite.books.views ):

下一步，在视图模�(mysite.books.views )中写这个 search 视图:

from django.db.models import Q
from django.shortcuts import render_to_response
from models import Book

def search(request):
    query = request.GET.get('q', '')
    if query:
        qset = (
            Q(title__icontains=query) |
            Q(authors__first_name__icontains=query) |
            Q(authors__last_name__icontains=query)
        )
        results = Book.objects.filter(qset).distinct()
    else:
        results = []
    return render_to_response("books/search.html", {
        "results": results,
        "query": query
    })

There are a couple of things going on here that you havent yet seen. First, theres request.GET . This is how you access GET data from Django; POST data is accessed through a similar request.POST object. These objects behave exactly like standard Python dictionaries with some extra features covered in Appendix H.

这里有一些需�注�的，首先 request.GET ，这从Django中怎样访问GET数�；POST数�通过类似的 request.POST 对象访问。这些对象行为与标准Python字典很�，在附录H中列出�其�外的特性。

Whats GET and POST Data?

什么是 GET and POST 数�?

GET and POST are the two methods that browsers use to send data to a server. Most of the time, youll see them in HTML form tags:

GET 和POST 是�览器使用的两个方法，用于��数�到�务器端。 一般�说，会在html表�里�看到:

<form action="/books/search/" method="get">

This instructs the browser to submit the form data to the URL /books/search/ using the GET method.

它指示�览器�/books/search/以GET的方法�交数�

There are important differences between the semantics of GET and POST that we wont get into right now, but see http://www.w3.org/2001/tag/doc/whenToUseGet.html if you want to learn more.

关于GET和POST这两个方法之间有很大的��，�过我们暂时�深入它，如果你想了解更多，�以访问： http://www.w3.org/2001/tag/doc/whenToUseGet.html 。

So the line:

所以下�这行：

query = request.GET.get('q', '')

looks for a GET parameter named q and returns an empty string if that parameter wasnt submitted.

寻找�为 q 的GET�数，而且如果�数没有�交，返回一个空的字符串。

Note that were using the get() method on request.GET , which is potentially confusing. The get() method here is the one that every Python dictionary has. Were using it here to be careful: it is not safe to assume that request.GET contains a 'q' key, so we use get('q', '') to provide a default fallback value of '' (the empty string). If we merely accessed the variable using request.GET['q'] , that code would raise a KeyError if q wasnt available in the GET data.

注�在 request.GET 中使用了 get() 方法，这�能让大家�好�解。这里的 get() 是�个python的的字典数�类型都有的方法。使用的时候��心：�设 request.GET 包�一个 'q' 的key是�安全的，所以我们使用 get('q', '') �供一个缺�的返回值 '' (一个空字符串)。如果�是使用 request.GET['q'] 访问��，在Get数�时 q ��得,�能引� KeyError .

Second, what about this Q business? Q objects are used to build up complex queries in this case, were searching for any books where either the title or the name of one of the authors matches the search query. Technically, these Q objects comprise a QuerySet, and you can read more about them in Appendix C.

其次,关于 Q , Q 对象在这个例�里用于建立��的查询,�索匹�查询的任何书�.技术上 Q 对象包�QuerySet,�以在附录C中进一步阅读.

In these queries, icontains is a case-insensitive search that uses the SQL LIKE operator in the underlying database.

在这个查询中， icontains 使用SQL的 LIKE �作符，是大�写��感的。

Since were searching against a many-to-many field, its possible for the same book to be returned more than once by the query (e.g., a book with two authors who both match the search query). Adding .distinct() to the filter lookup eliminates any duplicate results.

既然�索��多对多域�实现，就有�能对�一本书返回多次查询结果（例如：一本书有两个作者都符�查询�件）。因此添加 .distinct() 过滤查询结果，消除��部分。

Theres still no template for this search view, however. This should do the trick:

现在�然没有这个�索视图的模�，�以如下实现:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<head>
    <title>Search{% if query %} Results{% endif %}</title>
</head>
<body>
  <h1>Search</h1>
  <form action="." method="GET">
    <label for="q">Search: </label>
    <input type="text" name="q" value="{{ query|escape }}">
    <input type="submit" value="Search">
  </form>

  {% if query %}
    <h2>Results for "{{ query|escape }}":</h2>

    {% if results %}
      <ul>
      {% for book in results %}
        <li>{{ book|escape }}</l1>
      {% endfor %}
      </ul>
    {% else %}
      <p>No books found</p>
    {% endif %}
  {% endif %}
</body>
</html>

Hopefully by now what this does is fairly obvious. However, there are a few subtleties worth pointing out:

希望你已�很清楚地明白这个实现。�过，有几个细节需�指出：

The forms action is . , which means the current URL. This is a standard best practice: dont use separate views for the form page and the results page; use a single one that serves the form and search results.

表�的action是 . ， 表示当�的URL。这是一个标准的最佳惯常处�方�：�使用独立 的视图分别�显示表�页�和结果页�；而是使用�个视图页��处�表�并显示�索结果。

We reinsert the value of the query back into the <input> . This lets readers easily refine their searches without having to retype what they searched for.

我们把返回的查询值�新�入到 <input> 中去，以便于读者�以完善他们的�索内容， 而�必�新输入�索内容。

Everywhere query and book is used, we pass it through the escape filter to make sure that any potentially malicious search text is filtered out before being inserted into the page.

在所有使用 query 和 book 的地方，我们通过 escape 过滤器�确�任何 �能的��的�索文字被过滤出去，以���被�入到页�里。

Its vital that you do this with any user-submitted content! Otherwise you open your site up to cross-site scripting (XSS) attacks. Chapter 19 discusses XSS and security in more detail.

这对处�任何用户�交数��说是 必须 的��则的�你就开放你的网站�许跨站点脚本 （XSS）攻击。在第��章中将详细讨论了XSS和安全。

However, we dont need to worry about harmful content in your database lookups we can simply pass the query into the lookup as is. This is because Djangos database layer handles this aspect of security for you.

�过，我们�必担心数�库对�能有�害内容的查询的处�。 Django的数�库层在这方�已��过安全处�。 �译注：数�库层对查询数�自动Escape，所以�用担心】

Now we have a working search. A further improvement would be putting a search form on every page (i.e., in the base template); well let you handle that one yourself.

现在我们已�作了�索。进一步�把�索表�加到所有的页�（例如，在base模�）；这个�以由你自己完�。

Next, well look at a more complex example. But before we do, lets discuss a more abstract topic: the perfect form.

下�，我们看一下更��的例�。事先我们讨论一个抽象的�题：完美表�。

The Perfect Form

完美表�

Forms can often be a major cause of frustration for the users of your site. Lets consider the behavior of a hypothetical perfect form:

表��常引起站点用户的�感。我们考虑一下一个�设的完美的表�的行为：

• It should ask the user for some information, obviously. Accessibility and usability matter here, so smart use of the HTML <label> element and useful contextual help are important.

• 它应该问用户一些信æ�¯ï¼Œæ˜¾ç„¶ï¼Œç”±äºŽå�¯ç”¨æ€§çš„问题， 使用HTML <label> 元素和有用的 上下文帮助是很é‡�è¦�的。

• The submitted data should be subjected to extensive validation. The golden rule of Web application security is never trust incoming data, so validation is essential.

• 所æ��交的数æ�®åº”该多方é�¢çš„验è¯�。Web应用安全的金科玉律是从ä¸�è¦�相信进æ�¥çš„æ•°æ�®ï¼Œæ‰€ä»¥éªŒè¯�是必需的。

• If the user has made any mistakes, the form should be redisplayed with detailed, informative error messages. The original data should be prefilled, to save the user from having to reenter everything.

• 如果用户有一些错误，表å�•åº”该é‡�新显示详情，错误信æ�¯ã€‚原æ�¥çš„æ•°æ�®åº”该已ç»�填好，é�¿å…�用户é‡�新录入，

• The form should continue to redisplay until all of the fields have been correctly filled.

• 表å�•åº”该在所有域验è¯�正确å‰�一直é‡�新显示。

Constructing the perfect form seems like a lot of work! Thankfully, Djangos forms framework is designed to do most of the work for you. You provide a description of the forms fields, validation rules, and a simple template, and Django does the rest. The result is a perfect form with very little effort.

建立这样的表�好�需��很多工作�幸好，Django的表�框架已�设计的�以为你��大部分的工作。你�需��供表�域的�述，验�规则和简�的模���。这样就�需�一点的工作就�以��一个完美的表�。

Creating a Feedback Form

创建一个回馈表�

The best way to build a site that people love is to listen to their feedback. Many sites appear to have forgotten this; they hide their contact details behind layers of FAQs, and they seem to make it as difficult as possible to get in touch with an actual human being.

�好一个网站需�注�用户的�馈，很多站点好�忘记这个。他们把�系信�放在FAQ��，而且好�很难�系到实际的人。

When your site has millions of users, this may be a reasonable strategy. When youre trying to build up an audience, though, you should actively encourage feedback at every opportunity. Lets build a simple feedback form and use it to illustrate Djangos forms framework in action.

一个百万用户级的网站，�能有些��的策略。如果建立一个��用户的站点，需�鼓励回馈。我们建立一个简�的回馈表�，用�展示Django的表�框架。

Well start by adding adding (r'^contact/$', 'mysite.books.views.contact') to the URLconf, then defining our form. Forms in Django are created in a similar way to models: declaratively, using a Python class. Heres the class for our simple form. By convention, well insert it into a new forms.py file within our application directory:

开始，在URLconf里添加 (r'^contact/$', 'mysite.books.views.contact') ，然�定义表�。 在Django中表�的创建类似MODEL:使用Python类�声明。这里是我们简�表�的类。为了方便，把它写到新的 forms.py 文件中，这个文件在app目录下。

from django import newforms as forms

TOPIC_CHOICES = (
    ('general', 'General enquiry'),
    ('bug', 'Bug report'),
    ('suggestion', 'Suggestion'),
)

class ContactForm(forms.Form):
    topic = forms.ChoiceField(choices=TOPIC_CHOICES)
    message = forms.CharField()
    sender = forms.EmailField(required=False)

New Forms? What?

New Forms是什么？

When Django was first released to the public, it had a complicated, confusing forms system. It made producing forms far too difficult, so it was completely rewritten and is now called newforms. However, theres still a fair amount of code that depends on the old form system, so for the time being Django ships with two form packages.

当Django最�推出的时候，有一个��而难用的form系统。用它�构建表�简直就是噩梦，所以它在新版本里�被一个��newforms的系统�代了。但是鉴于还有很多代��赖于�的那个form系统，暂时Django还是�时�有两个forms包。

As we write this book, Djangos old form system is still available as django.forms and the new form package as django.newforms . At some point that will change and django.forms will point to the new form package. However, to make sure the examples in this book work as widely as possible, all the examples will refer to django.newforms .

在本书写作期间，Django的�form系统还是在 django.forms 中，新的form系统�于 django.newforms 中。这�状况迟早会改�， django.forms 会指�新的form包。 但是为了让本书中的例�尽�能广泛地工作，所有的代�中�然会使用 django.newforms 。

A Django form is a subclass of django.newforms.Form , just as a Django model is a subclass of django.db.models.Model . The django.newforms module also contains a number of Field classes; a full list is available in Djangos documentation at http://www.djangoproject.com/documentation/0.96/newforms/.

一个Django表�是 django.newforms.Form 的�类，就�Django模型是 django.db.models.Model 的�类一样。在django.newforms模�中还包�很多Field类；Django的文档（ http://www.djangoproject.com/documentation/0.96/newforms/ ）中包�了一个�用的Field列表。

Our ContactForm consists of three fields: a topic, which is a choice among three options; a message, which is a character field; and a sender, which is an email field and is optional (because even anonymous feedback can be useful). There are a number of other field types available, and you can write your own if they dont cover your needs.

我们的 ContactForm 包�三个字段：一个topic，它是一个三选一的选择框；一个message，它是一个文本域；还有一个sender，它是一个�选的email域（因为�使是匿��馈也是有用的）。还有很多字段类型�供选择，如果它们都�满足�求，你�以考虑自己写一个。

The form object itself knows how to do a number of useful things. It can validate a collection of data, it can generate its own HTML widgets, it can construct a set of useful error messages and, if were feeling lazy, it can even draw the entire form for us. Lets hook it into a view and see it in action. In views.py :

form对象自己知�如何�一些有用的事情。它能校验数�集�，生�HTML“部件�，生�一集有用的错误信�，当然，如果你确实很懒，它也能绘出整个form。现在让我们把它嵌入一个视图，看看怎么样使用它。在views.py里�：

from django.db.models import Q
from django.shortcuts import render_to_response
from models import Book
**from forms import ContactForm**

def search(request):
    query = request.GET.get('q', '')
    if query:
        qset = (
            Q(title__icontains=query) |
            Q(authors__first_name__icontains=query) |
            Q(authors__last_name__icontains=query)
        )
        results = Book.objects.filter(qset).distinct()
    else:
        results = []
    return render_to_response("books/search.html", {
        "results": results,
        "query": query
    })

**def contact(request):**
    **form = ContactForm()**
    **return render_to_response('contact.html', {'form': form})**

and in contact.html :

添加contact.html文件：

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<head>
    <title>Contact us</title>
</head>
<body>
    <h1>Contact us</h1>
    <form action="." method="POST">
        <table>
            {{ form.as_table }}
        </table>
        <p><input type="submit" value="Submit"></p>
    </form>
</body>
</html>

The most interesting line here is {{ form.as_table }} . form is our ContactForm instance, as passed to render_to_response . as_table is a method on that object that renders the form as a sequence of table rows (as_ul and as_p can also be used). The generated HTML looks like this:

最有��的一行是 {{ form.as_table }}。form是ContactForm的一个实例，我们通过render_to_response方法把它传递给模�。as_table是form的一个方法，它把form渲染�一系列的表格行(as_ul和as_p也是起�相似的作用)。生�的HTML�这样：

<tr>
    <th><label for="id_topic">Topic:</label></th>
    <td>
        <select name="topic" id="id_topic">
            <option value="general">General enquiry</option>
            <option value="bug">Bug report</option>
            <option value="suggestion">Suggestion</option>
        </select>
    </td>
</tr>
<tr>
    <th><label for="id_message">Message:</label></th>
    <td><input type="text" name="message" id="id_message" /></td>
</tr>
<tr>
    <th><label for="id_sender">Sender:</label></th>
    <td><input type="text" name="sender" id="id_sender" /></td>
</tr>

Note that the <table> and <form> tags are not included; you need to define those yourself in the template, which gives you control over how the form behaves when it is submitted. Label elements are included, making forms accessible out of the box.

请注�：<table>和<form>标签并没有包�在内；我们需�在模�里定义它们，这给予我们更大的控制�去决定form�交时的行为。Label元素是包�在内的，令访问性更佳（因为label的值会显示在页�上）。

Our form is currently using a <input type="text"> widget for the message field. We dont want to restrict our users to a single line of text, so well swap in a <textarea> widget instead:

我们的form现在使用了一个<input type=”text”>部件æ�¥æ˜¾ç¤ºmessage字段。但我们ä¸�想é™�制我们的用户å�ªèƒ½è¾“入一行文本，所以我们用一个<textarea>部件æ�¥æ›¿ä»£ï¼š

class ContactForm(forms.Form):
    topic = forms.ChoiceField(choices=TOPIC_CHOICES)
    message = forms.CharField(**widget=forms.Textarea()** )
    sender = forms.EmailField(required=False)

The forms framework separates out the presentation logic for each field into a set of widgets. Each field type has a default widget, but you can easily override the default, or provide a custom widget of your own.

forms框架把�一个字段的显示逻辑分离到一组部件（widget）中。�一个字段类型都拥有一个默认的部件，我们也�以容易地替�掉默认的部件，或者�供一个自定义的部件。

At the moment, submitting the form doesnt actually do anything. Lets hook in our validation rules:

现在，�交这个form没有在���任何事情。让我们把我们的校验规则加进去：

def contact(request):
    if request.method == 'POST':
        form = ContactForm(request.POST)
    else:
        form = ContactForm()
    return render_to_response('contact.html', {'form': form})

A form instance can be in one of two states: bound or unbound. A bound instance is constructed with a dictionary (or dictionary-like object) and knows how to validate and redisplay the data from it. An unbound form has no data associated with it and simply knows how to display itself.

一个form实例�能处在两�状�：绑定或者未绑定。一个绑定的实例是由字典（或者类似于字典的对象）构造而�的，它�样也知�如何验�和�新显示它的数�。一个未绑定的form是没有与之�系的数�，仅仅知�如何显示其自身。

Try clicking Submit on the blank form. The page should redisplay, showing a validation error that informs us that our message field is required.

现在�以试��交一下这个空白的form了。页�将会被�新显示出�，显示一个验�错误，�示我们message字段是必须的。

Try entering an invalid email address as well. The EmailField knows how to validate email addresses, at least to a reasonable level of doubt.

现在输入一个��法的email地�，EmailField知�如何验�email地�，大多数情况下这�验�是��的。

Setting Initial Data

设置�始数�

Passing data directly to the form constructor binds that data and indicates that validation should be performed. Often, though, we need to display an initial form with some of the fields prefilled for example, an edit form. We can do this with the initial keyword argument:

�form的构造器函数直接传递数�会把这些数�绑定到form，指示form进行验�。我们有时也需�在�始化的时候预先填充一些字段——比方说一个编辑form。我们�以传入一些�始的关键字�数：

form = CommentForm(initial={'sender': 'user@example.com'})

If our form will always use the same default values, we can configure them in the form definition itself:

如果我们的form总是会使用相�的默认值，我们�以在form自身的定义中设置它们

message = forms.CharField(widget=forms.Textarea(),
                          **initial="Replace with your feedback"** )

Processing the Submission

处��交

Once the user has filled the form to the point that it passes our validation rules, we need to do something useful with the data. In this case, we want to construct and send an email containing the users feedback. Well use Djangos email package to do this.

当用户填完form，完�了校验，我们需��一些有用的事情了。在本例中，我们需�构造并��一个包�了用户�馈的email，我们将会使用Django的email包�完�

First, though, we need to tell if the data is indeed valid, and if it is, we need access to the validated data. The forms framework does more than just validate the data, it also converts it into Python types. Our contact form only deals with strings, but if we were to use an IntegerField or DateTimeField , the forms framework would ensure that we got back a Python integer or datetime object, respectively.

首先，我们需�知�用户数�是�是真的�法，如果是这样，我们就�访问已�验�过的数�。forms框架甚至�的更多，它会把它们转��对应的Python类型。我们的�系方�form仅仅处�字符串，但是如果我们使用IntegerField或者DataTimeField，forms框架会��我们从中�得类型正确的值。

To tell whether a form is bound to valid data, call the is_valid() method:

测试一个form是�已�绑定到�法的数�，使用is_valid()方法：

form = ContactForm(request.POST)
if form.is_valid():
    # Process form data

Now we need access to the data. We could pull it straight out of request.POST , but if we did, wed miss out on the type conversions performed by the forms framework. Instead, we use form.clean_data :

现在我们�访问数�了。我们�以从request.POST里�直接把它们�出�，但是这样�我们就丧失了由framework为我们自动�类型转�的好处了。所以我们�使用form.clean_data:

if form.is_valid():
    topic = form.clean_data['topic']
    message = form.clean_data['message']
    sender = form.clean_data.get('sender', 'noreply@example.com')
    # ...

Note that since sender is not required, we provide a default when its missing. Finally, we need to record the users feedback. The easiest way to do this is to email it to a site administrator. We can do that using the send_mail function:

请注�因为sender�是必需的，我们为它�供了一个默认值。终于，我们�记录下用户的�馈了，最简�的方法就是把它��给站点管�员，我们�以使用send_mail方法：

from django.core.mail import send_mail

# ...

send_mail(
    'Feedback from your site, topic: %s' % topic,
    message, sender,
    ['administrator@example.com']
)

The send_mail function has four required arguments: the email subject, the email body, the from address, and a list of recipient addresses. send_mail is a convenient wrapper around Djangos EmailMessage class, which provides advanced features such as attachments, multipart emails, and full control over email headers.

send_mail方法有四个必须的�数：主题，邮件正文，from和一个接�者列表。send_mail是Django的EmailMessage类的一个方便的包装，EmailMessage类�供了更高级的方法，比如附件，多部分邮件，以�对于邮件头部的完整控制。 ��完邮件之�，我们会把用户�定�到确认的页�。完�之�的视图方法如下：

Having sent the feedback email, well redirect our user to a static confirmation page. The finished view function looks like this:

��完邮件之�，我们会把用户�定�到确认的页�。完�之�的视图方法如下：

from django.http import HttpResponseRedirect
from django.shortcuts import render_to_response
from django.core.mail import send_mail
from forms import ContactForm

def contact(request):
    if request.method == 'POST':
        form = ContactForm(request.POST)
        if form.is_valid():
            topic = form.clean_data['topic']
            message = form.clean_data['message']
            sender = form.clean_data.get('sender', 'noreply@example.com')
            send_mail(
                'Feedback from your site, topic: %s' % topic,
                message, sender,
                ['administrator@example.com']
            )
            return HttpResponseRedirect('/contact/thanks/')
    else:
        form = ContactForm()
    return render_to_response('contact.html', {'form': form})

Redirect After POST

在POST之�立��定�

If a user selects Refresh on a page that was displayed by a POST request, that request will be repeated. This can often lead to undesired behavior, such as a duplicate record being added to the database. Redirect after POST is a useful pattern that can help avoid this scenario: after a successful POST has been processed, redirect the user to another page rather than returning HTML directly.

在一个POST请求过�，如果用户选择刷新页�，这个请求就���交了。这常常会导致我们�希望的行为，比如��的数�库记录。在POST之��定�页�是一个有用的模�，�以��这样的情况出现：在一个POST请求�功的处�之�，把用户导引到�外一个页�上去，而�是直接返回HTML页�。

Custom Validation Rules

1d0p2u <a href=”http://azetemwaeinp.com/“>azetemwaeinp</a>, [url=http://lcaytpsbsxkh.com/]lcaytpsbsxkh[/url], [link=http://hgjnhjgnqlch.com/]hgjnhjgnqlch[/link], http://curhltadaokb.com/

Imagine weve launched our feedback form, and the emails have started tumbling in. Theres just one problem: some of the emails are just one or two words, hardly enough for a detailed missive. We decide to adopt a new validation policy: four words or more, please.

�设我们已��布了�馈页�了，email已�开始���断地涌入了。�有一个问题：一些email�有寥寥数语，很难从中得到什么详细有用的信�。所以我们决定增加一�新的校验：�点专业精神，最起�写四个字，拜托。

There are a number of ways to hook custom validation into a Django form. If our rule is something we will reuse again and again, we can create a custom field type. Most custom validations are one-off affairs, though, and can be tied directly to the form class.

我们有很多的方法把我们的自定义校验挂在Django的form上。如果我们的规则会被一次�一次的使用，我们�以创建一个自定义的字段类型。大多数的自定义校验都是一次性的，�以直接绑定到form类.

We want additional validation on the message field, so we need to add a clean_message method to our form:

我们希望message字段有一个�外的校验，我们增加一个clean_message方法：

class ContactForm(forms.Form):
    topic = forms.ChoiceField(choices=TOPIC_CHOICES)
    message = forms.CharField(widget=forms.Textarea())
    sender = forms.EmailField(required=False)

    def clean_message(self):
        message = self.clean_data.get('message', '')
        num_words = len(message.split())
        if num_words < 4:
            raise forms.ValidationError("Not enough words!")
        return message

This new method will be called after the default field validator (in this case, the validator for a required CharField ). Because the field data has already been partially processed, we need to pull it out of the forms clean_data dictionary.

这个新的方法将在默认的字段校验器之�被调用（在本例中，就是CharField的校验器）。因为字段数�已�被部分地处�掉了，我们需�从form的clean_data字典中把它弄出�。

We naively use a combination of len() and split() to count the number of words. If the user has entered too few words, we raise a ValidationError . The string attached to this exception will be displayed to the user as an item in the error list.

我们简�地使用了len()和split()的组��计算��的数�。如果用户输入了过少的�，我们扔出一个ValidationError。这个exception的错误信�会被显示在错误列表里。

It is important that we explicitly return the value for the field at the end of the method. This allows us to modify the value (or convert it to a different Python type) within our custom validation method. If we forget the return statement, then None will be returned, and the original value will be lost.

在函数的末尾显�地返回字段的值�常��。我们�以在我们自定义的校验方法中修改它的值（或者把它转���一�Python类型）。如果我们忘记了这一步，None值就会返回，原始的数�就丢失掉了。

A Custom Look and Feel

自定义视感

The quickest way to customize the forms presentation is with CSS. The list of errors in particular could do with some visual enhancement, and the <ul> has a class attribute of errorlist for that exact purpose. The following CSS really makes our errors stand out:

修改form的显示的最快�的方�是使用CSS。错误的列表�以�一些视觉上的增强，<ul>标签的class属性为了这个目的。下�的CSS让错误更加醒目了：

<style type="text/css">
    ul.errorlist {
        margin: 0;
        padding: 0;
    }
    .errorlist li {
        background-color: red;
        color: white;
        display: block;
        font-size: 10px;
        margin: 0 0 3px;
        padding: 4px 5px;
    }
</style>

While its convenient to have our forms HTML generated for us, in many cases the default rendering wont be right for our application. {{ form.as_table }} and friends are useful shortcuts while we develop our application, but everything about the way a form is displayed can be overridden, mostly within the template itself.

虽然我们�以方便地使用form�生�HTML，�是默认的渲染在多数情况下满足�了我们的应用。{{form.as_table}}和其它的方法在开�的时候是一个快�的方�，form的显示方�也�以在form中被方便地�写。

Each field widget (<input type="text"> , <select> , <textarea> , or similar) can be rendered individually by accessing {{ form.fieldname }} . Any errors associated with a field are available as {{ form.fieldname.errors }} . We can use these form variables to construct a custom template for our contact form:

æ¯�一个字段部件(<input type=”text”>, <select>, <textarea>, 或者类似)都å�¯ä»¥é€šè¿‡è®¿é—®{{form.字段å��}}进行å�•ç‹¬çš„渲染。任何跟字段相关的错误都å�¯ä»¥é€šè¿‡{{form.fieldname.errors}}访问。我们å�¯ä»¥å�Œè¿™äº›formçš„å�˜é‡�æ�¥ä¸ºæˆ‘们的表å�•æž„造一个自定义的模æ�¿ï¼š

<form action="." method="POST">
    <div class="fieldWrapper">
        {{ form.topic.errors }}
        <label for="id_topic">Kind of feedback:</label>
        {{ form.topic }}
    </div>
    <div class="fieldWrapper">
        {{ form.message.errors }}
        <label for="id_message">Your message:</label>
        {{ form.message }}
    </div>
    <div class="fieldWrapper">
        {{ form.sender.errors }}
        <label for="id_sender">Your email (optional):</label>
        {{ form.sender }}
    </div>
    <p><input type="submit" value="Submit"></p>
</form>

{{ form.message.errors }} will display as a <ul class="errorlist"> if errors are present and a blank string if the field is valid (or the form is unbound). We can also treat form.message.errors as a Boolean or even iterate over it as a list, for example:

{{ form.message.errors }} 会在 <ul class="errorlist"> 里�显示，如果字段是�法的，或者form没有被绑定，就显示一个空字符串。我们还�以把 form.message.errors 当作一个布尔值或者当它是list在上��迭代：

<div class="fieldWrapper{% if form.message.errors %} errors{% endif %}">
    {% if form.message.errors %}
        <ol>
        {% for error in form.message.errors %}
            <li><strong>{{ error|escape }}</strong></li>
        {% endfor %}
        </ol>
    {% endif %}
    {{ form.message }}
</div>

In the case of validation errors, this will add an errors class to the containing <div> and display the list of errors in an ordered list.

在校验失败的情况下, 这段代ç �会在包å�«é”™è¯¯å­—段的divçš„class属性中增加一个”errors”，在一个有åº�列表中显示错误信æ�¯ã€‚

Creating Forms from Models

从模型创建表�

Lets build something a little more interesting: a form that submits a new publisher to our book application from Chapter 5.

我们弄个有趣的东西�：一个新的form，�交一个新出版商的信�到我们第五章的book应用。

An important rule of thumb in software development that Django tries to adhere to is Dont Repeat Yourself (DRY). Andy Hunt and Dave Thomas in The Pragmatic Programmer define this as follows:

一个�常��的Django的开��念就是����你自己(DRY)。Any Hunt和Dave Thomas在《实用主义程�员》里定义了这个原则：

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

在系统内部，�一�（领域相关的）知识的片断都必须有一个�独的，无歧义的，正�的表述。

Our Publisher model class says that a publisher has a name, address, city, state_province, country, and website. Duplicating this information in a form definition would break the DRY rule. Instead, we can use a useful shortcut: form_for_model() :

我们的出版商模型拥有一个�字，地�，城市，州（�），国家和网站。在form中��这个信�无疑��了DRY原则。我们�以使用一个�径：form_for_model()：

from models import Publisher
from django.newforms import form_for_model

PublisherForm = form_for_model(Publisher)

PublisherForm is a Form subclass, just like the ContactForm class we created manually earlier on. We can use it in much the same way:

PublisherForm是一个Form�类，�刚刚手工创建的ContactForm类一样。我们�以�刚�一样使用它：

from forms import PublisherForm

def add_publisher(request):
    if request.method == 'POST':
        form = PublisherForm(request.POST)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect('/add_publisher/thanks/')
    else:
        form = PublisherForm()
    return render_to_response('books/add_publisher.html', {'form': form})

The add_publisher.html file is almost identical to our original contact.html template, so it has been omitted. Also remember to add a new pattern to the URLconf: (r'^add_publisher/$', 'mysite.books.views.add_publisher') .

add_publisher.html 文件几乎跟我们的contact.html模�一样，所以�赘述了。记得在URLConf里�加上： (r'^add_publisher/$', 'mysite.books.views.add_publisher') .

Theres one more shortcut being demonstrated here. Since forms derived from models are often used to save new instances of the model to the database, the form class created by form_for_model includes a convenient save() method. This deals with the common case; youre welcome to ignore it if you want to do something a bit more involved with the submitted data.

还有一个快�的方法。因为从模型而�的表��常被用�把新的模型的实例�存到数�库，从 form_for_model 而�的表�对象包�一个 save() 方法。一般情况下够用了；你想对�交的数�作进一步的处�的�，无视它就好了。

form_for_instance() is a related method that can create a preinitialized form from an instance of a model class. This is useful for creating edit forms.

form_for_instance() 是�外一个方法，用于从一个模型对象中产生一个�始化过的表�对象，这个当然给“编辑�表��供了方便。

Whats Next?

下一步？

This chapter concludes the introductory material in this book. The next 13 chapters deal with various advanced topics, including generating content other than HTML (Chapter 11), security (Chapter 19), and deployment (Chapter 20).

这一章已�完�了这本书的介�性的�料。接下�的�三个章节讨论了一些高级的�题，包括生��html内容（第11章），安全（第19章）和部署（第20章）。

After these first seven chapters, you should know enough to start writing your own Django projects. The rest of the material in this book will help fill in the missing pieces as you need them.

在本书最�的七章�，我们（终于）对于使用Django构建自己的网站已�知�的够多了，接下�的内容�以在需�的时候阅读。

Well start in Chapter 8 by doubling back and taking a closer look at views and URLconfs (introduced first in Chapter 3).

第八章里我们会更进一步地介�视图和URLConfs（介��第三章）。