Django 学习笔记 － RequestContext

Context 常被翻译为“上下文”，可以在很多程序设计中见到他的身影。

不仅仅是 Django Template，几乎所有 Template Engine 的设计都是传递一个 Context 给 Template 进行渲染。这个 Context 就够成了模板所需的变量表。

Django Template 的特点就是简单，默认情况下调用 render_to_response 函数传递的第二个参数是一个简单 map 对象，会被包装成 django.template.Context 传递给模板使用。

其实很多场合我们需要默认在 Context 里面加入一些常用的东西，譬如把 request 对象传入 Context，把权限模型放入 Context 以便调用。为了避免每次硬编码，Django 提供了一个 Context 的子类，django.template.RequestContext。

在 settings 里面有一个名为 TEMPLATE_CONTEXT_PROCESSORS 的设置于 RequestContext 密切相关。默认的配置为：

("django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n")

这些 Processors 都会被 RequestContext 顺序调用，往当前 Context 中放入一些预定义变量。譬如 auth 就会放置 user 这个变量，就是当前登录的用户对象。

RequestContext 作为 render_to_response 的第三个参数传递，必须将 request 作为参数传递给它，如下：

def some_view(request):
# ...
return render_to_response('my_template.html',
my_data_dictionary,
context_instance=RequestContext(request))

更多的信息请参考 Django 官方文档：
http://www.djangoproject.com/documentation/settings/#template-context-processors

Django 学习笔记 －Middleware

Django 的确可以做类似 Spring framework 里面 Interceptor 的操作，这在 Web 开发中相当不错。不过在 Django 里面这个不叫做 Interceptor 或者 Filter，他叫做 Middleware。

Middleware，多么庞大的概念，Java 开发着对这个此一定不陌生......，不过在 Django 的世界里，他就是 Interceptor，很简单。

Django 提供了很多默认的 Middleware 来作一些例如 URL 处理，Session 控制，和一些更基础的工作。Middleware 同时也构成了 Django 一个独特的插件机制。

Middleware 并不复杂，他主要就是可以让你在 HTTP 请求过来之
前和之后作一些处理。要实现 Middleware 并不需要继承任何类，脚本语言嘛，我们有 Duck Typing。

Middleware 里面有以下4个函数可用：

1. process_request(self, request)
2. process_view(self, request, view_func, view_args, view_kwargs)
3. process_response(self, request, response)
4. process_exception(self, request, exception)

看看函数名想必就知道做什么的了吧，写好 Middleware 之后随便放到哪里，只要在 settings.py 里面写上路径可以让 Python 找到就行了。

Middleware 的一些不足：

• 全局应用，不能够针对某种 url pattern 应用自己的 middleware，不过可以自行扩展
• 没有类似 Java Servlet 中 Filter Chain 的管理，完全是顺序应用 middleware，所以顺序很重要，因为有依赖。
  

Middleware 官方文档：
http://www.djangoproject.com/documentation/middleware/

尝试写一个类似 RoR 的快速开发框架（4）

这几天又继续完善这个框架，URL的分发采用FilterDispacther，处理Script使用RhinoServlet。框架使用了Phobos的类库，因为RhinoScriptEngine一类的东西Phobos都写得很不错，那来直接用就可以，没必要自己重新发明轮子了。

Phobos里面ScriptEnginePool被我扩展了，主要是用于在启动每个ScriptEngine的时候默认加载一个启动脚本，这个脚本只会在ScriptEngine初始化的时候执行一次，然后进入ENGINE_SCOPE里面。之后就可以使用这里面定义的一些公共函数了。

URL之后的Scripts处理就基本学习RoR的Convention了，layout和helpers的处理流程也基本好了，接下来就是要开始写一些helpers，重点可以转移到JavaScript编程上了。

JSR-223、Phobos、Glassfish

