Grantlee v0.2 (codename Doppelt-gemoppelt) now available

The Grantlee community is pleased to announce the release of Grantlee version 0.2 (Mirror).

This release is source and binary compatible with the 0.1 series. Initially I thought I’d be able to make the 0.2 release in August with few changes other than the version number bump. Linux 3.0 was just out at the time and I thought it would be fashionable, but I kept finding new things to get done. Besides I have trouble counting past nine (zero-indexed) without taking my socks off.

For the benefit of the uninitiated, Grantlee is a set of Qt based libraries including an advanced string template system in the style of the Django template system.

  {# This is a simple template #}
  {% for item in list %}
    {% ifequal item.quantity 0 %}
      We're out of {{ item.name }}!
    {% endifequal %}
  {% endfor %}

String template systems are very common in the world of web frameworks. In such web frameworks it is common common requirement to decouple data retrieved from a database and processed in some way from the presentation of that data. Typically it is presented in the form of html output, so most string template systems are optimised for html output including special handling of html entities and protection from cross site scripting exploits.

In the context of Qt, we already have several ways to separate data from its presentation in user interfaces. Apart from the more low level model view framework we have the more recent addition of QML for flexible QMetaObject and property based relations.

Grantlee is also in an abstract sense a QMetaObject based language, though it can be extended beyond the qmetaobject apis too. It is not suitable for user interfaces comparable to the way QML is though. Grantlee is more suited to creation of static output suitable for theming, and reports iterating over already processed data, which is recreated on demand and non autonomously, unlike QML. This of course is suitable for markup based user interface with stateless data connections. I wonder if there is a usecase for creation of locally processed static data based on varying inputs which is automatically regenerated when those inputs change which is not already satisfied by QML. Something to investigate in the future perhaps.

At about the same time though i discovered testcocoon and have been working with testcocoon developer Sébastien Fricker on coverage instrumentation for Grantlee. The motivation is more generally about learning how to use testcocoon with Qt and CMake projects. This is in anticipation of making it possible to gather coverage data for KDE productions in the future. The effort has led to a good deal of work by Sébastien on both testcocoon itself and on Grantlee to ensure useful coverage data collection. Some of the changes required relate to specifics of loading plugins, some crash fixes, and some issues associated with buildsystem integration and peculiarities of unit testing private api.

The result is some clear indications of what parts of Grantlee are adequately unit tested, and which are not. There are some false positives still produced by testcocoon such as in unit tests but I’m confident that will continue to improve. The good news is that most hard parts of Grantlee are unit tested. Ideally there should be no such thing as an edge case when considering what should be unit tested though. Increasing the coverage stats of Grantlee will be a focus for the next while. The coverage report generated by gcov and lcov is also available for this release.

Coverage result for part of Grantlee

Another set of changes since the 0.1.9 release is concerned with the buildsystem. I’ve learned a lot about CMake since starting with Grantlee; and I have been able to apply that knowledge to increase the 0-knowledge portability of Grantlee. 0-knowledge portability refer to the portability of Grantlee to platforms I have no access to. Features are enabled as much as possible by testing their availability rather than testing for platforms known to support certain features. For example some of the Grantlee unit tests require some third-party containers for testing. I’m able to test for both tr1 and boost to use as third parties when running those tests.

Enjoy!