加载的文件系统的路径。现在就来说说jinja的模板本身的语法，jinja原先用过一次，
和django template极其相似，而且有意思的是它能在{% if %}使用运算符，
可以在模板中调用函数，a()，注意是带括号的。这些方面的改进让它与
django template相比，更具灵活和简便。来看看Shorty的模板吧。
既然和django template类似，那么就有模板继承的概念了。看看它的布局模板，templates/layout.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Shorty</title>
</head>
<body>
<h1><a href="{{ url_for('new') }}">Shorty</a></h1>
<div class="body">{% block body %}{% endblock %}</div>
<div class="footer">
<a href="{{ url_for('new') }}">new</a> |
<a href="{{ url_for('list') }}">list</a> |
use shorty for good, not for evil
</div>
</body>
</html>
url_for()这个函数的调用出自哪里呢？就是前面utils.py中定义的url_for函数。
这个函数由jinja的环境设置中配置，jinja_env.globals['url_for']=url_for，通过
这样设定之后，就能在模板的上下文中使用了。
有了这个layout.html后，就可以继承{% extends %}它了，并填充
{% block body %}{% endblock %}的内容了。看看new.html
{% extends 'layout.html' %}
{% block body %}
<h2>Create a Shorty-URL!</h2>
{% if error %}<div class="error">{{ error }}</div>{% endif -%}
<form action="" method="post">
<p>Enter the URL you want to shorten</p>
<p><input type="text" name="url" id="url" value="{{ url|e(true) }}"></p>
<p>Optionally you can give the URL a memorable name</p>
<p><input type="text" id="alias" name="alias">{#
#}<input type="submit" id="submit" value="Do!"></p>
<p><input type="checkbox" name="private" id="private">
<label for="private">make this URL private, so don't list it</label></p>
</form>
{% endblock %}
e(true)是jinja的一个filter，{# #}是注释块，这里是为了不留下空白符。
templates/display.html
{% extends 'layout.html' %}
{% block body %}
<h2>Shortened URL</h2>
<p>
The URL {{ url.target|urlize(40, true) }}
was shortened to {{ url.short_url|urlize }}.
</p>
{% endblock %}
url.target, url.short_url是URL的属性，参看models.py。
urlize也是filter
看了templates之后，还缺少一个东西，就是那些静态文件css/javascript怎么弄呢？
django中是把这些静态文件分离出来交给web server处理，开发时是用一个过渡的方式来处理。
还记得在最开头的目录结构中有一个static. werkzeug是在application.py中
加入下列代码：
from os import path
from werkzeug import SharedDataMiddleware
把STATIC_PATH加入到utils.py中
STATIC_PATH = path.join(path.dirname(__file__), 'static')
既然application.py是一个dispatch的话，那就继续扮演这个角色，包装一下原先定义的
__call__()，但是self.__call__ = wrap(self.__call__)这样的用法是不对，换个用法
把原先的__call__更名为dispatch，再用新的__call__来包装dispatch.
def __call__(self, environ, start_response):
return self.dispatch(environ, start_response)
这样处理后，就到__init__函数中，安排一个包装dispatch的包装器。
self.dispatch = SharedDataMiddleware(self.dispatch, {
'/static': STATIC_PATH
})
这就是充分利用了wsgi的middleware的作用，不断来增强wsgi的功能。
在utils.py用下面的url_map替换原先的url_map = Map()
url_map = Map([Rule('/static/<file>', endpoint='static', build_only=True)])
有了这个，就可以在html中加入css的引入。
<link rel="stylesheet" type="text/css" href="{{ url_for('static', file='style.css') }}">
从上面的介绍，基本上就介绍完Shorty的主干线了。models/views/templates/dispatch，
这4个环节，让werkzeug做的wsgi application的结构渐渐清晰起来。但是感觉上还是有些乱，
这是因为它还不是一个完整的framework，如果是一个完整的framework，比如django/pylons，
它就会隐藏哪些呢？
1.dispatch，这个不必由开发人员来处理，应该由框架处理。
2.模板的衔接上，不必由开发人员以编程的方式来配置模板，
应采取更简单的作法。
3.在utils.py中可以看到很多东西，什么东西都往那一撂，像个仓库，
应该能有更清楚的作法。
但是这样的开发方式有什么好处呢？
一个就是灵活，模板是自己的，orm是用自己的，有什么wsgi middleware可用，
都能加入，而且是以一种直观的方式加入。
二是对一些小的项目，可能就是一个或两个py文件就打发，整个项目的打包简单
了，不需要用不到的功能。
三就是对开发人员来说，扩展性由自己来定，这是wsgi middleware的特点决定
的，可以不断加入wsgi middleware，增加功能。
