| ID | English原文 | 中文翻译 | 最近翻译记录 | 状态 | 操作 |
|---|---|---|---|---|---|
| 0#翻译 | Chapter 8: Advanced Views and URLconfs | 第八章：高级视图和URL配置 | 翻译 | ||
| 3#翻译 | In <reference name="Chapter 3" refuri="../chapter03/">Chapter 3</reference>, we explained the basics of Django view functions and URLconfs. | 在<reference name="Chapter 3" refuri="../chapter03/">第三章</reference> ，我们已经对基本的Django视图功能和URL配置做了介绍。 | 翻译 | ||
| 4#翻译 | This chapter goes into more detail about advanced functionality in those two pieces of the framework. | 在这一章，将进一步说明框架中这两个部分的高级机能。 | 翻译 | ||
| 6#翻译 | URLconf Tricks | URLconf 技巧 | 翻译 | ||
| 8#翻译 | There's nothing special about URLconfs like anything else in Django, they're just Python code. | URLconf没什么特别的，就象 Django 中其它东西一样，它们只是 Python 代码。 | 翻译 | ||
| 9#翻译 | You can take advantage of this in several ways, as described in the sections that follow. | 你可以在几方面从中得到好处，正如下面所描述的。 | 翻译 | ||
| 11#翻译 | Streamlining Function Imports | 流线型化(Streamlining)函数导入 | 翻译 | ||
| 13#翻译 | Consider this URLconf, which builds on the example in Chapter 3: | 看下这个 URLconf，它是建立在第三章的例子上: | 翻译 | ||
| 16#翻译 | As explained in Chapter 3, each entry in the URLconf includes its associated view function, passed directly as a function object. | 正如第三章中所解释的，在 URLconf 中的每一个入口包括了它所关联的视图函数，直接传入了一个函数对象。 | 翻译 | ||
| 17#翻译 | This means it's necessary to import the view functions at the top of the module. | 这就意味着需要在模块开始处导入视图函数。 | 翻译 | ||
| 19#翻译 | But as a Django application grows in complexity, its URLconf grows, too, and keeping those imports can be tedious to manage. | 但随着 Django 应用变得复杂，它的 URLconf 也在增长，并且维护这些导入可能使得管理变麻烦。 | 翻译 | ||
| 20#翻译 | (For each new view function, you have to remember to import it, and the import statement tends to get overly long if you use this approach.) It's possible to avoid that tedium by importing the <literal>views</literal> module itself. | (对每个新的view函数，你不得不记住要导入它，并且采用这种方法会使导入语句将变得相当长。)可以通过导入 views 模块本身来避免这个麻烦。 | 翻译 | ||
| 21#翻译 | This example URLconf is equivalent to the previous one: | 下面例子的URLconf与前一个等价： | 翻译 | ||
| 24#翻译 | Django offers another way of specifying the view function for a particular pattern in the URLconf: | Django 还提供了另一种方法可以在 URLconf 中为某个特别的模式指定视图函数： | 翻译 | ||
| 25#翻译 | you can pass a string containing the module name and function name rather than the function object itself. | 你可以传入一个包含模块名和函数名的字符串，而不是函数对象本身。 | 翻译 | ||
| 26#翻译 | Continuing the ongoing example: | 继续示例: | 翻译 | ||
| 29#翻译 | (Note the quotes around the view names. | (注意视图名前后的引号。 | 翻译 | ||
| 30#翻译 | We're using <literal>'mysite.views.current_datetime'</literal> with quotes instead of <literal>mysite.views.current_datetime</literal> .) | 应该使用带引号的 <literal>'mysite.views.current_datetime'</literal> 而不是 <literal>mysite.views.current_datetime</literal> 。) | 翻译 | ||
| 32#翻译 | Using this technique, it's no longer necessary to import the view functions; Django automatically imports the appropriate view function the first time it's needed, according to the string describing the name and path of the view function. | 使用这个技术，就不必导入视图函数了；Django 会在第一次需要它时根据字符串所描述的视图函数的名字和路径，导入合适的视图函数。 | 翻译 | ||
| 34#翻译 | A further shortcut you can take when using the string technique is to factor out a common view prefix. | 当使用字符串技术时，你可以采用更简化的方式：提取出一个公共视图前缀。 | 翻译 | ||
| 35#翻译 | In our URLconf example, each of the view strings starts with <literal>'mysite.views'</literal> , which is redundant to type. | 在我们的URLconf例子中，每个视图字符串的开始部分都是<literal>mysite.views</literal>，造成重复输入。 | 翻译 | ||
| 36#翻译 | We can factor out that common prefix and pass it as the first argument to <literal>patterns()</literal> , like this: | 我们可以把公共的前缀提取出来，作为第一个参数传给<literal>patterns()</literal>函数，像这样： | 翻译 | ||
| 39#翻译 | Note that you don't put a trailing dot (<literal>"."</literal> ) in the prefix, nor do you put a leading dot in the view strings. | 注意既不要在前缀后面跟着一个点号(<literal>"."</literal> )，也不要在视图字符串前面放一个点号。 | 翻译 | ||
| 40#翻译 | Django puts those in automatically. | Django 会自动处理它们。 | 翻译 | ||
| 42#翻译 | With these two approaches in mind, which is better? | 牢记这两种方法，哪种更好一些呢？ | 翻译 | ||
| 43#翻译 | It really depends on your personal coding style and needs. | 这取决于你的个人编码习惯和需要。 | 翻译 | ||
| 45#翻译 | Advantages of the string approach are as follows: | 字符串方法的好处如下: | 翻译 | ||
| 47#翻译 | It's more compact, because it doesn't require you to import the view functions. | 更紧凑，因为不需要你导入视图函数。 | 翻译 | ||
| 49#翻译 | It results in more readable and manageable URLconfs if your view functions are spread across several different Python modules. | 如果你的视图函数存在于几个不同的 Python 模块的话，它可以使得 URLconf 更易读和管理。 | 翻译 | ||
| 51#翻译 | Advantages of the function object approach are as follows: | 函数对象方法的好处如下: | 翻译 | ||
| 53#翻译 | It allows for easy wrapping of view functions. | 更容易对视图函数进行包装(wrap)。 | 翻译 | ||
| 54#翻译 | See the section Wrapping View Functions later in this chapter. | 参见本章后面的《包装视图函数》一节。 | 翻译 | ||
| 56#翻译 | It's more Pythonic that is, it's more in line with Python traditions, such as passing functions as objects. | 更 Pythonic，就是说，更符合 Python 的传统，如把函数当成对象传递。 | 翻译 | ||
| 58#翻译 | Both approaches are valid, and you can even mix them within the same URLconf. | 两个方法都是有效的，甚至你可以在同一个 URLconf 中混用它们。 | 翻译 | ||
| 59#翻译 | The choice is yours. | 决定权在你。 | 翻译 | ||
| 61#翻译 | Using Multiple View Prefixes | 使用多个视图前缀 | 翻译 | ||
| 63#翻译 | In practice, if you use the string technique, you'll probably end up mixing views to the point where the views in your URLconf won't have a common prefix. | 在实践中，如果你使用字符串技术，特别是当你的 URLconf 中没有一个公共前缀时，你最终可能混合视图。 | 翻译 | ||
| 64#翻译 | However, you can still take advantage of the view prefix shortcut to remove duplication. | 然而，你仍然可以利用视图前缀的简便方式来减少重复。 | 翻译 | ||
| 65#翻译 | Just add multiple <literal>patterns()</literal> objects together, like this: | 只要增加多个 <literal>patterns()</literal> 对象，象这样: | 翻译 | ||
| 67#翻译 | Old: | 旧的: | 翻译 | ||
| 70#翻译 | New: | 新的: | 翻译 | ||
| 73#翻译 | All the framework cares about is that there's a module-level variable called <literal>urlpatterns</literal> . This variable can be constructed dynamically, as we do in this example. | 整个框架关注的是存在一个名为 <literal>urlpatterns</literal> 的模块级别的变量。如上例，这个变量可以动态生成。 | 翻译 | ||
| 74#翻译 | We should specifically point out that the objects returned by <literal>patterns()</literal> can be added together, which is something you might not have expected. | 这里我们要特别说明一下，patterns()返回的对象是可相加的，这个特性可能是大家没有想到的。 | 翻译 | ||
| 76#翻译 | Special-Casing URLs in Debug Mode | 调试模式中的特例 | 翻译 | ||
| 78#翻译 | Speaking of constructing <literal>urlpatterns</literal> dynamically, you might want to take advantage of this technique to alter your URLconf's behavior while in Djangos debug mode. | 说到动态构建 <literal>urlpatterns</literal>，你可能想利用这一技术，在 Django 的调试模式下修改 URLconf 的行为。 | 翻译 | ||
| 79#翻译 | To do this, just check the value of the <literal>DEBUG</literal> setting at runtime, like so: | 为了做到这一点，只要在运行时检查 <literal>DEBUG</literal> 配置项的值即可，如: | 翻译 | ||
| 82#翻译 | In this example, the URL <literal>/debuginfo/</literal> will only be available if your <literal>DEBUG</literal> setting is set to <literal>True</literal> . | 在这个例子中，URL链接<literal>/debuginfo/</literal> 只在你的 <literal>DEBUG</literal> 配置项设为 <literal>True</literal> 时才有效。 | 翻译 | ||
| 84#翻译 | Using Named Groups | 使用命名组 | 翻译 | ||
| 86#翻译 | In all of our URLconf examples so far, we've used simple, <emphasis>non-named</emphasis> regular expression groups that is, we put parentheses around parts of the URL we wanted to capture, and Django passes that captured text to the view function as a positional argument. | 在目前为止的所有 URLconf 例子中，我们使用简单的<emphasis>无命名</emphasis> 正则表达式组，即，在我们想要捕获的URL部分上加上小括号，Django 会将捕获的文本作为位置参数传递给视图函数。 | 翻译 | ||
| 87#翻译 | In more advanced usage, it's possible to use <emphasis>named</emphasis> regular expression groups to capture URL bits and pass them as <emphasis>keyword</emphasis> arguments to a view. | 在更高级的用法中，还可以使用 <emphasis>命名</emphasis> 正则表达式组来捕获URL，并且将其作为 <emphasis>关键字</emphasis> 参数传给视图。 | 翻译 | ||
| 89#翻译 | Keyword Arguments vs. | 关键字参数 对比 | 翻译 | ||
| 90#翻译 | Positional Arguments | 位置参数 | 翻译 | ||
| 92#翻译 | A Python function can be called using keyword arguments or positional arguments and, in some cases, both at the same time. | 一个 Python 函数可以使用关键字参数或位置参数来调用，在某些情况下，可以同时进行使用。 | 翻译 | ||
| 93#翻译 | In a keyword argument call, you specify the names of the arguments along with the values you're passing. | 在关键字参数调用中，你要指定参数的名字和传入的值。 | 翻译 | ||
| 94#翻译 | In a positional argument call, you simply pass the arguments without explicitly specifying which argument matches which value; the association is implicit in the arguments' order. | 在位置参数调用中，你只需传入参数，不需要明确指明哪个参数与哪个值对应，它们的对应关系隐含在参数的顺序中。 | 翻译 | ||
| 96#翻译 | For example, consider this simple function: | 例如，考虑这个简单的函数: | 翻译 | ||
| 99#翻译 | To call it with positional arguments, you specify the arguments in the order in which they're listed in the function definition: | 为了使用位置参数来调用它，你要按照在函数定义中的顺序来指定参数。 | 翻译 | ||
| 102#翻译 | To call it with keyword arguments, you specify the names of the arguments along with the values. | 为了使用关键字参数来调用它，你要指定参数名和值。 | 翻译 | ||
| 103#翻译 | The following statements are equivalent: | 下面的语句是等价的: | 翻译 | ||
| 106#翻译 | Finally, you can mix keyword and positional arguments, as long as all positional arguments are listed before keyword arguments. | 最后，你可以混合关键字和位置参数，只要所有的位置参数列在关键字参数之前。 | 翻译 | ||
| 107#翻译 | The following statements are equivalent to the previous examples: | 下面的语句与前面的例子是等价: | 翻译 | ||
| 110#翻译 | In Python regular expressions, the syntax for named regular expression groups is <literal>(?P<name>pattern)</literal> , where <literal>name</literal> is the name of the group and <literal>pattern</literal> is some pattern to match. | 在 Python 正则表达式中，命名的正则表达式组的语法是 <literal>(?P<name>pattern)</literal> ，这里 <literal>name</literal> 是组的名字，而 <literal>pattern</literal> 是匹配的某个模式。 | 翻译 | ||
| 112#翻译 | Here's an example URLconf that uses non-named groups: | 下面是一个使用无名组的 URLconf 的例子: | 翻译 | ||
| 115#翻译 | Here's the same URLconf, rewritten to use named groups: | 下面是相同的 URLconf，使用命名组进行了重写: | 翻译 | ||
| 118#翻译 | This accomplishes exactly the same thing as the previous example, with one subtle difference: | 这段代码和前面的功能完全一样，只有一个细微的差别： | 翻译 | ||
| 119#翻译 | the captured values are passed to view functions as keyword arguments rather than positional arguments. | 取的值是以关键字参数的方式而不是以位置参数的方式传递给视图函数的。 | 翻译 | ||
| 121#翻译 | For example, with non-named groups, a request to <literal>/articles/2006/03/</literal> would result in a function call equivalent to this: | 例如，如果不带命名组，请求 <literal>/articles/2006/03/</literal> 将会等同于这样的函数调用： | 翻译 | ||
| 124#翻译 | With named groups, though, the same request would result in this function call: | 而带命名组，同样的请求就会变成这样的函数调用： | 翻译 | ||
| 127#翻译 | In practice, using named groups makes your URLconfs slightly more explicit and less prone to argument-order bugs and you can reorder the arguments in your views' function definitions. | 使用命名组可以让你的URLconfs更加清晰，减少搞混参数次序的潜在BUG，还可以让你在函数定义中对参数重新排序。 | 翻译 | ||
| 128#翻译 | Following the preceding example, if we wanted to change the URLs to include the month <emphasis>before</emphasis> the year, and we were using non-named groups, we'd have to remember to change the order of arguments in the <literal>month_archive</literal> view. | 接着上面这个例子，如果我们想修改URL把月份放到 年份的 <emphasis>前面</emphasis> ，而不使用命名组的话，我们就不得不去修改视图 <literal>month_archive</literal> 的参数次序。 | 翻译 | ||
| 129#翻译 | If we were using named groups, changing the order of the captured parameters in the URL would have no effect on the view. | 如果我们使用命名组的话，修改URL里提取参数的次序对视图没有影响。 | 翻译 | ||
| 131#翻译 | Of course, the benefits of named groups come at the cost of brevity; some developers find the named-group syntax ugly and too verbose. | 当然，命名组的代价就是失去了简洁性： | 翻译 | ||
| 132#翻译 | Still, another advantage of named groups is readability, especially by those who aren't intimately familiar with regular expressions or your particular Django application. | 一些开发者觉得命名组的语法丑陋和显得冗余。 | 翻译 | ||
| 133#翻译 | It's easier to see whats happening, at a glance, in a URLconf that uses named groups. | 命名组的另一个好处就是可读性强。 | 翻译 | ||
| 135#翻译 | Understanding the Matching/Grouping Algorithm | 理解匹配/分组算法 | 翻译 | ||
| 137#翻译 | A caveat with using named groups in a URLconf is that a single URLconf pattern cannot contain both named and non-named groups. | 需要注意的是如果在URLconf中使用命名组，那么命名组和非命名组是不能同时存在于同一个URLconf的模式中的。 | 翻译 | ||
| 138#翻译 | If you do this, Django won't throw any errors, but you'll probably find that your URLs arent matching as you expect. | 如果你这样做，Django不会抛出任何错误，但你可能会发现你的URL并没有像你预想的那样匹配正确。 | 翻译 | ||
| 139#翻译 | Specifically, here's the algorithm the URLconf parser follows, with respect to named groups vs. | 具体地，以下是URLconf解释器有关正则表达式中命名组和 | 翻译 | ||
| 140#翻译 | non-named groups in a regular expression: | 非命名组所遵循的算法: | 翻译 | ||
| 142#翻译 | If there are any named arguments, it will use those, ignoring non-named arguments. | 如果有任何命名的组，Django会忽略非命名组而直接使用命名组。 | 翻译 | ||
| 144#翻译 | Otherwise, it will pass all non-named arguments as positional arguments. | 否则，Django会把所有非命名组以位置参数的形式传递。 | 翻译 | ||
| 146#翻译 | In both cases, it will pass any extra options as keyword arguments. | 在以上的两种情况，Django同时会以关键字参数的方式传递一些额外参数。 | 翻译 | ||
| 147#翻译 | See the next section for more information. | 更具体的信息可参考下一节。 | 翻译 | ||
| 149#翻译 | Passing Extra Options to View Functions | 传递额外的参数到视图函数中 | 翻译 | ||
| 151#翻译 | Sometimes you'll find yourself writing view functions that are quite similar, with only a few small differences. | 有时你会发现你写的视图函数是十分类似的，只有一点点的不同。 | 翻译 | ||
| 152#翻译 | For example, say you have two views whose contents are identical except for the template they use: | 比如说，你有两个视图，它们的内容是一致的，除了它们所用的模板不太一样： | 翻译 | ||
| 155#翻译 | We're repeating ourselves in this code, and that's inelegant. | 我们在这代码里面做了重复的工作，不够简练。 | 翻译 | ||
| 156#翻译 | At first, you may think to remove the redundancy by using the same view for both URLs, putting parentheses around the URL to capture it, and checking the URL within the view to determine the template, like so: | 起初你可能会想，通过对两个URL都使用同样的视图，在URL中使用括号捕捉请求，然后在视图中检查并决定使用哪个模板来去除代码的冗余，就像这样： | 翻译 | ||
| 159#翻译 | The problem with that solution, though, is that it couples your URLs to your code. | 这种解决方案的问题还是老缺点，就是把你的URL耦合进你的代码里面了。 | 翻译 | ||
| 160#翻译 | If you decide to rename <literal>/foo/</literal> to <literal>/fooey/</literal> , you'll have to remember to change the view code. | 如果你打算把 <literal>/foo/</literal> 改成 <literal>/fooey/</literal> 的话，那么你就得记住要去改变视图里面的代码。 | 翻译 | ||
| 162#翻译 | The elegant solution involves an optional URLconf parameter. | 对一个可选URL配置参数的优雅解决方法： | 翻译 | ||
| 163#翻译 | Each pattern in a URLconf may include a third item: | URLconf里面的每一个模式都可以包含第三个数据： | 翻译 | ||
| 164#翻译 | a dictionary of keyword arguments to pass to the view function. | 一个关键字参数的字典： | 翻译 | ||
| 166#翻译 | With this in mind, we can rewrite our ongoing example like this: | 有了这个概念以后，我们就可以把我们现在的例子改写成这样： | 翻译 | ||
| 169#翻译 | As you can see, the URLconf in this example specifies <literal>template_name</literal> in the URLconf. | 如你所见，这个例子中，URLconf指定了 <literal>template_name</literal> 。 | 翻译 | ||
| 170#翻译 | The view function treats it as just another parameter. | 而视图函数会把它当成另一个参数。 | 翻译 | ||
| 172#翻译 | This extra URLconf options technique is a nice way of sending additional information to your view functions with minimal fuss. | 这种使用额外的URLconf参数的技术以最小的代价给你提供了向视图函数传递额外信息的一个好方法。 | 翻译 | ||
| 173#翻译 | As such, it's used by a couple of Django's bundled applications, most notably its generic views system, which we cover in Chapter 11. | 正因如此，这技术已被很多Django的捆绑应用使用，其中以我们将在第11章讨论的通用视图系统最为明显。 | 翻译 | ||
| 175#翻译 | The following sections contain a couple of ideas on how you can use the extra URLconf options technique in your own projects. | 下面的几节里面有一些关于你可以怎样把额外URLconf参数技术应用到你自己的工程的建议。 | 翻译 | ||
| 177#翻译 | Faking Captured URLconf Values | 伪造捕捉到的URLconf值 | 翻译 | ||
| 179#翻译 | Say you have a set of views that match a pattern, along with another URL that doesn't fit the pattern but whose view logic is the same. | 比如说你有匹配某个模式的一堆视图，以及一个并不匹配这个模式但视图逻辑是一样的URL。 | 翻译 | ||
| 180#翻译 | In this case, you can fake the capturing of URL values by using extra URLconf options to handle that extra URL with the same view. | 这种情况下，你可以通过向同一个视图传递额外URLconf参数来伪造URL值的捕捉。 | 翻译 | ||
| 182#翻译 | For example, you might have an application that displays some data for a particular day, with URLs such as these: | 例如，你可能有一个显示某一个特定日子的某些数据的应用，URL类似这样的： | 翻译 | ||
| 185#翻译 | This is simple enough to deal with you can capture those in a URLconf like this (using named group syntax): | 这太简单了，你可以在一个URLconf中捕捉这些值，像这样（使用命名组的方法）： | 翻译 | ||
| 188#翻译 | And the view function signature would look like this: | 然后视图函数的原型看起来会是： | 翻译 | ||
| 191#翻译 | This approach is straightforward it's nothing you havent seen before. | 这种解决方案很直接，没有用到什么你没见过的技术。 | 翻译 | ||
| 192#翻译 | The trick comes in when you want to add another URL that uses <literal>my_view</literal> but whose URL doesn't include a <literal>month</literal> and/or <literal>day</literal> . | 当你想添加另外一个使用 <literal>my_view</literal> 视图但不包含<literal>month</literal>和/或者<literal>day</literal>的URL时，问题就出现了。 | 翻译 | ||
| 194#翻译 | For example, you might want to add another URL, <literal>/mydata/birthday/</literal> , which would be equivalent to <literal>/mydata/jan/06/</literal> . You can take advantage of extra URLconf options like so: | 比如你可能会想增加这样一个URL， <literal>/mydata/birthday/</literal> ， 这个URL等价于 <literal>/mydata/jan/06/</literal> 。这时你可以这样利用额外URLconf参数： | 翻译 | ||
| 197#翻译 | The cool thing here is that you don't have to change your view function at all. | 在这里最帅的地方莫过于你根本不用改变你的视图函数。 | 翻译 | ||
| 198#翻译 | The view function only cares that it <emphasis>gets</emphasis> | 视图函数只会关心它 <emphasis>获得</emphasis> 了 | 翻译 | ||
| 199#翻译 | <literal>month</literal> and <literal>day</literal> parameters it doesn't matter whether they come from the URL capturing itself or extra parameters. | 参数，它不会去管这些参数到底是捕捉回来的还是被额外提供的。month和day | 翻译 | ||
| 201#翻译 | Making a View Generic | 创建一个通用视图 | 翻译 | ||
| 203#翻译 | It's good programming practice to factor out commonalities in code. | 抽取出我们代码中共性的东西是一个很好的编程习惯。 | 翻译 | ||
| 204#翻译 | For example, with these two Python functions: | 比如，像以下的两个Python函数： | 翻译 | ||
| 207#翻译 | we can factor out the greeting to make it a parameter: | 我们可以把问候语提取出来变成一个参数： | 翻译 | ||
| 210#翻译 | You can apply this same philosophy to your Django views by using extra URLconf parameters. | 通过使用额外的URLconf参数，你可以把同样的思想应用到Django的视图中。 | 翻译 | ||
| 212#翻译 | With this in mind, you can start making higher-level abstractions of your views. | 了解这个以后，你可以开始创作高抽象的视图。 | 翻译 | ||
| 213#翻译 | Instead of thinking to yourself, This view displays a list of <literal>Event</literal> objects, and That view displays a list of <literal>BlogEntry</literal> objects, realize they're both specific cases of A view that displays a list of objects, where the type of object is variable. | 更具体地说，比如这个视图显示一系列的 <literal>Event</literal> 对象，那个视图显示一系列的 <literal>BlogEntry</literal> 对象，并意识到它们都是一个用来显示一系列对象的视图的特例，而对象的类型其实就是一个变量。 | 翻译 | ||
| 215#翻译 | Take this code, for example: | 以这段代码作为例子： | 翻译 | ||
| 218#翻译 | The two views do essentially the same thing: | 这两个视图做的事情实质上是一样的： | 翻译 | ||
| 219#翻译 | they display a list of objects. | 显示一系列的对象。 | 翻译 | ||
| 220#翻译 | So let's factor out the type of object they're displaying: | 让我们把它们显示的对象的类型抽象出来： | 翻译 | ||
| 223#翻译 | With those small changes, we suddenly have a reusable, model-agnostic view! | 就这样小小的改动，我们突然发现我们有了一个可复用的，模型无关的视图！ | 翻译 | ||
| 224#翻译 | From now on, anytime we need a view that lists a set of objects, we can simply reuse this <literal>object_list</literal> view rather than writing view code. | 从现在开始，当我们需要一个视图来显示一系列的对象时，我们可以简简单单的重用这一个 <literal>object_list</literal> 视图，而无须另外写视图代码了。 | 翻译 | ||
| 225#翻译 | Here are a couple of notes about what we did: | 以下是我们做过的事情： | 翻译 | ||
| 227#翻译 | We're passing the model classes directly, as the <literal>model</literal> parameter. | 我们通过 <literal>model</literal> 参数直接传递了模型类。 | 翻译 | ||
| 228#翻译 | The dictionary of extra URLconf options can pass any type of Python object not just strings. | 额外URLconf参数的字典是可以传递任何类型的对象，而不仅仅只是字符串。 | 翻译 | ||
| 230#翻译 | The <literal>model.objects.all()</literal> line is an example of <emphasis>duck typing</emphasis> : If it walks like a duck and talks like a duck, we can treat it like a duck. | <literal>model.objects.all()</literal>一行是<emphasis>鸭子类型(duck typing)</emphasis> ：如果它走路像鸭子，叫声也像鸭子，那么我们就把它当做鸭子。 | 翻译 | ||
| 231#翻译 | Note the code doesn't know what type of object <literal>model</literal> is; the only requirement is that <literal>model</literal> have an <literal>objects</literal> attribute, which in turn has an <literal>all()</literal> method. | 注意代码本身并不知道<literal>model</literal>是什么类型的对象；只是要求</literal>model</literal>对象有<literal>objects</literal>属性，并且该属性有<literal>all()</literal>方法。 | 翻译 | ||
| 233#翻译 | We're using <literal>model.__name__.lower()</literal> in determining the template name. | 我们使用 <literal>model.__name__.lower()</literal> 来确定模板的名字。 | 翻译 | ||
| 234#翻译 | Every Python class has a <literal>__name__</literal> attribute that returns the class name. | 每个Python的类都有一个 <literal>__name__</literal> 属性来返回类名。 | 翻译 | ||
| 235#翻译 | This feature is useful at times like this, when we don't know the type of class until runtime. | 这特性在当我们直到运行时刻才知道对象类型的这种情况下很有用。 | 翻译 | ||
| 236#翻译 | For example, the <literal>BlogEntry</literal> class's <literal>__name__</literal> is the string <literal>'BlogEntry'</literal> . | 比如， <literal>BlogEntry</literal> 类的 <literal>__name__</literal> 就是字符串 <literal>'BlogEntry'</literal> 。 | 翻译 | ||
| 238#翻译 | In a slight difference between this example and the previous example, we're passing the generic variable name <literal>object_list</literal> to the template. | 这个例子与前面的例子稍有不同，我们传递了一个通用的变量名给模板。 | 翻译 | ||
| 239#翻译 | We could easily change this variable name to be <literal>blogentry_list</literal> or <literal>event_list</literal> , but we've left that as an exercise for the reader. | 当然我们可以轻易的把这个变量名改成 <literal>blogentry_list</literal> 或者 <literal>event_list</literal> ，不过我们打算把这当作练习留给读者。 | 翻译 | ||
| 241#翻译 | Because database-driven Web sites have several common patterns, Django comes with a set of generic views that use this exact technique to save you time. | 因为数据库驱动的网站都有一些通用的模式，Django提供了一个通用视图的集合，使用它可以节省你的时间。 | 翻译 | ||
| 242#翻译 | We cover Django's built-in generic views in Chapter 11. | 我们将会在下一章讲讲Django的内置通用视图。 | 翻译 | ||
| 244#翻译 | Giving a View Configuration Options | 提供视图配置选项 | 翻译 | ||
| 246#翻译 | If you're distributing a Django application, chances are that your users will want some degree of configuration. | 如果你发布一个Django的应用，你的用户可能会希望配置上能有些自由度。 | 翻译 | ||
| 247#翻译 | In this case, it's a good idea to add hooks to your views for any configuration options you think people may want to change. | 这种情况下，为你认为用户可能希望改变的配置选项添加一些钩子到视图中会是一个很好的主意。 | 翻译 | ||
| 248#翻译 | You can use extra URLconf parameters for this purpose. | 你可以用额外URLconf参数实现。 | 翻译 | ||
| 250#翻译 | A common bit of an application to make configurable is the template name: | 一个应用中比较常见的可供配置的地方是模板名字： | 翻译 | ||
| 253#翻译 | Understanding Precedence of Captured Values vs. | 了解捕捉到的值 | 翻译 | ||
| 254#翻译 | Extra Options | 和额外参数之间的优先级 | 翻译 | ||
| 256#翻译 | When there's a conflict, extra URLconf parameters get precedence over captured parameters. | 当冲突出现的时候，额外URLconf参数优先于捕捉值。 | 翻译 | ||
| 257#翻译 | In other words, if your URLconf captures a named-group variable and an extra URLconf parameter includes a variable with the same name, the extra URLconf parameter value will be used. | 也就是说，如果URLconf捕捉到的一个命名组变量和一个额外URLconf参数包含的变量同名时，额外URLconf参数的值会被使用。 | 翻译 | ||
| 259#翻译 | For example, consider this URLconf: | 例如，下面这个URLconf： | 翻译 | ||
| 262#翻译 | Here, both the regular expression and the extra dictionary include an <literal>id</literal> . The hard-coded <literal>id</literal> gets precedence. | 这里，正则表达式和额外字典都包含了一个 <literal>id</literal> 。硬编码的（额外字典的） <literal>id</literal> 将优先使用。 | 翻译 | ||
| 263#翻译 | That means any request (e.g., <literal>/mydata/2/</literal> or <literal>/mydata/432432/</literal> ) will be treated as if <literal>id</literal> is set to <literal>3</literal> , regardless of the value captured in the URL. | 就是说任何请求（比如， <literal>/mydata/2/</literal> 或者 <literal>/mydata/432432/</literal> ）都会作 <literal>id</literal> 设置为 <literal>3</literal> 对待，不管URL里面能捕捉到什么样的值。 | 翻译 | ||
| 265#翻译 | Astute readers will note that in this case, it's a waste of time and typing to capture the <literal>id</literal> in the regular expression, because its value will always be overridden by the dictionary's value. | 聪明的读者会发现在这种情况下，在正则表达式里面写上捕捉是浪费时间的，因为 <literal>id</literal> 的值总是会被字典中的值覆盖。 | 翻译 | ||
| 266#翻译 | Thats correct; we bring this up only to help you avoid making the mistake. | 没错，我们说这个的目的只是为了让你不要犯这样的错误。 | 翻译 | ||
| 268#翻译 | Using Default View Arguments | 使用缺省视图参数 | 翻译 | ||
| 270#翻译 | Another convenient trick is to specify default parameters for a view's arguments. | 另外一个方便的特性是你可以给一个视图指定默认的参数。 | 翻译 | ||
| 271#翻译 | This tells the view which value to use for a parameter by default if none is specified. | 这样，当没有给这个参数赋值的时候，视图将会使用默认值。 | 翻译 | ||
| 273#翻译 | An example: | 例子： | 翻译 | ||
| 276#翻译 | Here, both URL patterns point to the same view <literal>views.page</literal> but the first pattern doesn't capture anything from the URL. | 在这里，两个URL表达式都指向了同一个视图 <literal>views.page</literal> ，但是第一个表达式没有传递任何参数。 | 翻译 | ||
| 277#翻译 | If the first pattern matches, the <literal>page()</literal> function will use its default argument for <literal>num</literal> , <literal>'1'</literal> . If the second pattern matches, <literal>page()</literal> will use whatever <literal>num</literal> value was captured by the regular expression. | 如果匹配了第一个模式， <literal>page()</literal> 函数将会对参数 <literal>num</literal> 使用默认值 <literal>"1"</literal> ，如果第二个模式匹配成功， <literal>page()</literal> 函数将使用正则表达式传递过来的num的值。 | 翻译 | ||
| 279#翻译 | (Note that we've been careful to set the default argument's value to the <emphasis>string</emphasis> | （注：我们已经注意到设置默认参数值是字符串 | 翻译 | ||
| 280#翻译 | <literal>'1'</literal> , not the integer <literal>1</literal> . That's for consistency, because any captured value for <literal>num</literal> will always be a string.) | <literal>'1'</literal> ，不是整数<literal>1</literal>。这是为了保持一致，因为获取的<literal>num</literal>的值总是字符串。 | 翻译 | ||
| 282#翻译 | It's common to use this technique in conjunction with configuration options, as explained earlier. | 就像前面解释的一样，这种技术与配置选项的联用是很普遍的。 | 翻译 | ||
| 283#翻译 | This example makes a slight improvement to the example in the Giving a View Configuration Options section by providing a default value for <literal>template_name</literal> : | 以下这个例子比提供视图配置选项一节中的例子有些许的改进。 | 翻译 | ||
| 286#翻译 | Special-Casing Views | 特殊情况下的视图 | 翻译 | ||
| 288#翻译 | Sometimes you'll have a pattern in your URLconf that handles a large set of URLs, but you'll need to special-case one of them. | 有时你用一个模式来处理URLconf中的一系列URL，但是有时候你需要特别处理其中的某个URL。 | 翻译 | ||
| 289#翻译 | In this case, take advantage of the linear way a URLconf is processed and put the special case first. | 在这种情况下，要使用将URLconf中把特殊情况放在首位的线性处理方式 。 | 翻译 | ||
| 291#翻译 | For example, you can think of the add an object pages in Django's admin site as represented by a URLpattern like this: | 比方说，你可以认为Django管理站点的对象添加页面时通过下面这个URLpattern所描述的方式来实现的： | 翻译 | ||
| 294#翻译 | This matches URLs such as <literal>/myblog/entries/add/</literal> and <literal>/auth/groups/add/</literal> . However, the add page for a user object (<literal>/auth/user/add/</literal> ) is a special case it doesn't display all of the form fields, it displays two password fields, and so forth. | 这将匹配像 <literal>/myblog/entries/add/</literal> 和 <literal>/auth/groups/add/</literal> 这样的URL 。然而，用户对象的添加页面（ <literal>/auth/user/add/</literal> ）是个特殊情况，因为它不会显示所有的表单域，它显示两个密码域等等。 | 翻译 | ||
| 295#翻译 | We <emphasis>could</emphasis> solve this problem by special-casing in the view, like so: | 我们 <emphasis>可以</emphasis> 在视图中特别指出这种情况： | 翻译 | ||
| 298#翻译 | but that's inelegant for a reason we've touched on multiple times in this chapter: | 不过，就如我们多次在这章提到的，这样做并不优雅： | 翻译 | ||
| 299#翻译 | it puts URL logic in the view. | 因为它把URL逻辑放在了视图中。 | 翻译 | ||
| 300#翻译 | As a more elegant solution, we can take advantage of the fact that URLconfs are processed in order from top to bottom: | 更优雅的解决方法是，我们要利用URLconf从顶向下的解析顺序这个特点： | 翻译 | ||
| 303#翻译 | With this in place, a request to <literal>/auth/user/add/</literal> will be handled by the <literal>user_add_stage</literal> view. | 在这种情况下，对<literal>/auth/user/add/</literal> 的请求将会被 <literal>user_add_stage</literal> 视图处理。 | 翻译 | ||
| 304#翻译 | Although that URL matches the second pattern, it matches the top one first. | 尽管URL也匹配第二种模式，它会先匹配上面的模式。 | 翻译 | ||
| 305#翻译 | (This is short-circuit logic.) | （这是短路逻辑。） | 翻译 | ||
| 307#翻译 | Capturing Text in URLs | 从URL中捕获文本 | 翻译 | ||
| 309#翻译 | Each captured argument is sent to the view as a plain Python Unicode string, regardless of what sort of match the regular expression makes. | 每个被捕获的参数将被作为纯Python Unicode字符串来发送给视图，而不管正则表达式中的格式。 | 翻译 | ||
| 310#翻译 | For example, in this URLconf line: | 举个例子，在这行URLConf中： | 翻译 | ||
| 313#翻译 | the <literal>year</literal> argument to <literal>views.year_archive()</literal> will be a string, not an integer, even though <literal>\d{4}</literal> will only match integer strings. | 尽管 <literal>\d{4}</literal> 将只匹配整数的字符串，但是参数 <literal>year</literal> 是作为字符串传至 <literal>views.year_archive()</literal> 的，而不是整型。 | 翻译 | ||
| 315#翻译 | This is important to keep in mind when you're writing view code. | 当你在写视图代码时记住这点很重要。 | 翻译 | ||
| 316#翻译 | Many built-in Python functions are fussy (and rightfully so) about accepting only objects of a certain type. | 许多内置Python函数是挑剔的（这是理所当然的），只接受特定类型的对象。 | 翻译 | ||
| 317#翻译 | A common error is to attempt to create a <literal>datetime.date</literal> object with string values instead of integer values: | 一个典型的的错误就是用字符串值而不是整数值来创建 <literal>datetime.date</literal> 对象： | 翻译 | ||
| 320#翻译 | Translated to a URLconf and view, the error looks like this: | 回到URLconf和视图处，错误看起来很可能是这样： | 翻译 | ||
| 323#翻译 | Instead, <literal>day_archive()</literal> can be written correctly like this: | 因此， <literal>day_archive()</literal> 应该这样写才是正确的： | 翻译 | ||
| 326#翻译 | Note that <literal>int()</literal> itself raises a <literal>ValueError</literal> when you pass it a string that is not composed solely of digits, but we're avoiding that error in this case because the regular expression in our URLconf has ensured that only strings containing digits are passed to the view function. | 注意，当你传递了一个并不完全包含数字的字符串时， <literal>int()</literal> 会抛出 <literal>ValueError</literal> 的异常，不过我们已经避免了这个错误，因为在URLconf的正则表达式中已经确保只有包含数字的字符串才会传到这个视图函数中。 | 翻译 | ||
| 328#翻译 | Determining What the URLconf Searches Against | 决定URLconf搜索的东西 | 翻译 | ||
| 330#翻译 | When a request comes in, Django tries to match the URLconf patterns against the requested URL, as a Python string. | 当一个请求进来时，Django试着将请求的URL作为一个普通Python字符串进行URLconf模式匹配（而不是作为一个Unicode字符串）。 | 翻译 | ||
| 331#翻译 | This does not include <literal>GET</literal> or <literal>POST</literal> parameters, or the domain name. | 这并不包括 <literal>GET</literal> 或 <literal>POST</literal> 参数，或者域名。 | 翻译 | ||
| 332#翻译 | It also does not include the leading slash, because every URL has a leading slash. | 它也不包括第一个斜杠，因为每个URL必定有一个斜杠。 | 翻译 | ||
| 334#翻译 | For example, in a request to <literal>http://www.example.com/myapp/</literal> , Django will try to match <literal>myapp/</literal> . In a request to <literal>http://www.example.com/myapp/?page=3</literal> , Django will try to match <literal>myapp/</literal> . | 例如，在向 <literal>http://www.example.com/myapp/</literal> 的请求中，Django将试着去匹配 <literal>myapp/</literal> 。在向 <literal>http://www.example.com/myapp/?page=3</literal> 的请求中，Django同样会去匹配 <literal>myapp/</literal> 。 | 翻译 | ||
| 336#翻译 | The request method (e.g., <literal>POST</literal> , <literal>GET</literal> ) is <emphasis>not</emphasis> taken into account when traversing the URLconf. | 在解析URLconf时，请求方法（例如， <literal>POST</literal> ， <literal>GET</literal> ， <literal>HEAD</literal> ）并 <emphasis>不会</emphasis> 被考虑。 | 翻译 | ||
| 337#翻译 | In other words, all request methods will be routed to the same function for the same URL. | 换而言之，对于相同的URL的所有请求方法将被导向到相同的函数中。 | 翻译 | ||
| 338#翻译 | It's the responsibility of a view function to perform branching based on request method. | 因此根据请求方法来处理分支是视图函数的责任。 | 翻译 | ||
| 340#翻译 | Higher-Level Abstractions of View Functions | 视图函数的高级抽象 | 翻译 | ||
| 342#翻译 | And speaking of branching based on request method, let's take a look at how we might build a nice way of doing that. | 说到基于请求方法的分支，让我们来看一下可以用什么优雅的方法来实现它。 | 翻译 | ||
| 343#翻译 | Consider this URLconf/view layout: | 考虑这个 URLconf/view 设计: | 翻译 | ||
| 346#翻译 | In this example, the <literal>some_page()</literal> view's handling of <literal>POST</literal> vs. | 在这个示例中，<literal> some_page()</literal> 视图函数对<literal> POST</literal> | 翻译 | ||
| 347#翻译 | <literal>GET</literal> requests is quite different. | 和<literal> GET</literal> 这两种请求方法的处理完全不同。 | 翻译 | ||
| 348#翻译 | The only thing they have in common is a shared URL: | 它们唯一的共同点是共享一个URL地址： | 翻译 | ||
| 349#翻译 | <literal>/somepage/</literal> . As such, it's kind of inelegant to deal with both <literal>POST</literal> and <literal>GET</literal> in the same view function. | <literal> /somepage/</literal>。正如大家所看到的，在同一个视图函数中对<literal> POST</literal> 和<literal> GET</literal> 进行处理是一种很不优雅的做法。 | 翻译 | ||
| 350#翻译 | It would be nice if we could have two separate view functions one handling <literal>GET</literal> requests and the other handling <literal>POST</literal> and ensuring each one was only called when appropriate. | 一个比较好的设计习惯应该是，使用两个分开的视图函数——一个处理<literal> POST</literal> 请求，另一个处理<literal> GET</literal> 请求，然后在相应的地方分别调用。 | 翻译 | ||
| 352#翻译 | We can do that by writing a view function that delegates to other views, either before or after executing some custom logic. | 我们可以像这样做：先写一个视图函数然后由它来具体分派其它的视图，在之前或之后可以执行一些我们自定的程序逻辑。 | 翻译 | ||
| 353#翻译 | Here's an example of how this technique could help simplify our <literal>some_page()</literal> view: | 下边的示例展示了这个技术是如何帮我们简化<literal> some_page()</literal> 视图的： | 翻译 | ||
| 356#翻译 | Let's go through what this does: | 让我们从头看一下代码是如何工作的： | 翻译 | ||
| 358#翻译 | We've written a new view, <literal>method_splitter()</literal> , that delegates to other views based on <literal>request.method</literal> . It looks for two keyword arguments, <literal>GET</literal> and <literal>POST</literal> , which should be <emphasis>view functions</emphasis> . If <literal>request.method</literal> is <literal>'GET'</literal> , then it calls the <literal>GET</literal> view. | 我们写了一个新的视图，<literal> method_splitter()</literal> ，它根据<literal> request.method</literal> 返回的值来调用相应的视图。可以看到它带有两个关键字参数，<literal> GET</literal> 和<literal> POST</literal> ，它们应该是<emphasis> 视图函数</emphasis> 。如果<literal> request.method</literal> 返回<literal> GET</literal> ，那它就会自动调用<literal> GET</literal> 视图。 | 翻译 | ||
| 359#翻译 | If <literal>request.method</literal> is <literal>'POST'</literal> , then it calls the <literal>POST</literal> view. | 如果<literal> request.method</literal> 返回的是<literal> POST</literal> ，那它调用的就是<literal> POST</literal> 视图。 | 翻译 | ||
| 360#翻译 | If <literal>request.method</literal> is something else (<literal>HEAD</literal> , etc.), or if <literal>GET</literal> or <literal>POST</literal> were not supplied to the function, then it raises an <literal>Http404</literal> . | 如果<literal> request.method</literal> 返回的是其它值（如：<literal> HEAD</literal> ），或者是没有把<literal> GET</literal> 或<literal> POST</literal> 提交给此函数，那它就会抛出一个<literal> Http404</literal> 错误。 | 翻译 | ||
| 362#翻译 | In the URLconf, we point <literal>/somepage/</literal> at <literal>method_splitter()</literal> and pass it extra arguments the view functions to use for <literal>GET</literal> and <literal>POST</literal> , respectively. | 在URLconf中，我们把<literal> /somepage/</literal> 指向<literal> method_splitter()</literal> 函数，并把分别处理<literal> GET</literal> 和<literal> POST</literal>的函数作为额外参数传递给它。 | 翻译 | ||
| 364#翻译 | Finally, we've split the <literal>some_page()</literal> view into two view functions <literal>some_page_get()</literal> and <literal>some_page_post()</literal> . This is much nicer than shoving all of that logic into a single view. | 最终，我们把<literal> some_page()</literal> 视图分解到两个视图函数中<literal> some_page_get()</literal> 和<literal> some_page_post()</literal> 。这比把所有逻辑都挤到一个单一视图的做法要优雅得多。 | 翻译 | ||
| 366#翻译 | Note that these view functions technically no longer have to check <literal>request.method</literal> , because <literal>method_splitter()</literal> does that. | 注意，在技术上这些视图函数就不用再去检查<literal> request.method</literal> 了，因为<literal> method_splitter()</literal> 已经替它们做了。 | 翻译 | ||
| 367#翻译 | (By the time <literal>some_page_post()</literal> is called, for example, we can be confident <literal>request.method</literal> is <literal>'post'</literal> .) Still, just to be safe, and also to serve as documentation, we stuck in an <literal>assert</literal> that makes sure <literal>request.method</literal> is what we expect it to be. | （比如，<literal> some_page_post()</literal> 被调用的时候，我们可以确信<literal> request.method</literal> 返回的值是<literal> post</literal> 。）当然，这样做不止更安全也能更好的将代码文档化，这里我们做了一个假定，就是<literal> request.method</literal> 能象我们所期望的那样工作。 | 翻译 | ||
| 369#翻译 | Now we have ourselves a nice, generic view function that encapsulates the logic of delegating a view by <literal>request.method</literal> . Nothing about <literal>method_splitter()</literal> is tied to our specific application, of course, so we can reuse it in other projects. | 现在我们就拥有了一个不错的，可以通用的视图函数了，里边封装着由<literal> request.method</literal> 的返回值来分派不同的视图的程序。关于<literal> method_splitter()</literal> 就不说什么了，当然，我们可以把它们重用到其它项目中。 | 翻译 | ||
| 371#翻译 | But, while we're at it, there's one way to improve on <literal>method_splitter()</literal> . As it's written, it assumes that the <literal>GET</literal> and <literal>POST</literal> views take no arguments other than <literal>request</literal> . What if we wanted to use <literal>method_splitter()</literal> with views that, for example, capture text from URLs, or take optional keyword arguments themselves? | 然而，当我们做到这一步时，我们仍然可以改进<literal> method_splitter</literal> 。从代码我们可以看到，它假设<literal> Get</literal> 和<literal> POST</literal> 视图除了<literal> request</literal> 之外不需要任何其他的参数。那么，假如我们让<literal> method_splitter</literal>和那种会从URL里捕捉字符，或者会接收一些可选参数的视图一起工作时该怎么办呢？ | 翻译 | ||
| 373#翻译 | To do that, we can use a nice Python feature: | 为了实现这个，我们可以使用Python中一个优雅的特性： | 翻译 | ||
| 374#翻译 | variable arguments with asterisks. | 带星号的可变参数。 | 翻译 | ||
| 375#翻译 | We'll show the example first, then explain it: | 我们先展示这些例子，接着再进行解释： | 翻译 | ||
| 378#翻译 | Here, we've refactored <literal>method_splitter()</literal> to remove the <literal>GET</literal> and <literal>POST</literal> keyword arguments, in favor of <literal>*args</literal> and <literal>**kwargs</literal> (note the asterisks). | 这里,我们重构method_splitter(),去掉了GET和POST两个关键字参数,改而使用*args和和**kwargs(注意*号) | 翻译 | ||
| 379#翻译 | This is a Python feature that allows a function to accept a dynamic, arbitrary number of arguments whose names aren't known until runtime. | 这是一个Python特性，允许函数接受动态的、可变数量的、参数名只在运行时可知的参数。 | 翻译 | ||
| 380#翻译 | If you put a single asterisk in front of a parameter in a function definition, any <emphasis>positional</emphasis> arguments to that function will be rolled up into a single tuple. | 如果你在函数定义时,在参数前面加一个*号,那么所有传递给函数的<emphasis>位置参数</emphasis>将会被封装为一个元组. | 翻译 | ||
| 381#翻译 | If you put two asterisks in front of a parameter in a function definition, any <emphasis>keyword</emphasis> arguments to that function will be rolled up into a single dictionary. | 如果你在函数定义时,在参数前面加两个*号，那么所有传递给函数的关键字参数,将会被包装成一个字典。 | 翻译 | ||
| 383#翻译 | For example, with this function: | 例如，对于这个函数 | 翻译 | ||
| 386#翻译 | Here's how it would work: | 看一下它是怎么工作的 | 翻译 | ||
| 389#翻译 | Bringing this back to <literal>method_splitter()</literal> , you can see we're using <literal>*args</literal> and <literal>**kwargs</literal> to accept <emphasis>any</emphasis> arguments to the function and pass them along to the appropriate view. | 回过头来看<literal>method_splitter()</literal>，你会发现我们用<literal>*args</literal>和<literal>**kwargs</literal>接受任何参数并把它们传递到正确的视图。 | 翻译 | ||
| 390#翻译 | But before we do that, we make two calls to <literal>kwargs.pop()</literal> to get the <literal>GET</literal> and <literal>POST</literal> arguments, if they're available. | 但是在我们这样做之前，我们要调用两次<literal>kwargs.pop()</literal><literal>以获得GET</literal>和<literal>POST</literal>参数 ，前提是它们是合法的。 | 翻译 | ||
| 391#翻译 | (Were using <literal>pop()</literal> with a default value of <literal>None</literal> to avoid <literal>KeyError</literal> if one or the other isn't defined.) | (我们通过指定pop的缺省值为None,来避免由于一个或者多个关键字缺失带来的KeyError。) | 翻译 | ||
| 393#翻译 | Wrapping View Functions | 包装视图函数 | 翻译 | ||
| 395#翻译 | Our final view trick takes advantage of an advanced Python technique. | 我们最后的视图技巧利用了一个高级python技术。 | 翻译 | ||
| 396#翻译 | Say you find yourself repeating a bunch of code throughout various views, as in this example: | 假设你发现自己在各个不同视图里重复了大量代码，就像 这个例子： | 翻译 | ||
| 399#翻译 | Here, each view starts by checking that <literal>request.user</literal> is authenticated that is, the current user has successfully logged into the site and redirects to <literal>/accounts/login/</literal> if not. | 这里，每一个视图开始都检查<literal>request.user</literal>是否是已经认证的，如果是的话，说明当前用户已经成功登陆站点，否则就重定向到<literal>/accounts/login/</literal> | 翻译 | ||
| 400#翻译 | (Note that we haven't yet covered <literal>request.user</literal> Chapter 14 does but, as you might imagine, <literal>request.user</literal> represents the current user, either logged-in or anonymous.) | (注意,虽然我们还没有讲到request.user,但是14章将要讲到它。就如你所想像的,request.user描述当前用户是登录的还是匿名。) | 翻译 | ||
| 402#翻译 | It would be nice if we could remove that bit of repetitive code from each of these views and just mark them as requiring authentication. | 如果我们能够丛每个视图里移除那些 重复代，并且只在需要认证的时候指明它们，那就完美了。 | 翻译 | ||
| 403#翻译 | We can do that by making a view wrapper. | 我们能够通过使用一个视图包装达到目的。 | 翻译 | ||
| 404#翻译 | Take a moment to study this: | 花点时间来看看这个： | 翻译 | ||
| 407#翻译 | This function, <literal>requires_login</literal> , takes a view function (<literal>view</literal> ) and returns a new view function (<literal>new_view</literal> ). The new function, <literal>new_view</literal> is defined <emphasis>within</emphasis> | 函数requires_login,传入一个视图函数view,然后返回一个新的视图函数new_view.这个新的视图函数new_view在函数requires_login内定义， | 翻译 | ||
| 408#翻译 | <literal>requires_login</literal> and handles the logic of checking <literal>request.user.is_authenticated()</literal> and delegating to the original view (<literal>view</literal> ). | 它处理request.user.is_authenticated()这个验证,从而决定是否执行原来的view函数。 | 翻译 | ||
| 410#翻译 | Now, we can remove the <literal>if not request.user.is_authenticated()</literal> checks from our views and simply wrap them with <literal>requires_login</literal> in our URLconf: | 现在,我们可以从views中去掉if not request.user.is_authenticated()验证。我们可以在URLconf中很容易的用requires_login来包装实现。 | 翻译 | ||
| 413#翻译 | This has the same effect as before, but with less code redundancy. | 优化后的代码和前面的功能一样,但是减少了代码冗余。 | 翻译 | ||
| 414#翻译 | Now we've created a nice, generic function <literal>requires_login()</literal> that we can wrap around any view in order to make it require login. | 现在我们创建了一个漂亮而通用的函数requires_login()来帮助我们包装所有需要验证是否登录的视图。 | 翻译 | ||
| 416#翻译 | Including Other URLconfs | 包含其他URLconf | 翻译 | ||
| 418#翻译 | If you intend your code to be used on multiple Django-based sites, you should consider arranging your URLconfs in such a way that allows for including. | 如果你试图让你的代码用在多个基于Django的站点上，你应该考虑以能被包含的方式来处理你的URLconf。 | 翻译 | ||
| 420#翻译 | At any point, your URLconf can include other URLconf modules. | 在任何时候，你的URLconf都可以包含其他URLconf模块。 | 翻译 | ||
| 421#翻译 | This essentially roots a set of URLs below other ones. | 本质上这是把URL连接成树。 | 翻译 | ||
| 422#翻译 | For example, this URLconf includes other URLconfs: | 例如下面的，URLconf包含了其他URLConf： | 翻译 | ||
| 425#翻译 | (We saw this before in Chapter 6, when we introduced the Django admin site. | （之前在第6章介绍Django的admin模块时我们曾经见过include。 | 翻译 | ||
| 426#翻译 | The admin site has its own URLconf that you merely <literal>include()</literal> within yours.) | admin模块有他自己的URLconf,你仅仅只需要在你自己的代码中加入include就可以了。） | 翻译 | ||
| 428#翻译 | There's an important gotcha here: | 这里有个很重要的地方： | 翻译 | ||
| 429#翻译 | the regular expressions in this example that point to an <literal>include()</literal> do <emphasis>not</emphasis> have a <literal>$</literal> (end-of-string match character) but <emphasis>do</emphasis> include a trailing slash. | 例子中的指向 <literal>include()</literal> 的正则表达式并 <emphasis>不</emphasis> 包含一个 <literal>$</literal> （字符串结尾匹配符），但是包含了一个斜杆。 | 翻译 | ||
| 430#翻译 | Whenever Django encounters <literal>include()</literal> , it chops off whatever part of the URL matched up to that point and sends the remaining string to the included URLconf for further processing. | 每当Django遇到 <literal>include()</literal> 时，它将截断匹配的URL，并把剩余的字符串发往包含的URLconf作进一步处理。 | 翻译 | ||
| 432#翻译 | Continuing this example, here's the URLconf <literal>mysite.blog.urls</literal> : | 继续看这个例子，这里就是被包含的URLconf <literal>mysite.blog.urls</literal> ： | 翻译 | ||
| 435#翻译 | With these two URLconfs, here's how a few sample requests would be handled: | 通过这两个URLconf，下面是一些处理请求的例子： | 翻译 | ||
| 437#翻译 | <literal>/weblog/2007/</literal> : In the first URLconf, the pattern <literal>r'^weblog/'</literal> matches. | <literal>/weblog/2007/</literal> ：在第一个URLconf中，模式 <literal>r'^weblog/'</literal> 被匹配。 | 翻译 | ||
| 438#翻译 | Because it is an <literal>include()</literal> , Django strips all the matching text, which is <literal>'weblog/'</literal> in this case. | 因为它是一个 <literal>include()</literal> ，Django将截掉所有匹配的文本，在这里是 <literal>'weblog/'</literal> 。 | 翻译 | ||
| 439#翻译 | The remaining part of the URL is <literal>2007/</literal> , which matches the first line in the <literal>mysite.blog.urls</literal> URLconf. | URL仍存在的部分为 <literal>2007/</literal> ,与第一行的 <literal>mysite.blog.urls</literal>URL设置相匹配。 | 翻译 | ||
| 441#翻译 | <literal>/weblog//2007/</literal> (with two slashes): | /weblog//2007/(包含两个斜杠) | 翻译 | ||
| 442#翻译 | In the first URLconf, the pattern <literal>r'^weblog/'</literal> matches. | 在第一个URLconf中,r'^weblog/'匹配 | 翻译 | ||
| 443#翻译 | Because it is an <literal>include()</literal> , Django strips all the matching text, which is <literal>'weblog/'</literal> in this case. | 因为它有一个include(),django去掉了匹配的部,在这个例子中匹配的部分是'weblog/' | 翻译 | ||
| 444#翻译 | The remaining part of the URL is <literal>/2007/</literal> (with a leading slash), which does not match any of the lines in the <literal>mysite.blog.urls</literal> URLconf. | 剩下的部分是/2007/ (最前面有一个斜杠),不匹配mysite.blog.urls中的任何一行. | 翻译 | ||
| 446#翻译 | <literal>/about/</literal> : This matches the view <literal>mysite.views.about</literal> in the first URLconf, demonstrating that you can mix <literal>include()</literal> patterns with non-<literal>include()</literal> patterns. | <literal>/about/</literal> : 这个匹配第一个URLconf中的 <literal>mysite.views.about</literal> 视图。这说明你可以混合使用<literal>include()</literal>和<literal>非include()</literal>模式。 | 翻译 | ||
| 448#翻译 | How Captured Parameters Work with include() | 捕获的参数如何和include()协同工作 | 翻译 | ||
| 450#翻译 | An included URLconf receives any captured parameters from parent URLconfs, for example: | 一个被包含(included)的URLconf接收任何来自父URLconfs的被捕获的参数，比如: | 翻译 | ||
| 453#翻译 | In this example, the captured <literal>username</literal> variable is passed to the included URLconf and, hence, to <emphasis>every</emphasis> view function within that URLconf. | 在这个例子中，被捕获的 <literal>username</literal> 变量将传递给被包含的 URLconf，进而传递给那个URLconf中的 <emphasis>每一个</emphasis> 视图函数。 | 翻译 | ||
| 455#翻译 | Note that the captured parameters will <emphasis>always</emphasis> be passed to <emphasis>every</emphasis> line in the included URLconf, regardless of whether the line's view actually accepts those parameters as valid. | 注意，这个被捕获的参数 <emphasis>总是</emphasis> 传递到被包含的URLconf中的 <emphasis>每一</emphasis> 行，不管那些行对应的视图是否需要这些参数。 | 翻译 | ||
| 456#翻译 | For this reason, this technique is useful only if you're certain that every view in the included URLconf accepts the parameters you're passing. | 因此，这个技术只有在你确定被包含只向的每个视图都需要那个被传递的参数的时候才有用。 | 翻译 | ||
| 458#翻译 | How Extra URLconf Options Work with include() | 额外的URLconf如何和include()协同工作 | 翻译 | ||
| 460#翻译 | Similarly, you can pass extra URLconf options to <literal>include()</literal> , just as you can pass extra URLconf options to a normal view as a dictionary. | 相似的，你可以传递额外的URLconf选项到 <literal>include()</literal> , 就像你可以通过字典传递额外的URLconf选项到普通的视图。 | 翻译 | ||
| 461#翻译 | When you do this, <emphasis>each</emphasis> line in the included URLconf will be passed the extra options. | 当你这样做的时候，被包含URLconf的 <emphasis>每一</emphasis> 行都会收到那些额外的参数。 | 翻译 | ||
| 463#翻译 | For example, the following two URLconf sets are functionally identical. | 比如，下面的两个URLconf在功能上是一样的。 | 翻译 | ||
| 465#翻译 | Set one: | 第一个： | 翻译 | ||
| 468#翻译 | Set two: | 第二个 | 翻译 | ||
| 471#翻译 | As is the case with captured parameters (explained in the previous section), extra options will <emphasis>always</emphasis> be passed to <emphasis>every</emphasis> line in the included URLconf, regardless of whether the line's view actually accepts those options as valid. | 这个例子和前面关于被捕获的参数一样（在上一节就解释过这一点），额外的选项将 <emphasis>总是</emphasis> 被传递到被包含的URLconf中的 <emphasis>每一</emphasis> 行，不管那一行对应的视图是否确实作为有效参数接收这些选项。 | 翻译 | ||
| 472#翻译 | For this reason, this technique is useful only if you're certain that every view in the included URLconf accepts the extra options you're passing. | 因此，这个技术只有在你确定被包含指向的每个视图都正确接收这些额外选项的时候才有用。 | 翻译 | ||
| 474#翻译 | What's Next? | 接下来做什么？ | 翻译 | ||
| 476#翻译 | This chapter has provided many advanced tips and tricks for views and URLconfs. | 这一章提供了很多关于视图和URLconfs的高级提示技巧。 | 翻译 | ||
| 477#翻译 | Next, in <reference name="Chapter 9" refuri="../chapter09/">Chapter 9</reference>, we'll give this advanced treatment to Djangos template system. | 接下来，在<reference name="Chapter 9" refuri="../chapter09/">第九章</reference>,我们将会把这个先进的处理方案应用到Django的模板系统。 | 翻译 | ||
| 479#翻译 | <reference name="GNU Free Document License" refuri="/license/">GNU Free Document License</reference>. | GNU Free Document License. | 翻译 | ||
| 480#翻译 | Hosting graciously provided by | Hosting graciously provided by | 翻译 |