细说 repoze.bfg 中的 view

View

理解View

用户在浏览器中选择url, 服务器获得请求并返回页面, 可以翻译成在你命令行下进入某目录编辑某文件.

Repoze.bfg就是使用命令行的人: 你自己, 应用的model就是文件系统, traversal 或 url dispatch 就是cd 目录, view callable 就是对文件进行操作的程序(比如编辑).

 

什么叫callable? 就是函数和类的统称. 因为在python中他们都可以被调用. View callable就是可以接收context, request参数并返回response的函数或类.

view callable 的参数: context, request.

要操作文件(页面), view 需要知道一些信息, 这些信息以参数的方式传递进来,

1. 请求的页面名称, 在request.matchdict中得到 {'pagename':'Front Page'}
2. 如果请求是提交的, 在request.params中有提交数据, 即当前会话客户浏览器填入的表单数据
3. request.context, 在url dispatch模式下, request.context被用来传递安全上下文.(在request.context.acl 中) .
4. context: 主要用在traversal模式下作为model的对象被传递. 在 url dispatch中可被省略.

 

View callable实际上就是一个函数或类. 对于函数有context,request参数. 对于类其构造器有context,request参数:

def hello_world(context,request): ... class hello_world(object): def __init__(self,context,requet): ...

view callable 接收参数并利用(或不用)这些参数做处理, 目的是什么 ? 是给浏览器返回页面呈现.  我们说就是一个Response.

这里按repoze.bfg的设计约定有两种方式返回呈现, 一种是WebOb的Response对象. 我们说这是一种"裸"的返回, 因为Response('Hello World!')就是一个原始的Hello World字符串, 没有任何的处理, 类似于python的print. 第二种就是非Repsonse对象, 在这种情况下, repoze.bfg将检查view configuration(在zcml中) 以得到相关的renderer, 再转换成Response结果. 比如下面的view configuration (in configure.zcml)

<view
  view=".views.my_view" <=== view callable
  renderer="templates/atemplate.pt" <==== zpt template
/>
















必须强调的是这里有两个"View". 







第一个 view是zcml中的指示符(directive), 通过它把view callable和renderer组合起来.  View directive主要用在traversal中. 



而url dispatch方式中主要用route指示符来表示映射. 如:



<route path=""
    name="home"
    view=".views.my_view"
    view_renderer="templates/mytemplate.pt"
    />



 











第二个 view 就是view callable. Traversal和Url Dispatch都会用到它. 用在指示符内部作为必选项, 

用来指定响应请求的处理函数或类(view callable).

实际的执行情况用伪代码表示就是
repoze.bfg: convert(view callable+template, response)
repoze.bfg: return response

 

renderer是什么? renderer是用于html页面生成的一种模板语言. 它可以有多种实现. 比如chaemelon的zpt实现.
在第二种情况下, view callable 经常返回的是一个字典. 该字典用于以命名变量的方式向模板提供参数. 这个很重要, 因为view callable可以动态产生值, 把这些值与模板绑定就可以达到动态页面的结果, 比如:
view callable:

def hello_world(context,request):

   name="george"
   return {'customer_name':name}

zpt template:

<span tal:replace="structure customer_name">Customer Name</span>

customer_name就是命名变量, 通过view callable返回后再传递给模板. 以上代码其实并不能执行, 还要通过view configuration(zcml)组装(wiring)才能让repoze.bfg知道如何将二者结合起来:

<view
  view=".views.hello_world" <===假设在目录下有一个views.py文件, hello_world是view callable即views.py内的一个函数或类
  renderer="templates/customer.zpt" <=== 我们的模板代码在这个文件中
/>

为什么要分离出单独的renderer? 降低耦合度, 让渲染器能自由替换. 如果你发现了更好的渲染器, 那么唯一需要做的就是改变renderer选项. 同时提供新的模板文件. 此事不会变动原有的程序代码. 这个就很爽也.

 

再谈View

理论上, 根据BFG文档, 其宣称自己并不是MVC结构, 指的是View这个概念, 在BFG中, View指的是将要呈现给用户的数据, 它并不需要是数据看起来的样子, 而是数据本身. 比如前例中的name="george"这个数据才是View.  数据总是要呈现的, BFG把数据和模板叠加来表现"数据看起来的样子 ". 那么Controller 在哪里? Controller就是BFG本身, BFG的核心任务就是响应浏览器的请求并把该请求分派到合适的View.