Take this with a grain of salt, because I recommend QML for everything, but I really think that QML is a great choice for a data storage language.
Every time I want to store a bit of custom data for an application, I create a QML type instead of designing an XML schema. This probably has more to do with the applications I write, but it still means you should consider QML next time you have some generic data to store. The obvious caveat – this is for data that has some serious human interaction. Maybe a human wrote it, maybe humans are going in and tweaking it all the time, maybe human readable just makes your debugging 1000x easier. But if humans never touch it then use a direct binary format, the tried and true approach from days of yore.
What started me off thinking of QML as a true data-definition language was looking at some code which used XML files for its data. As far as I’m concerned, XML is now obsoleted by QML. This code reminded me of some code in Qt demo, with all the XML parsing functions it had. Back when I did some work on QtDemo, storing the examples data in XML seemed wonderful! It was easy enough to write and maintain by hand, and it was just a couple of easy to write functions to use QXmlStreamReader to get the data out. What could be better? QML, obviously. When I looked at code like this again, I cringed at the fact that one wrote discrete functions to parse the data into the right in-memory data structure. QML, as the Qt something something, means that you can have Qt data structures direct from the human readable file. Even if you just have QtObjects with additional properties in QML, the entire parsing and data structure part is simply done for you. A couple of lines to load the component and there you are – a list of QObject, or QStrings, or the actual tree structure of your ordered data. It’s instantiated, in-memory, ready to go, and it makes loading any data as easy as .ui files made loading your UI. This is as easy as loading custom data theoretically can be, and I’m content with that.
Unfortunately, because it makes zero-sense for UIs, the writing out part is not so well automated. Theoretically you could do it in generic functions that just take a few calls, but that’s not written yet. Which makes writing the data out just as hard as in XML, but at least there is hope for the future. Then we’ll have a really nice setup for Qt programmers: your custom QObject hierarchy data structures can be saved to, and loaded from, human readable files in a couple of simple lines of code. It’s the future I see in my dreams 🙂 .
I’m not talking about doing more with QML than taking it out of the UI space. One of its primary design goals was to store UI data. This data is a hierarchy of objects, with a lot of custom properties that will be set by hand and tweaked mercilessly. QML also involves bindings for a more declarative feel that really helps humans with writing the complex systems – that isn’t actually relevant for this use case (and will usually be overwritten by the machine if you write stuff out, but it doesn’t matter if you’re storing static data). Another property of UI data that QML is good for is the creation of reusable components. Some amazing folks have already started applying the magic of QML to build systems (qbs), which I think should work great because build files are another instance of hierarchy of human-edited custom properties. I’ve used it a lot in my game prototypes, for easy and powerful game scripting of unit/map/card data. And if I re-wrote QtDemo, the examples list would be QML instead of XML, pairing more demoing of Qt with massive code savings.
Be First to Comment