| ID | English原文 | 中文翻译 | 最近翻译记录 | 状态 | 操作 |
|---|---|---|---|---|---|
| 0#翻译 | Chapter 11: | 第11章 | 翻译 | ||
| 1#翻译 | Generic Views | 通用视图 | 翻译 | ||
| 4#翻译 | Here again is a recurring theme of this book: | 这里需要再次回到本书的主题: | 翻译 | ||
| 5#翻译 | at its worst, Web development is boring and monotonous. | 在最坏的情况下, Web 开发是一项无聊而且单调的工作。 | 翻译 | ||
| 6#翻译 | So far, we've covered how Django tries to take away some of that monotony at the model and template layers, but Web developers also experience this boredom at the view level. | 到目前为止,我们已经介绍了 Django 怎样在模型和模板的层面上减小开发的单调性,但是 Web 开发在视图的层面上,也经历着这种令人厌倦的事情。 | 翻译 | ||
| 8#翻译 | Django's <emphasis>generic views</emphasis> were developed to ease that pain. | Django的<emphasis>通用视图</emphasis> 可以减少这些痛苦。 | 翻译 | ||
| 9#翻译 | They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to write too much code. | 它抽象出一些在视图开发中常用的代码和模式,这样就可以在无需编写大量代码的情况下,快速编写出常用的数据视图。 | 翻译 | ||
| 10#翻译 | In fact, nearly every view example in the preceding chapters could be rewritten with the help of generic views. | 事实上,前面章节中的几乎所有视图的示例都可以在通用视图的帮助下重写。 | 翻译 | ||
| 12#翻译 | Chapter 8 touched briefly on how you'd go about making a view generic. | 在第八章简单的向大家介绍了怎样使视图更加的“通用”。 | 翻译 | ||
| 13#翻译 | To review, we can recognize certain common tasks, like displaying a list of objects, and write code that displays a list of <emphasis>any</emphasis> object. | 回顾一下,我们会发现一些比较常见的任务,比如显示一系列对象,写一段代码来显示 <emphasis>任何</emphasis> 对象内容。 | 翻译 | ||
| 14#翻译 | Then the model in question can be passed as an extra argument to the URLconf. | 解决办法就是传递一个额外的参数到URLConf。 | 翻译 | ||
| 16#翻译 | Django ships with generic views to do the following: | Django内建通用视图可以实现如下功能: | 翻译 | ||
| 18#翻译 | Perform common simple tasks: | 完成常用的简单任务: | 翻译 | ||
| 19#翻译 | redirect to a different page, or render a given template. | 重定向到另一个页面以及渲染一个指定的模板。 | 翻译 | ||
| 21#翻译 | Display list and detail pages for a single object. | 显示列表和某个特定对象的详细内容页面。 | 翻译 | ||
| 22#翻译 | The <literal>event_list</literal> and <literal>entry_list</literal> views from Chapter 8 are examples of list views. | 第8章中提到的 <literal>event_list</literal> 和 <literal>entry_list</literal> 视图就是列表视图的一个例子。 | 翻译 | ||
| 23#翻译 | A single event page is an example of what we call a detail view. | 一个单一的 event 页面就是我们所说的详细内容页面。 | 翻译 | ||
| 25#翻译 | Present date-based objects in year/month/day archive pages, associated detail, and latest pages. | 呈现基于日期的数据的年/月/日归档页面,关联的详情页面,最新页面。 | 翻译 | ||
| 26#翻译 | The Django Weblog's (<reference name="http://www.djangoproject.com/weblog/" refuri="http://www.djangoproject.com/weblog/">http://www.djangoproject.com/weblog/</reference>) year, month, and day archives are built with these, as would be a typical newspaper's archives. | Django Weblogs (<reference name="http://www.djangoproject.com/weblog/" refuri="http://www.djangoproject.com/weblog/">http://www.djangoproject.com/weblog/</reference>)的年、月、日的归档就是使用通用视图 架构的,就像是典型的新闻报纸归档。 | 翻译 | ||
| 28#翻译 | Taken together, these views provide easy interfaces to perform the most common tasks developers encounter. | 综上所述,这些视图为开发者日常开发中常见的任务提供了易用的接口。 | 翻译 | ||
| 30#翻译 | Using Generic Views | 使用通用视图 | 翻译 | ||
| 32#翻译 | All of these views are used by creating configuration dictionaries in your URLconf files and passing those dictionaries as the third member of the URLconf tuple for a given pattern. | 使用通用视图的方法是在URLconf文件中创建配置字典,然后把这些字典作为URLconf元组的第三个成员。 | 翻译 | ||
| 33#翻译 | (See Passing Extra Options to View Functions in Chapter 8 for an overview of this technique.) | (对于这个技巧的应用可以参看第八章向视图传递额外选项。) | 翻译 | ||
| 35#翻译 | For example, here's a simple URLconf you could use to present a static about page: | 例如,下面是一个呈现静态“关于”页面的URLconf: | 翻译 | ||
| 38#翻译 | Though this might seem a bit magical at first glance look, a view with no code! | 一眼看上去似乎有点不可思议,不需要编写代码的视图! | 翻译 | ||
| 39#翻译 | , it's actually exactly the same as the examples in Chapter 8: the <literal>direct_to_template</literal> view simply grabs information from the extra-parameters dictionary and uses that information when rendering the view. | 它和第八章中的例子完全一样:<literal>direct_to_template</literal>视图仅仅是直接从传递过来的额外参数获取信息并用于渲染视图。 | 翻译 | ||
| 41#翻译 | Because this generic view and all the others is a regular view function like any other, we can reuse it inside our own views. | 因为通用视图都是标准的视图函数,我们可以在我们自己的视图中重用它。 | 翻译 | ||
| 42#翻译 | As an example, let's extend our about example to map URLs of the form <literal>/about/<whatever>/</literal> to statically rendered <literal>about/<whatever>.html</literal> . We'll do this by first modifying the URLconf to point to a view function: | 例如,我们扩展 about例子,把映射的URL从 <literal>/about//</literal>修改到一个静态渲染 <literal>about/.html</literal> 。 我们首先修改URL配置以指向新的视图函数: | 翻译 | ||
| 45#翻译 | Next, we'll write the <literal>about_pages</literal> view: | 接下来,我们编写 <literal>about_pages</literal> 视图的代码: | 翻译 | ||
| 48#翻译 | Here we're treating <literal>direct_to_template</literal> like any other function. | 在这里我们象使用其他函数一样使用 <literal>direct_to_template</literal> 。 | 翻译 | ||
| 49#翻译 | Since it returns an <literal>HttpResponse</literal> , we can simply return it as-is. | 因为它返回一个<literal>HttpResponse</literal>对象,我们只需要简单的返回它就好了。 | 翻译 | ||
| 50#翻译 | The only slightly tricky business here is dealing with missing templates. | 这里唯一有点棘手的事情是要处理找不到模板的情况。 | 翻译 | ||
| 51#翻译 | We don't want a nonexistent template to cause a server error, so we catch <literal>TemplateDoesNotExist</literal> exceptions and return 404 errors instead. | 我们不希望一个不存在的模板导致一个服务端错误,所以我们捕获TemplateDoesNotExist异常并且返回404错误来作为替代。 | 翻译 | ||
| 53#翻译 | Is There a Security Vulnerability Here? | 这里有没有安全性问题? | 翻译 | ||
| 55#翻译 | Sharp-eyed readers may have noticed a possible security hole: | 眼尖的读者可能已经注意到一个可能的安全漏洞: | 翻译 | ||
| 56#翻译 | we're constructing the template name using interpolated content from the browser (<literal>template="about/%s.html" % page</literal> ). At first glance, this looks like a classic <emphasis>directory traversal</emphasis> vulnerability (discussed in detail in Chapter 20). | 我们直接使用从客户端浏览器得到的数据构造模板名称(<literal>template="about/%s.html" % page</literal> )。乍看起来,这像是一个经典的 <emphasis>目录跨越(directory traversal)</emphasis> 攻击(详情请看第20章)。 | 翻译 | ||
| 57#翻译 | But is it really? | 事实真是这样吗? | 翻译 | ||
| 59#翻译 | Not exactly. | 完全不是。 | 翻译 | ||
| 60#翻译 | Yes, a maliciously crafted value of <literal>page</literal> could cause directory traversal, but although <literal>page</literal> | 是的,一个恶意的 <literal>page</literal> 值可以导致目录跨越,但是尽管 <literal>page</literal> | 翻译 | ||
| 61#翻译 | <emphasis>is</emphasis> taken from the request URL, not every value will be accepted. | <emphasis>是</emphasis> 从请求的URL中获取的,但并不是所有的值都会被接受。 | 翻译 | ||
| 62#翻译 | The key is in the URLconf: | 这就是URL配置的关键所在: | 翻译 | ||
| 63#翻译 | we're using the regular expression <literal>\w+</literal> to match the <literal>page</literal> part of the URL, and <literal>\w</literal> only accepts letters and numbers. | 我们使用正则表达式 <literal>\w+</literal> 来从URL里匹配 <literal>page</literal> ,而 <literal>\w</literal> 只接受字符和数字。 | 翻译 | ||
| 64#翻译 | Thus, any malicious characters (such as dots and slashes) will be rejected by the URL resolver before they reach the view itself. | 因此,任何恶意的字符 (例如在这里是点 <literal>.</literal> 和正斜线 <literal>/</literal> )将在URL解析时被拒绝,根本不会传递给视图函数。 | 翻译 | ||
| 66#翻译 | Generic Views of Objects | 对象的通用视图 | 翻译 | ||
| 68#翻译 | The <literal>direct_to_template</literal> view certainly is useful, but Django's generic views really shine when it comes to presenting views on your database content. | <literal>direct_to_template</literal> 毫无疑问是非常有用的,但Django通用视图最有用的地方是呈现数据库中的数据。 | 翻译 | ||
| 69#翻译 | Because it's such a common task, Django comes with a handful of built-in generic views that make generating list and detail views of objects incredibly easy. | 因为这个应用实在太普遍了,Django带有很多内建的通用视图来帮助你很容易 地生成对象的列表和明细视图。 | 翻译 | ||
| 71#翻译 | Let's take a look at one of these generic views: | 让我们先看看其中的一个通用视图: | 翻译 | ||
| 72#翻译 | the object list view. | 对象列表视图。 | 翻译 | ||
| 73#翻译 | We'll be using this <literal>Publisher</literal> object from Chapter 5: | 我们使用第五章中的 <literal>Publisher</literal> 来举例: | 翻译 | ||
| 76#翻译 | To build a list page of all publishers, we'd use a URLconf along these lines: | 要为所有的出版商创建一个列表页面,我们使用下面的URL配置: | 翻译 | ||
| 79#翻译 | That's all the Python code we need to write. | 这就是所要编写的所有Python代码。 | 翻译 | ||
| 80#翻译 | We still need to write a template, however. | 当然,我们还需要编写一个模板。 | 翻译 | ||
| 81#翻译 | We can explicitly tell the <literal>object_list</literal> view which template to use by including a <literal>template_name</literal> key in the extra arguments dictionary: | 我们可以通过在额外参数字典中包含一个<literal>template_name</literal>键来显式地告诉<literal>object_list</literal>视图使用哪个模板: | 翻译 | ||
| 84#翻译 | In the absence of <literal>template_name</literal> , though, the <literal>object_list</literal> generic view will infer one from the object's name. | 在缺少<literal>template_name</literal>的情况下,<literal>object_list</literal>通用视图将自动使用一个对象名称。 | 翻译 | ||
| 85#翻译 | In this case, the inferred template will be <literal>"books/publisher_list.html"</literal> the books part comes from the name of the app that defines the model, while the publisher bit is just the lowercased version of the model's name. | 在这个例子中,这个推导出的模板名称将是 <literal>"books/publisher_list.html"</literal> ,其中books部分是定义这个模型的app的名称, publisher部分是这个模型名称的小写。 | 翻译 | ||
| 87#翻译 | This template will be rendered against a context containing a variable called <literal>object_list</literal> that contains all the publisher objects. | 这个模板将按照 context 中包含的变量 <literal>object_list</literal> 来渲染,这个变量包含所有的书籍对象。 | 翻译 | ||
| 88#翻译 | A very simple template might look like the following: | 一个非常简单的模板看起来象下面这样: | 翻译 | ||
| 91#翻译 | (Note that this assumes the existence of a <literal>base.html</literal> template, as we provided in an example in Chapter 4.) | (注意,这里我们假定存在一个<literal>base.html</literal>模板,它和我们第四章中的一样。) | 翻译 | ||
| 93#翻译 | That's really all there is to it. | 这就是所有要做的事。 | 翻译 | ||
| 94#翻译 | All the cool features of generic views come from changing the info dictionary passed to the generic view. | 要使用通用视图酷酷的特性只需要修改参数字典并传递给通用视图函数。 | 翻译 | ||
| 95#翻译 | Appendix D documents all the generic views and all their options in detail; the rest of this chapter will consider some of the common ways you might customize and extend generic views. | 附录D是通用视图的完全参考资料;本章接下来的章节将讲到自定义和扩展通用视图的一些方法。 | 翻译 | ||
| 97#翻译 | Extending Generic Views | 扩展通用视图 | 翻译 | ||
| 99#翻译 | There's no question that using generic views can speed up development substantially. | 毫无疑问,使用通用视图可以充分加快开发速度。 | 翻译 | ||
| 100#翻译 | In most projects, however, there comes a moment when the generic views no longer suffice. | 然而,在多数的工程中,也会出现通用视图不能 满足需求的情况。 | 翻译 | ||
| 101#翻译 | Indeed, one of the most common questions asked by new Django developers is how to make generic views handle a wider array of situations. | 实际上,刚接触Django的开发者最常见的问题就是怎样使用通用视图来处理更多的情况。 | 翻译 | ||
| 103#翻译 | Luckily, in nearly every one of these cases, there are ways to simply extend generic views to handle a larger array of use cases. | 幸运的是,几乎每种情况都有相应的方法来简易地扩展通用视图以处理这些情况。 | 翻译 | ||
| 104#翻译 | These situations usually fall into a handful of patterns dealt with in the sections that follow. | 这时总是使用下面的 这些方法。 | 翻译 | ||
| 106#翻译 | Making Friendly Template Contexts | 制作友好的模板Context | 翻译 | ||
| 108#翻译 | You might have noticed that sample publisher list template stores all the books in a variable named <literal>object_list</literal> . While this works just fine, it isn't all that friendly to template authors: | 你也许已经注意到范例中的出版商列表模板在变量 <literal>object_list</literal> 里保存所有的书籍。这个方法工作的很好,只是对编写模板的人不太友好。 | 翻译 | ||
| 109#翻译 | they have to just know that they're dealing with books here. | 他们必须知道这里正在处理的是书籍。 | 翻译 | ||
| 110#翻译 | A better name for that variable would be <literal>publisher_list</literal> ; that variable's content is pretty obvious. | 更好的变量名应该是<literal>publisher_list</literal>,这样变量所代表的内容就显而易见了。 | 翻译 | ||
| 112#翻译 | We can change the name of that variable easily with the <literal>template_object_name</literal> argument: | 我们可以很容易地像下面这样修改 <literal>template_object_name</literal> 参数的名称: | 翻译 | ||
| 115#翻译 | In the template, the generic view will append <literal>_list</literal> to the <literal>template_object_name</literal> to create the variable name representing the list of items. | 在模板中,通用视图会通过在<literal>template_object_name</literal>后追加一个<literal>_list</literal>的方式来创建一个表示列表项目的变量名。 | 翻译 | ||
| 117#翻译 | Providing a useful <literal>template_object_name</literal> is always a good idea. | 使用有用的 <literal>template_object_name</literal> 总是个好想法。 | 翻译 | ||
| 118#翻译 | Your coworkers who design templates will thank you. | 你的设计模板的合作伙伴会感谢你的。 | 翻译 | ||
| 120#翻译 | Adding Extra Context | 添加额外的Context | 翻译 | ||
| 122#翻译 | Sometimes, you might need to present some extra information beyond that provided by the generic view. | 你常常需要呈现比通用视图提供的更多的额外信息。 | 翻译 | ||
| 123#翻译 | For example, think of showing a list of all the other publishers on each publisher detail page. | 例如,考虑一下在每个出版商的详细页面显示所有其他出版商列表。 | 翻译 | ||
| 124#翻译 | The <literal>object_detail</literal> generic view provides the publisher to the context, but it seems there's no way to get a list of <emphasis>all</emphasis> publishers in that template. | <literal>object_detail</literal> 通用视图为context提供了出版商信息,但是看起来没有办法在模板中 获取 <emphasis>所有</emphasis> 出版商列表。 | 翻译 | ||
| 126#翻译 | But there is: | 这是解决方法: | 翻译 | ||
| 127#翻译 | all generic views take an extra optional parameter, <literal>extra_context</literal> . This is a dictionary of extra objects that will be added to the template's context. | 所有的通用视图都有一个额外的可选参数 <literal>extra_context</literal> 。这个参数是一个字典数据类型,包含要添加到模板的context中的额外的对象。 | 翻译 | ||
| 128#翻译 | So, to provide the list of all publishers on the detail view, we'd use an info dictionary like this: | 所以要给视图提供所有出版商的列表,我们就用这样的info字典: | 翻译 | ||
| 131#翻译 | This would populate a <literal>{{ book_list }}</literal> variable in the template context. | 这样就把一个 <literal>{{ book_list }}</literal> 变量放到模板的context中。 | 翻译 | ||
| 132#翻译 | This pattern can be used to pass any information down into the template for the generic view. | 这个方法可以用来传递任意数据 到通用视图模板中去,非常方便。 | 翻译 | ||
| 133#翻译 | It's very handy. | 这是非常方便的 | 翻译 | ||
| 135#翻译 | However, there's actually a subtle bug here can you spot it? | 不过,这里有一个很隐蔽的BUG,不知道你发现了没有? | 翻译 | ||
| 137#翻译 | The problem has to do with when the queries in <literal>extra_context</literal> are evaluated. | 我们现在来看一下, <literal>extra_context</literal> 里包含数据库查询的问题。 | 翻译 | ||
| 138#翻译 | Because this example puts <literal>Book.objects.all()</literal> in the URLconf, it will be evaluated only once (when the URLconf is first loaded). | 因为在这个例子中,我们把 <literal>Publisher.objects.all()</literal> 放在URLconf中,它只会执行一次(当URLconf第一次加载的时候)。 | 翻译 | ||
| 139#翻译 | Once you add or remove publishers, you'll notice that the generic view doesn't reflect those changes until you reload the Web server (see Caching and QuerySets in Appendix C for more information about when <literal>QuerySet</literal> objects are cached and evaluated). | 当你添加或删除出版商,你会发现在重启Web服务器之前,通用视图不会反映出这些修改(有关QuerySet何时被缓存和赋值的更多信息请参考附录C中“缓存与查询集”一节)。 | 翻译 | ||
| 141#翻译 | Note | 备注 | 翻译 | ||
| 143#翻译 | This problem doesn't apply to the <literal>queryset</literal> generic view argument. | 这个问题不适用于通用视图的 <literal>queryset</literal> 参数。 | 翻译 | ||
| 144#翻译 | Since Django knows that particular QuerySet should <emphasis>never</emphasis> be cached, the generic view takes care of clearing the cache when each view is rendered. | 因为Django知道有些特别的 QuerySet <emphasis>永远不能</emphasis> 被缓存,通用视图在渲染前都做了缓存清除工作。 | 翻译 | ||
| 146#翻译 | The solution is to use a <emphasis>callback</emphasis> in <literal>extra_context</literal> instead of a value. | 解决这个问题的办法是在 <emphasis>extra_context</emphasis> 中用一个回调(callback)来代替使用一个变量。 | 翻译 | ||
| 147#翻译 | Any callable (i.e., a function) that's passed to <literal>extra_context</literal> will be evaluated when the view is rendered (instead of only once). | 任何传递给<literal>extra_context</literal>的可调用对象(例如一个函数)都会在每次视图渲染前执行(而不是只执行一次)。 | 翻译 | ||
| 148#翻译 | You could do this with an explicitly defined function: | 你可以象这样定义一个函数: | 翻译 | ||
| 151#翻译 | Or, you could use a less obvious but shorter version that relies on the fact that <literal>Book.objects.all</literal> is itself a callable: | 或者你可以使用另一个不是那么清晰但是很简短的方法,事实上 <literal>Publisher.objects.all</literal> 本身就是可以调用的: | 翻译 | ||
| 154#翻译 | Notice the lack of parentheses after <literal>Book.objects.all</literal> . This references the function without actually calling it (which the generic view will do later). | 注意 <literal>Book.objects.all</literal> 后面没有括号;这表示这是一个函数的引用,并没有真正调用它(通用视图将会在渲染时调用它)。 | 翻译 | ||
| 156#翻译 | Viewing Subsets of Objects | 显示对象的子集 | 翻译 | ||
| 158#翻译 | Now let's take a closer look at this <literal>queryset</literal> key we've been using all along. | 现在让我们来仔细看看这个 <literal>queryset</literal> 。 | 翻译 | ||
| 159#翻译 | Most generic views take one of these <literal>queryset</literal> arguments it's how the view knows which set of objects to display (see Selecting Objects in Chapter 5 for an introduction to <literal>QuerySet</literal> objects, and see Appendix B for the complete details). | 大多数通用视图有一个<literal>queryset</literal>参数,这个参数告诉视图要显示对象的集合 (有关QuerySet的解释请看第五章的 “选择对象”章节,详细资料请参看附录B)。 | 翻译 | ||
| 161#翻译 | To pick a simple example, we might want to order a list of books by publication date, with the most recent first: | 举一个简单的例子,我们打算对书籍列表按出版日期排序,最近的排在最前: | 翻译 | ||
| 164#翻译 | That's a pretty simple example, but it illustrates the idea nicely. | 这是一个相当简单的例子,但是很说明问题。 | 翻译 | ||
| 165#翻译 | Of course, you'll usually want to do more than just reorder objects. | 当然,你通常还想做比重新排序更多的事。 | 翻译 | ||
| 166#翻译 | If you want to present a list of books by a particular publisher, you can use the same technique: | 如果你想要呈现某个特定出版商出版的所有书籍列表,你可以使用同样的技术: | 翻译 | ||
| 169#翻译 | Notice that along with a filtered <literal>queryset</literal> , we're also using a custom template name. | 注意 在使用一个过滤的 <literal>queryset</literal> 的同时,我们还使用了一个自定义的模板名称。 | 翻译 | ||
| 170#翻译 | If we didn't, the generic view would use the same template as the vanilla object list, which might not be what we want. | 如果我们不这么做,通用视图就会用以前的模板,这可能不是我们想要的结果。 | 翻译 | ||
| 172#翻译 | Also notice that this isn't a very elegant way of doing publisher-specific books. | 同样要注意的是这并不是一个处理出版商相关书籍的最好方法。 | 翻译 | ||
| 173#翻译 | If we want to add another publisher page, we'd need another handful of lines in the URLconf, and more than a few publishers would get unreasonable. | 如果我们想要添加另一个 出版商页面,我们就得在URL配置中写URL配置,如果有很多的出版商,这个方法就不能 接受了。 | 翻译 | ||
| 174#翻译 | We'll deal with this problem in the next section. | 在接下来的章节我们将来解决这个问题。 | 翻译 | ||
| 176#翻译 | Complex Filtering with Wrapper Functions | 用函数包装来处理复杂的数据过滤 | 翻译 | ||
| 178#翻译 | Another common need is to filter the objects given in a list page by some key in the URL. | 另一个常见的需求是按URL里的关键字来过滤数据对象。 | 翻译 | ||
| 179#翻译 | Earlier we hard-coded the publisher's name in the URLconf, but what if we wanted to write a view that displayed all the books by some arbitrary publisher? | 之前,我们在URLconf中硬编码了出版商的名字,但是如果我们想用一个视图就显示某个任意指定的出版商的所有书籍,那该怎么办呢? | 翻译 | ||
| 180#翻译 | The solution is to wrap the <literal>object_list</literal> generic view to avoid writing a lot of code by hand. | 我们可以通过对 <literal>object_list</literal> 通用视图进行包装来避免 写一大堆的手工代码。 | 翻译 | ||
| 181#翻译 | As usual, we'll start by writing a URLconf: | 按惯例,我们先从写URL配置开始: | 翻译 | ||
| 184#翻译 | Next, we'll write the <literal>books_by_publisher</literal> view itself: | 接下来,我们写 <literal>books_by_publisher</literal> 这个视图: | 翻译 | ||
| 187#翻译 | This works because there's really nothing special about generic views they're just Python functions. | 这样写没问题,因为通用视图就是Python函数。 | 翻译 | ||
| 188#翻译 | Like any view function, generic views expect a certain set of arguments and return <literal>HttpResponse</literal> objects. | 和其他的视图函数一样,通用视图也是接受一些 参数并返回 <literal>HttpResponse</literal> 对象。 | 翻译 | ||
| 189#翻译 | Thus, it's incredibly easy to wrap a small function around a generic view that does additional work before (or after; see the next section) handing things off to the generic view. | 因此,通过包装通用视图函数可以做更多的事。 | 翻译 | ||
| 191#翻译 | Note | 注意 | 翻译 | ||
| 193#翻译 | Notice that in the preceding example we passed the current publisher being displayed in the <literal>extra_context</literal> . This is usually a good idea in wrappers of this nature; it lets the template know which parent object is currently being browsed. | 注意在前面这个例子中我们在 <literal>extra_context</literal>中传递了当前出版商这个参数。 | 翻译 | ||
| 195#翻译 | Performing Extra Work | 处理额外工作 | 翻译 | ||
| 197#翻译 | The last common pattern we'll look at involves doing some extra work before or after calling the generic view. | 我们再来看看最后一个常用模式: | 翻译 | ||
| 199#翻译 | Imagine we had a <literal>last_accessed</literal> field on our <literal>Author</literal> object that we were using to keep track of the last time anybody looked at that author. | 想象一下我们在 <literal>Author</literal> 对象里有一个 <literal>last_accessed</literal> 字段,我们用这个字段来记录最近一次对author的访问。 | 翻译 | ||
| 200#翻译 | The generic <literal>object_detail</literal> view, of course, wouldn't know anything about this field, but once again we could easily write a custom view to keep that field updated. | 当然通用视图 <literal>object_detail</literal> 并不能处理这个问题,但是我们仍然可以很容易地编写一个自定义的视图来更新这个字段。 | 翻译 | ||
| 202#翻译 | First, we'd need to add an author detail bit in the URLconf to point to a custom view: | 首先,我们需要在URL配置里设置指向到新的自定义视图: | 翻译 | ||
| 205#翻译 | Then we'd write our wrapper function: | 接下来写包装函数: | 翻译 | ||
| 208#翻译 | Note | 注意 | 翻译 | ||
| 210#翻译 | This code won't actually work unless you add a <literal>last_accessed</literal> field to your <literal>Author</literal> model and create a <literal>books/author_detail.html</literal> template. | 除非你添加 <literal>last_accessed</literal> 字段到你的 <literal>Author</literal> 模型并创建 <literal>books/author_detail.html</literal> 模板,否则这段代码不能真正工作。 | 翻译 | ||
| 212#翻译 | We can use a similar idiom to alter the response returned by the generic view. | 我们可以用同样的方法修改通用视图的返回值。 | 翻译 | ||
| 213#翻译 | If we wanted to provide a downloadable plain-text version of the list of authors, we could use a view like this: | 如果我们想要提供一个供下载用的 纯文本版本的author列表,我们可以用下面这个视图: | 翻译 | ||
| 216#翻译 | This works because the generic views return simple <literal>HttpResponse</literal> objects that can be treated like dictionaries to set HTTP headers. | 这个方法之所以工作是因为通用视图返回的 <literal>HttpResponse</literal> 对象可以象一个字典 一样的设置HTTP的头部。 | 翻译 | ||
| 217#翻译 | This <literal>Content-Disposition</literal> business, by the way, instructs the browser to download and save the page instead of displaying it in the browser. | 随便说一下,这个 <literal>Content-Disposition</literal> 的含义是 告诉浏览器下载并保存这个页面,而不是在浏览器中显示它。 | 翻译 | ||
| 219#翻译 | What's Next? | 下一章 | 翻译 | ||
| 221#翻译 | In this chapter we looked at only a couple of the generic views Django ships with, but the general ideas presented here should apply pretty closely to any generic view. | 在这一章我们只讲了Django带的通用视图其中一部分,不过这些方法也适用于其他的 通用视图。 | 翻译 | ||
| 222#翻译 | Appendix C covers all the available views in detail, and it's recommended reading if you want to get the most out of this powerful feature. | 附录C详细地介绍了所有可用的视图,如果你想了解这些强大的特性,推荐你阅读一下。 | 翻译 | ||
| 224#翻译 | This concludes the section of this book devoted to advanced usage. | 这本书的高级语法部分到此结束。 | 翻译 | ||
| 225#翻译 | In the <reference name="next chapter" refuri="../chapter12/">next chapter</reference>, we cover deployment of Django applications. | 在<reference name="next chapter" refuri="../chapter12/">下一章</reference>, 我们讲解了Django应用的部署。 | 翻译 |