[ANN] The Grantlee template system

Stephen Kelly steveire at gmail.com
Thu Jun 18 13:15:06 BST 2009


If you've looked through the schedule for Akademy you might have seen my talk about the Grantlee template system. If you were really curious you might have googled for it and found only another talk about it and and empty git repository.

I've finished most of the design changes I wanted to make to the system and so I pushed to the repo today.

Grantlee is a string template system which follows the syntax of the Django template system. For comparison, the Django template system can be found here:

and the tests here:

The generated apidox for Grantlee are here:

This is not a release announcement. There's a couple of blockers to releasing Grantlee v0.1.

Here's the story do far:

* Core library follows the same design as the Django system and allows the same extensions (tags, filters, loaders).
* Extensible using QtPlugin system. Tags and filters can be written in C++.
* Tags and filters can also be written in QtScript.
* Depends only on QtCore, QtPlugin and optionally dependency on QtScript through the plugin.
* Default tags library and loader tags library from Django are ported to Grantlee.
* Default filters library started, but not yet finished
* Over 350 data driven regression tests covering the core, the loader tags and the default tags.
* All tests run clean in valgrind with the suppression file in scripts/qt.supp
* Some consumer-level apidox written, but none of the classes are documented yet.
* A handful of examples already exist in playground/pim/akonadi and demos/books and examples/dbus/dbus-chat in my qt clone. The qt ones will probably be forked into Grantlee before release.
* It's not limited to HTML- There's no reason you couldn't generate ODF with this.
* There's still a few API warts lying around, but I'm not guaranteeing API stability for a few releases anyway.
* The design is extended a bit from Django to handle different environments and use cases. In particular Django templates typically have the lifetime of one HTTP request and need only one configuration at a time.
* The differences between Grantlee and Django are documented here: http://grantlee.org/apidox/differences_django.html
* It's not threadsafe, but it might not be a lot of work to make it threadsafe. That'll might come before 0.1.
* i18n support is not yet implemented. I'm not certain how to implement it in a way that works in both Qt systems and KDE systems.
* I will respond to merge requests :)

The release blockers are
* Implement secure path resolution in the file system. (see Templates::test_loaders_security in http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/templates/tests.py)
* Fix the build system. The stuff I've written only shows my ignorance of CMake. (Should I package findGrantlee.cmake with Grantlee?)
* Implement the default filters and tests from Django. This should mostly be pretty quick to do. (http://code.djangoproject.com/browser/django/trunk/django/template/defaultfilters.py, http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/templates/filters.py)
* The mutable template stuff and enginestate stuff still needs to be finished.
* The error handling needs to be rethought.
* Get review. Hopefully some will come from here.

I've already delivered two talks on this. One to Qt experts who didn't know Django, and one to Python Ireland who knew all about Django, but nothing about Qt. If there's anything in particular you'd like to see covered at my Akademy talk (ie, how it works, or how to use it, or how to write themes in it or demos, etc), let me know.


Other future developments with this will include:
* Kross support. I've already spoken to Sebastian Sauer about this, it shouldn't be too hard to do.
* Benchmarking against XSLT based solutions which provide similar features
* Porting some KDE applications for KDE 4.4- Initally, KJots, KMail and probably KNode. I'm aiming to finally close this bug report https://bugs.kde.org/show_bug.cgi?id=171849 :).
* GHNS support in the applications. This will mean coming up with some kind of standard package structure.
* I'd like to see this become *the* way to theme exported data from KDE apps. Consistency of syntax and package structure is probably useful for themers.

Grantlee, being written in C++ might be faster than the Django system, so I also had the suggestion of porting Django itself to Grantlee.

If you've made it this far, you'll probably only have one question left: Why is it called Grantlee? You'll have to come to my talk to find that out. :p

All the best,


More information about the kde-core-devel mailing list