继上一篇提到JSR-223改变之后，我从JCP网站上下载到了JSR-223提议的最终版本文档，06年8月10号的。光有代码还不行啊，还得找一下JSR-223的API包，Sundararajan 建议参考一下 Phobos 的代码，于是下了 Glassfish (2007-7-24)，用上了里面的 jsr-223.jar。

考虑到写一个JsRails框架的问题，我需要在ScriptEngine启动的时候默认加载一部分类库，之前sun实现的RhinoScriptEngine并没有留有任何扩展让人可以作这个事情，很想改改sun的实现代码，但是毕竟人家是CDDL的，不好弄。于是从cvs中checkout下了Phobos的最终代码，发现同名的jsr-223.jar比Glassfish里面的新，这一份jar才是最符合JSR-223 PFD的。看看代码里面的注释，发现作者已经想到了预留的扩展，总算可以实现要实现的功能了！

JSR-223 中的 javax.script.http 被删了

今天就JSR-223参考实现里面的一个小bug给 Sundararajan 发了封信，结果很快收到回信了。他告诉我 DeTagifier.java 估计要删掉了，javax.script.http 已经没有了，难怪我下载 JDK6 的源代码时发现这东西没了呢，而且从网上也很难搜到相关代码。

在用JSR-223+Rhino是用到了javax.script.http，感觉设计上还是有一些强制性的，譬如HttpScriptServlet，实现这个应该是MVC框架的一个职责，目前我的代码里面对这个类重新实现了一下，不然无法达到RoR那种效果。

我又回了 Sundararajan 一封信，向他咨询一下 JSR-223 未来的一些走势，期待回信了。

PS：Sundararajan 看着名字很怪，从他的blog上看出来他是个印度人，对脚本语言也是相当的熟悉了，他的blog上有很多脚本语言的对比，譬如JavaScript,Jython,JRuby,Grooby等等，对技术的研究也是非常透彻和有深度的。

尝试写一个类似 RoR 的快速开发框架（3）

继上一篇讨论了Routers的问题之后，我有着手写了关于URL的处理，总结起来有如下步骤，比之前多了有关静态内容的匹配。

1. 首先匹配规则
2. 如果规则不符，检测是否以后缀结尾
3. 如果有后缀，认为是静态内容
4. 没有后缀，自然拆封，例如：say/hello -> Controller: say, Method: hello

按照这个流程我做了DispatchFilter来处理URL，当然还有很多预料之外的问题需要解决。

RoR 的 layout 特性我还没有想到好的实现办法，使用 FreeMarker 作为模版有一些问题解决不了，譬如类似 RoR 的 render 功能，可能我要考虑直接用 JavaScript 像 RoR 一样作为模版用了。

尝试写一个类似 RoR 的快速开发框架（2）

