It seems that my initial email announcing the existence of Grantlee had too much of the wrong kind of information and not enough context. I’ve been speaking to a few people about it since at Linux Tag and elsewhere. I’ll try to address the problems here.
String Templates are not C++ templates
Some people saw ‘template system’, and assumed that Grantlee was about C++ templates. Not so. The templates I’m talking about are more like the kind of templates used for string substitution. For example, ‘Hello %NAME’ might be a template which could have ‘%NAME’ substituted for anything else. Grantlee brings a lot more features and flexibility than just plain string substitution though.
Grantlee allows ‘tags’ such as if conditions, for loops, cycles, and even custom tags using the QtPlugin and QtScript systems. An example template for a blog homepage might look like this:
<html>
<h1>My Blog, by {{ blog_owner.name }}</h1>
<h2>Recent entries</h2>
<div class="bloglist">
{% for entry in blog_entries %}
<h2>{{ entry.title }}</h2>
<h3>{{ entry.date }}</h3>
<div class="blogentry">
{{ entry.content }}
</div>
{% endfor %}
</div>
</html>
It is of course not limited to blog homepages. The entry in the above example is just a QObject with some properties title, date and content. Any application can create QObjects like this and send them to the Template to be rendered. The primary benefit of this is that Templates can come from external data files and can be changed or updated without recompiling the application. The syntax of these templates is the same as the Templates in the Django framework.
So What is Django?
Django is a web framework written in the python language. It is growing in popularity particularly with news sites. The design of Django is split into three main parts: Models, Views and Templates.
The Models system in Django represents the database of a website. It’s an abstraction layer over tables, relations, joins etc, which allows website creators to ignore the details of specific databases (eg, MySQL, postgres etc), and just deal with objects from their database. The objects might be users, blog entries etc.
The Views system in Django is the logical part. When your browser requests a page- a blog entry, or a list of recent entries for example, the Views system first queries the models system to get the data to send back to the browser. For example, a particular view might first get the 10 most recent blog entries and then render a result to send back to the browser.
The rendering of the result is performed by the Django Template system. The Template system loads some plain text files which describe the html to send back to the browser. Because the templates come from external files, and are not ‘tied to’ the view, there is a clear separation of concerns. The Views system retrieves the correct data from the database, and the Template system generates the returned html.
The view and the template do not interact with each other directly in a meaningful way. The view creates some objects (In the above case it creates a list of blog objects called ‘blog_entries’, and a blog_owner object for the title), and passes them to the Template system to render the response to the browser. This separation has several benefits. Firstly, it allows changing the appearance of the web site without changing any of the code to handle the database or the HTTP requests. Secondly, it allows the person writing the Models and the Views (concerned with logic) to be a different person to the person creating the Templates (concerned with appearance of the web page). People with good coding skills may not have good artistic abilities.
So Grantlee is a web framework written in Qt?
Nope. Grantlee is the Template part of Django described above ported over to C++/Qt. If someone was writing a web framework in Qt using a similar design to Django, Grantlee could be used to provide the templating features of such a project, but that is not the primary aim. The benefit Grantlee provides to KDE (and Qt) applications, then, is to provide easy theming capabilities to application writers. In the same way that Django Views only retrieve or create objects and then pass them to Templates for rendering, so Qt applications need only to create QObjects and pass them to Grantlee for rendering.
Templates come from external data files, which means that the appearance of the data being presented can be changed without recompiling the application or writing any additional code. Therefore, the appearance of rendered data can be decided not by the application writer, but by an entirely different person with an eye for aesthetics. There was a proposal some time ago to allow user customising of css to modify how KMail reader looks. Grantlee allows the themer to modify not only the css, but also the html code which controls how such things look.
Ok, It’s a theming system. Can I see it?
So far there are a small handful of demo applications ported to Grantlee and some screenshots here. See the template files for the books example, the dbus-chat example, and the example mail application.
What’s next? Can I use it?
Not yet. There are a few incomplete bits blocking an initial release. Next steps will probably be porting KMail and KJots to Grantlee in time for KDE 4.4. Other issues such as packaging structure and scope need to be solved too. I’ve already spoken about that to Frank Karlitschek of http://opendesktop.org/ about package structure and GetHotNewStuff integration to allow users to share themes with each other.
How do I find out more?
Come to my talk of course.
Steveire's Blog 