月度存档: 二月 2010

Python应用:轻量级Web框架Quixote

缘起

Quixote是 由美国全国研究创新联合会(CNRI,Corporation for National Research Initiatives)的工程师A.M.Kuchling、Neil Schemenauer和Greg Ward开发的一个轻量级Web框架。和几乎所有的开源项目一样,Quixote也是为了满 足实际需要而出世的。

CNRI当时在进行一个名为MEMS Exchange的项目(http://www.mems-exchange.org/)。MEMS是微机电系统的缩写,制造一个MEMS设备往往需要多种制造设备,单个工厂可能无 法提供所需的所有设备。因此,MEMS Exchange项目就是要整合起多家制造厂的资源,利用互联网派单和追踪制造过程,形成一个分布式的MEMS设备制造网络。

起初,他们做了一个Java版的客户端程序提供给用户,但他们发现,没有人愿 意使用这个客户端程序,大家还是习惯性地用邮件发送加工过程。最终他们认识到,虽然客户端的表现力更强,功能也更完整,但相比起要下载一个庞大的程序,用 户更加愿意使用他们每天面对的浏览器来做事情。于是,他们决定改到Web界面上来,要做一个Web应用。但是用Java的servlets开发Web应用 是一件非常低效的事情,所以他们选择了Zope(和现在不同,在1999年,Python的Web应用框架没有什么选择的余地,基本上是Zope一家独 大)。3个月的开发之后,他们得到了一个运转良好的系统。

然而,Zope带来的快乐并没有持续多长时间。几个月后,他们想提供更加复杂 一点的界面,却发现用Zope写的代码难以维护和调试,在浏览器的文本编辑框里写代码也实在不是什么好的体验。由于当时除了Zope之外也没有什么别的 Python Web框架,他们决定:自己写一个!在2000年,编写一个新的Web框架是类似于向风车挑战一样的事情,开发团队自嘲地用堂吉诃德的名字命名这个框架:Quixote。

Quxiote的特点:

一、目录式的URL分发规则

所有的的Web框架要解决的第一件事,都是如何将用户的URL请求映射到程序上去。与ROR和Django这类基于Route和正则匹配的框架不同。Quxiote使用目录的方式逐层查找来实现的,最后请求将被映射到一个类的方法上。

假设你有一个应用是app。如果用户请求http://localhost/hello/,Quxiote将会将这个请求映射到app.hello._q_index()这个方法上,_q_index()方法是Quixote默认的根路径方法。如果用户请求http://localhost/hello/world, Quxiote将会将这个请求映射到app.hello.world()这个方法上。如果你需要为用户的访问设置权限,你只要实现相应目录下的_q_access()方法。

二、最接近Python的模板语言

Web 框架的模板一直是备受争议的环节,因为不同的模板框架提供了不同的模板标签,这提高了开发人员的学习成本。

所以Quxiote提倡用Python来写模板,最大程度的使用已有的Python编程能力。

Quxiote的模板语言叫做PTL(Python Template Language),PTL的模板文件以.ptl结尾,需要执行Quxiote的quixote.enable_ptl()之后Python才会像解析.py一样解析.ptl文件。PTL文件将html代码嵌入到Python代码中,并进行切块。这样你能在模板中随意的书写Python的代码来实现模板。这和现在比较流行的模板实现机制恰好相反。本人还是比较支持,以html作为模板文件,再用Python来解析html中的标签。这种方式更加清楚,可维护性更高。

三、显示标记,拒绝魔术

在The zen of python 中有一句话

Explicit is better than implicit. #显示的说明要比不言明的好。

所以如果你在Python命令行中输入:
import this
便可以看到有趣的提示,这便是Python编程所坚持的哲理

在Quixote中需要公布出来的路径需要配置在一个_q_exports=[]列表中。配置的内容即方法名称。

Quixote的优点:

  1. 简单,Quxiote的全部代码量为7000行左右,而且包含了大量的注释,如果去掉注释,则只有大约2500行代码。这也是我选择Quixote来学习Python的原因,因为你能容易通过阅读代码看到Quxiote做了什么。
  2. 高效,这一方面得益于Python语言本身的特点和Quxiote简单的架构,另一方面得益于用PTL模板。
  3. 安全,这也得益于Quxiote的简单,使得我们能很好的控制框架,并且它提供了一些HTML输出方法,保证了HTML输出的安全。
  4. 自由,开源就是好!
  5. 久经考验,历史悠久,在大量的企业应用中被证明是一个高效,灵活,稳定的框架,最著名的应用就是豆瓣(http://www.douban.com),我也是从豆瓣的架构中知道了Quxiote。

Quxiote的缺点:

  1. 没有内置的数据库支持和安全验证机制
  2. PTL适合程序员,并不适合美工参与前端代码的编写和修改
  3. 内置服务器不能很好的支持Debug,如果使用simple_server.py来调试虽然可以跟踪到,但是如果修改代码必须重启服务器,如果使用cgi,虽然修改代码后不用重启服务器,但是无法跟踪到代码,并且Quixote提供的Session支持会失效,除非使用Session持久化。
  4. 没有内置WSGI的支持,WSGI是Python PEP中提出的规范即(Web Server Gateway Interface)这个规范被广泛应用,使得Python Web Server 和 Python Web Framework能很好的兼容。

总结:

首先,对于想学习Python Web开发的人来说,通过使用Quixote将会带来很多的好处,Quxiote很接近Python,不会像Django和Pylons虽然提供了很好的开发流程,也能很快的上手,但是很难了解到这些框架到低做了什么,至少对于初学者来说,使用这些框架并不太适合。而Quixote代码量少,但包括了很多核心功能的实现,如Request,Response,Session,WebServer等。

其次,Quixote的简单使得Quixote非常灵活,也意味着你需要做更多的二次开发,所以想用Quixote做出好的网站,还需要有一定的Python基础。如数据库开发,Python多线程应用等等。

由于Quixote并没有为我们提供数据库的支持和安全验证机制,但是你同样可以使用一些已有的框架来解决这个问题,如SqlAlchemy。SqlAlchemy可以说是Python的ORM标准,就像Java中的Hibernate一样,所以是不二的选择,很多人没有选择Django,也是因为Django的ORM解决方法并不能让人满意。

另外本人并不使用Quixote的PTL,毕竟时代的发展已经有更好的技术来替代他了,比如Python的模板引擎Mako,豆瓣在新的开发中也部分使用了Mako。

SqlAlchemy和Mako的介绍以及和Quixote集成的文章也会陆续推出。

【扩展阅读】

The zend of python :http://www.python.org/dev/peps/pep-0020/

Python Web Server Gateway Interface:http://www.python.org/dev/peps/pep-0333/

Quixote White Pager:http://www.quixote.ca/overview/paper.html

QuixoteCookbook:http://www.quixote.ca/qx/QuixoteCookbook

不可忽视的DocType

1. doctype是什么

doctype标签 用来指定document的dtd(Document Type Definition)的,写在每个html的最前面,形如:

<!DOCTYPE RootElement Availability “URI” [declarations]>

如几种常见的doctype:

  • HTML 4.01: Strict<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
  • HTML 4.01 Transitional<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
  • XHTML 1.1 Strict DTD<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

2. doctype能做什么

有没有指定doctype, 以及指定不同的doctype都会激活不同的浏览器模式,从而产生对一些对html,css和js的影响,其中最著名的就是所谓的盒模型问题。

2.1   为什么会有多种模式

在很久很久以前还是netscape和ie争霸天下的时代,由于太强大了,浏览器模式是由浏览器自己说了算的。时光流逝,转眼到了战国群雄的时 代,大家发现如果都自己说了算的话天下就乱套了,就商量说推举个盟主吧,于是w3c就上台了。但是问题又来了,譬如IE,虽说再不能一头独大,向标准看齐 是大势所趋,但是假如浏览器只支持标准的话,之前的许多页面又会产生一些问题。

于是doctype应运而生,假如没有指定任何doctype,就采用原先的模式,被称为怪癖模式(Quirks Mode),假如指定了doctype,就遵循标准,被称为标准模式或严格模式(Standards Mode)。期间,以Mozilla为代表的几位,觉得标准模式里诸如img的解析不是很合适,就保留了一些个人意见,在指定一些特定的doctype情 况下,会采用一种准标准模式(Almost Standards Mode),具体情况请参考Activating Browser Modes with Doctype,或译文用doctype激活浏览器模式

2.2   不同模式的具体影响

ppk大牛已经给我们 做了很好的总结,Quirks mode and strict mode