这两天又边看《Agile Web Development with Ruby》边写这个框架。开始着手处理URL到Controller的分配。虽然书上没有提到明确的URL处理流程，但看过几个程序之后大概的程序流程有点明白了。
RoR 通过 routes.rb 来定义自定义的 URL 影射规则，观察过 routes.rb、Cake、Django 的 URL 影射规则之后，我觉得在我这个框架里面最好的选择就是采用正则直接匹配。于是我可以考虑如下写法定义 routes.jsx：
Routing.connect('^/$', 'blog', 'index');
Routing.connect('^/articles/(\\d+)$, 'blog', 'show');

除了这个当然还有一个默认的规则，那就是根据url分割之后进行匹配：
/say/hello -> Controller: say, Method: hello
这样的 url 虽然没有经过 Routing 的定义，但是可以用默认的方式进行匹配，当然了，在hello后面的参数会追加到函数定义中去，譬如：
/say/hello/nicholas
function hello(greeting) { print(greeting); }
这种方式也应该要受到支持。

URL 的匹配还是挺复杂的一块内容，现在作了一个简陋的实现，还期待 ShiningRay 和 Tin 同学多提意见。

尝试写一个类似 RoR 的快速开发框架（1）

最近受 RoR 的影响颇深，导致人逐渐变懒......

同样是写程序，用 RoR 的确可以有效的减少代码量同时又可以快速开发出所要的东西，有什么不好呢？现在类似 RoR 的框架层出不穷，随着 JSR-223 的升温，使我感觉是否可以用 JavaScript 写一个类似 RoR 的快速框架出来呢，于是着手开始尝试。

JSR-223 和 BSF 实在太像了，以至于参考实现的代码基本上直接取自 BSF，虽然 JSR-223 提供了 http 支持，但是要用 JavaScript 实现一个类似 RoR 的框架，靠这点 http 支持毕竟还是有点局限，所以首先要在Servlet上下点功夫。

URL 是一个很重要的部分，RoR 里面使用 routes.rb 来实现自定义的 URL 规则，这一点在 Java Web 开发中能够做到的话也只能用 Filter 了。我的思路是通过 Filter 获取 URL，然后将 URL 分解，拆出 Controller、Method、Params 部分，然后用 RequestDispatcher 分发到专门处理 Scripts 的 Servlet 来处理，其中这些过程变量放在 request 中带过去。

ScriptServlet 部分应该是读取指定目录的 js 文件，按照 RoR 的约定，应该是在 app/controllers 目录下面按照 xxx_controller.js 开始找，然后根据 request 传过来的 Method 进行调用，最后搜索模版，路径在 views/xxx/ 目录下，用函数调用返回的结果渲染模版。

大致的流程估计应该是这样，下面考虑一下所用的框架。觉得很有可能需要自己实现一个基于脚本的 MVC 框架，除了 Filter 处理 URL 之外，还需要一个 ScriptsServlet 充当 ApplicationController 的角色，用来将请求分发给不同的 js 去处理，然后再加在模版进行渲染。模版引擎考虑才用 FreeMarker，虽然用 js 也可以做，但总觉得功能上不如 FreeMarker 来的强大。

大概思路先是这点，打算做做看先。

JSR 223: Scripting for the Java Platform

最近由于 RoR 的盛行，SUN 收编了 JRuby 的两名作者，决心在脚本语言方面做点文章了，于是 Java 6 中间加入了 JSR-223 的支持。看了一下 JSR-223 的相关内容，发觉这东西不就是把 BSF (Bean Script Framework) 规范化了吗......，不同的是 BSF 是 IBM Alphaworks 贡献给 Apache 的，而 JSR-223 是一个规范。

这个 JSR-223 其实就是定义了一些接口，用来衔接使用 Java 实现的脚本语言和 Java 本身通讯，是 Java 与 Scritps 互操作的一个桥梁。主要职责差不多是让 Java 执行动态语言脚本，访问动态语言执行中产生的变量、函数等，同时让动态语言能够在它的范围内访问到 Java 空间里面的指定变量，达到互操作的目的。

JSR-223 除了一个标准的给用户使用的接口之外应该还有一部分给 Scripts Provider 让他们将自己的实现符合这个规范，达到一致的目的。

BSF 自 2003 年就已经 release 2 了，翻了翻以前老外讨论 BSF 的邮件列表，发现他们主要的问题集中在性能，觉得在 JVM 上面用 Java 再来解释一种脚本语言效率实在不行。不过近年来随着 RoR 的出现，似乎让大家的重点更多的转移到了速度上来，毕竟不是所有场合都那么追求高性能，能够提供更高的开发效率才是大家所需的。

由 CakePHP 想到的......

做了一段时间的 CakePHP 开发，一个类似 RoR 的 PHP 框架，让我对 Web 编程又开始感兴趣了，之前用 Java 开发 Web 程序着实让人失望。静下心来总结一下，其实 Java 开发 Web 应用也可以模仿 RoR 的，虽然类似的框架已经有一些了，但是我还是觉得应该尽可能的简单......

采用一个非 JSP 的模版引擎。大家喜欢使用 JSP 当模版，当然了，默认就是这样的。不过 JSP 第一次编译着实让人很烦燥，我觉得 Web 开发的速度优势不明显了。开发 ASP/PHP，边写程序边刷新页面是挺实用的方法，页面有太多的布局、UI元素，需要频繁的刷新来进行调整，这点 JSP 让人调的很麻烦。所以选择一个好的模版引擎可以省不少事情，我最喜欢 FreeMarker，当然还有 Velocity 可以用，还有一个有意思的东西，Antlr 配套的 Stringtemplate 也可以拿来用，非常不错。

使用动态语言编写 Controller。Controller 的职责出要是处理一些控制逻辑，数据库的操作它不需要来负责，所以 Controller 随着 View 的不同改动太大了，但也都是微调。因为经常需要改变，所以每次都编译一边实在恶心。当然了，各种框架几乎都提供了容器外测试的环境，我个人觉得后期可以将稳定的 Controller 写回静态类以提高性能并进行详细功能测试，但一般来说大可不必。采用一种好的动态语言可以省不少事情，譬如 Java 提供了统一的 BSF 可以选用很多动态语言，譬如 JavaScript，Jython，Groovy, BeanShell，JRuby 等等。初期效率不是最关键的因素，再说 Web 应用的性能瓶颈往往在数据库，Web 框架没必要太复杂。


业务、数据层可以脱离容器开发。这一层是 Java 的强项，完全可以脱离容器开发，进行单元测试，这对于 Java 开发人员往往是最得心应手的工作。

如果有时间到想用 Java 做一个这样的东西玩玩，似乎还漏了最重要的一点，Convention over Configuration，有了这个 Magic，效率才可能有魔术般的提升！

见到了 Java 之父 James Gosling

居然能和 Java 之父 James Gosling 一起合影这对于一个 Java Developer 来说是多么兴奋得事情！James 来公司作客，公司组织了一个讨论会，虽然很多同事都不是 Java 开发人员，但对于 Java 之父的到访还都是很感兴趣的，大家也都纷纷提问。我也凑了个热闹，提了个问题。

Q：As you mentioned functional programming, which gets ideas from mathematics. They have many language spotlight like continuation, closure and so on. Does java consider introducing these features in the future?

似乎 James 对这个问题也是颇有感触，他说 Closure 和 Continuation 的支持现在更多的是一场争论，似乎无穷无尽。函数式编程的确是一件好东西，可以有效地减少代码数量，但是同样他带来的一个缺点就是晦涩难懂。做 Java 的一部分开发人员其实并不是纯粹的计算机出生，所以他们并不一定有扎实的数学基础，对于函数式编程的理解可能比较困难，不自然。不过嘛，虽然 Continuation 没什么戏了，我们依然可以通过 Inner Class 或者 Anonymous Class 的方式凑活当 Closure 用吧。

会上还有同事提到一些关于现在高性能计算的问题，也是最近双核 CPU 的出现，大家对于双核甚至多核比较关注。根据 James 的介绍，Java 的线程方式对于多核的支持非常完善了，在数百个 CPU 上的多线程表现也算不错，但是在上千个 CPU 上的尝试还是不太理想，毕竟这么多 CPU 有很多无法预料的情况产生。当有人问及未来会不会出现一种具有更高生产力的编程语言是，他回答道如果未来可能产生一门语言在并行计算上具有压倒性优势的话，那么这门语言就是最有希望的。目前除了 Java 之外，FP 和基于消息的语言（类似 Smalltalk 的理想模型）是三种主流趋势，他看好 Java，毕竟后两种语言绕开了共享内存的缺陷，但是要想让大众接受比较困难一点。

时间比较短，而且大家也都是问得比较随意，没有刻意去准备，再加上 James 估计也就是走个过场，座谈会就匆匆结束了。

能够与 Java 之父面对面，还是一件很高兴得事情！