For years I’ve been absolutely certain that I really prefer stupid template languages any time I’m generating HTML. The less the template language can do the better. Since I spend most of my time coding in Python you might assume this applies just to Python, but I think it also applies to anything where you have the power to readily mix HTML generation and code.

The biggest annoyance I have with smart template languages (Mako, Genshi, Jinja2, PHP, PerlColdFusion, etc) is that you have the capability to mix core business logic with your end views, hence violating the rules of Model-View-Controller architecture. While the web can be hard to match to MVC, in general you aren’t supposed to do that sort of thing. I’ve made the mistake of putting core logic in the wrong places in the past, but I’m proud to say I’ve gotten good at avoiding that particular mistake.

I don’t work in a vacuum.

I often work on projects crafted by others, some who decided for arcane/brilliant/idiotic reasons to mix the kernel of their applications in template function/macros. This is only possible in Smart Template Languages! If they were using a Stupid Template Language they would have been forced put their kernel code in a Python file where it applies, not in a template that was supposed to just render HTML or XML or plain text.

What it comes down to is that Smart Template Languages designers assume that developers are smart enough to avoid making this mistake. Stupid Template Languages designers assume that developers generally lack the discipline to avoid creating horrific atrocities that because of unnecessary complexity have a bus factor of 1.

So what is a Smart Template Language?

In my own vernacular, template languages that let you write functions/macros are what I call a Smart Template Language. Some of them are brilliantly executed, the example of Jinja2 comes to mind, but invariably I suffer through abuse of its Macro control structure as implemented by others.

Misery Cubed a.k.a. Genius Template Languages

Next comes Genius Template Languages, which take things a step further. These template languages allow you to not only define functions/macros, but also let you embed unrestricted Python (or Java or Ruby or whatever) in the template. This ‘feature’ lets you code your entire application in the templates!  In the Python world what comes to mind is Mako and Genshi, but I’m sure there are many other tools with this ‘capability’.

I like Stupid Template Languages!

Stupid Template Languages don’t let you define functions/macros. They don’t let you embed Python code. They barely let you define variables and often have simplistic control architectures.

For Django efforts, which is about 70% of my work, I like the Django Template Language (DTL). Since it is used by a huge community, there are a ton of useful apps which have it as a dependency. Switching away from it would mean cutting myself off from a large ecosphere of tools I can use to not reinvent the wheel.

Back in my Zope/Plone days I really, really enjoyed the Template Attribute Language (TAL) because it was stupid too. If I needed an XML generation template language and could import it easily I might consider using it again, or perhaps Chameleon, which is a new, improved version . The downside is that they come paired with another tool paired with it, METAL, which gave it macros. My own experience with METAL is that it was all too easy to do what we developers do with Smart Template Languages.

But DTL and TAL are slow!

So what?

If you want to boost your performance, first try caching. There are a ton of tools you can use, with Varnish being one I keep seeing in action. Read the docs on your favorite web framework’s caching engine and apply what you learn. And Djangonauts should read up on Mike Malone as much as possible.

If after all that the site still delivers slow content and it appears to be a template language issue, then identify the bottleneck content and consider alternatives for that one portion. My favorite response is a bit of AJAX. Use your framework to render the content as JSON and have JavaScript parse it into legible content, a task which JQuery makes trivial.

From: http://pydanny.blogspot.com/2010/12/stupid-template-languages.html


前几天,抽时间把原来的一个Django项目移植到了Google App Engine上,在Google App Engine上面使用Django还是挺方便的,主要有两个主要项目用于帮助更好的使用Django。以下是这两个项目:

Google App Engine Helper for Django


这两个项目的出发点不一样,但我没有使用过app-engine-patch,所以对个项目的评价是不搞谱的。Google App Engine Helper for Django引入了一个经过修改了Model基类,以使之能在Google App Engine上使用Django的model功能。

总的来说Google App Engine Helper for Django这个项目能帮助你尽快的将Django项目移植到Google App Engine上去。

















def remember_me(view_func):
    def _dec(request, *args, **kwargs):
        if request.POST.get(‘rme’) == ‘1’:
        return view_func(request, *args, **kwargs)
    return _dec



在设计站点的时候,也许会有这种情况:当用户注册后,直接帮当前用户登陆,这时可以使用from django.contrib.auth import login的方法来完成用户的状态的改变,但这里有点问题,就是在设置session的时候,会设置一个BACKEND_SESSION_KEY这个东西,如果你使用默认的login view的时候使用from django.contrib.auth import authenticate来对User对象设置一个值。如果不使用authenticate的话,那只有手工自己设置了:

new_user.backend = “%s.%s” % (‘django.contrib.auth.backends’, ‘ModelBackend’)







Signals这个东西是非常有用的一个机制,但这个东西还没有正式的文档。所以知名度不是很高,但还是有一个Wiki页面说明了这个东西使用。其实Signals在Django中有大量的应用,比如:在初次syncdb的使用,会让你创建超级管理员,在这里就有一个Signal,post_syncdb,当系统执行syncdb的时候,会调用已监听的方法,通过这个方法实现创建超级管理员向导。系统自带许多Signal,其中有个post_save,这个Signal用于监听Model对象保存后,执行的操作,比如:在现在中都会添加一个UserProfile来扩展User Model,但自带的添加用户方法,并不会添加UserProfile,所以可以使用post_save来监听User Model,当创建User之后,再创建UserProfile,这样不必修改Django源代码就可以使用。当然你也可以使用Manager来完成这个操作,这就是我说的重复部分,怎么用那就看自己的了。



sys.path.append(os.path.join(os.path.dirname(__file__), DJANGO_THIDR_COMPONENTS_PATH))