`
limodou
  • 浏览: 66208 次
  • 性别: Icon_minigender_1
最近访客 更多访客>>
文章分类
社区版块
存档分类
最新评论

[Django]使用mako模板系统

阅读更多

最近看了看mako模板系统,感觉功能还是非常强大,虽然还没有怎么使用,但至少对于我这个 Python 程序员来说,不用去开发乱七八糟的tag,应该还是很方便的。Django 的tag其实也是一种简化的方式,但这种方式的编程并不轻松,象mako那样可以在模板中灵活定义函数,并且可以为其它的模板文件使用,从使得代码的重用性就非常强。于是我开始先研究一下如何在Django中使用mako好了。

记得以前黄毅写过这方面的东西,最初是在他的Blog上,后来他又整理了一下发布在了 djangosnippets.org 上了,在djangosnippets.org上还包括了geshi这个模板系统。不过我目前对于xml的模板系统没有什么兴趣,而且从测试上说mako是比geshi快的,所以先研究mako好了。

关于mako我不想说太多了大家自已去看吧。下面我先简单介绍一下由黄毅所做的工作。总的来说,黄毅的工作是将常用的几个与模板相关的函数进行了重定义,比如:select_template, get_template, render_to_response。在使用时你有可能需要定义三个参数在settings中,分别是:

MAKO_TEMPLATE_DIRS 它是用来存放模板路径的,正如TEMPLATE_DIRS的作用一样。如果没有缺省为make_templates。同时对于每一个app都会将它下面的make_templates子目录加到模板目录中去,如果存在的话。

MAKO_MODULE_DIR mako的文件型模板是可以编译成.py模块的,这个目录就是指明生成的.py文件将放在什么地方。如果没有指定,则生成的.py文件将放在与原模板相同的路径中去。

MAKO_MODULENAME_CALLABLE 这个是用来提供一个编译模板名生成的函数的。缺省的就是在模板名后面加.py就可以了。你可以写一个新的生成规则的函数来生成你想要的.py文件名。

在最简单的情况下,你不需要修改settings.py的配置。只要将你的模板放在每个app下的mako_templates下就可以了。然后将djangosnippets.org上的代码,一个是common.py一个是moko_django.py分别保存到一个目录下。然后在view中从mako_django.py中导入render_to_response()函数来使用就可以了。

了解了黄毅的mako处理方式,我做了一些改进:

common.py 没有动

mako_django.py 将 MAKO_TEMPLATE_DIRS 改为 TEMPLATE_DIRS,这样不用为mako单独使用新的目录了。同时将每个app下的mako_templates子目录的处理改为templates,这样和Django现在的方式一样。

因为没有单独的mako目录,如果你混合使用django和mako的模板这样从文件名上可能会有冲突。因此我希望通过扩展名来自动区分。这样我规定mako的扩展名为mko。为了方便处理,我写了一个新的render_template()函数(这个函数我定义在了common.py中了)。

render_template(request, template_path, extra_context)

这个函数会使用RequestContext来生成Context对象,这样就可以处理TEMPLATE_CONTEXT_PROCESSORS。同时它会根据模板的后缀来判断是何种模板类型。在缺省情况下.mko就是mako模板。为了方便扩展,你可以在settings中设置一个选项:

TEMPLATE_TYPES

它是一个字典。比如可以这样定义:

TEMPLATE_TYPES = {'.mko':'mako', '.mk':'mako'}

可以看到一个后缀对应一种类型。而对类型的处理目前是写死在render_template中了,所以如果想通过这种后缀来判断模板类型的话,需要修改代码增加新的扩展。不过目录应该足够了。缺省情况下这个项可以不用定义。

所以以我的方式来运行的话,你需要:

common.py 包括render_template和app_dirs的处理(同黄毅的)。

mako_django.py 我修改过的版本。

除了继续使用原来的TEMPLATE_DIRS和templates外,另两个选项与黄毅的相同。

使用时要注意区分后缀。

上述我做的修改都在 zipbook 项目中可以找到,其中我还做了一个测试:

http://localhost:8000/zipbooks/mako/

分享到:
评论
1 楼 JeffreyHsu 2010-01-01  
mako的确是比genshi强大多了

genshi基于严格的xml,太烦人了,一点不匹配都不行。
不支持else
灵活性完全比不上mako

最简单的动态产生class这样的功能,在mako直接写class="${'foo' if xx else xxx}"就行了
但在genshi里,必须要定义一个class的dict传进去,这个classes的dict还要在外部单独写函数来动态生成,麻烦的要死

还有,genshi都慢死了

相关推荐

Global site tag (gtag.js) - Google Analytics