XML to QObjects: QXmlToQObjectCreator

October 23, 2008

Thank you, to all who attended Dev Days 2008 in Munich. For me it was really great to talk to so many users and hear about all the baffling projects that people pull off with Qt. And of course, to hear how people use and what people need, in terms of Qt’s XML support.

One customer told about how sub-classes of QObject are used for representing data, and are converted to such from XML. So, why not add a little helper class to Qt for this?

The class, which currently only is a research idea and missed the feature freeze for Qt 4.5, is called QXmlToQObjectCreator, and hopefully the documentation explains it all:

QXmlToQObjectCreator API Documentation

In other words, it’s a very simple class that builds a QObject tree corresponding to the output of QXmlQuery. The current sketched code is pasted here, for those interested.

In what way can this class be made more useful?

19 Responses to “XML to QObjects: QXmlToQObjectCreator”

  1. Aike Sommer Says:

    Hi!! 🙂

    I have been working on something similar… It doesnt unmarshall arbitrary XML into QObjects, but creates a strongly typed tree of objects from matching XML! A schema-to-class compiler would make that even prettier!! 😉
    (I really love JAXB, so i wanted something along those ideas in C++ too)

    If you are interested, the code is at:
    http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/kephal/xml/

    This still needs some cleanup and docs, but is working quite well already!

    🙂

  2. Guido Seifert Says:

    Interesting. Using the SAX parser I once wrote code to create and ‘execute’ objects and ‘write’ this way to a QPrinter. Using QXmlToQObjectCreator I could have saved lots of overhead. My solution wasn’t too difficult, but with QXmlToQObjectCreator it would have been a trivial task. 😀

  3. Andre Says:

    Creating nothing for text nodes does not seem to be a great idea. Why not just set a dynamic property “text” for these?

  4. englich Says:

    What do we do if there’s an attribute named text?
    I would also like to do something sensible with text nodes, the question is what. Something which doesn’t mess up other scenarios.

    Another possibility is to attach a child object named “#text” which has a property called “content” or so. Or maybe have a property named “#text” as you say, since attributes can never have that name.

    Designed for round tripping would be nice. That is, if one serialized the XML and then read it in again, and out again, the output would be same. Let’s say a class like examples/xmlpatterns/qobjectxmlmodel/QObjectXMLModel was made part of Qt, then it would be practical if the same XML format was used. Hm..

    Maybe the question can be generalized into: what’s a good XML format for representing QObjects?

  5. JarJarThomas Says:

    I’ve written such a piece of code but not for qt already.
    For me it’s called DynStruct.
    It allows to read an xml file, create a dynstruct tree out of it, can convert back to xml.

    Also it can be serialized in a binary format for network submission.
    It has also the functionality to serialize the tree information and the values separately so it’s faster to submit data to other machines. (Send once the tree structure and then only the data for all subsequent transfers).

    It also has a kind of conversion functionality.

    An example
    Object A defines a dynstruct with a specified structure by filling it with default values.
    Even if the dynstruct read from disc is NOT exactly matching (missing values or additional values) i can assign it to the objectspecific dynstruct and the informations are merged.

    If additional tag names are defined (i can define for each tag multiple names, a default name and optional tagnames) it can do also a renaming of tags.

    Also each DynStruct works on an internal datatree wich can be shared between different dynstructs.
    So each dynstruct can walk over the tree or make another node as current rootnode without modifying code of the others.

    This class is currently my whole datasystem i need.

    It allows extreme flexible development, because no hardcoded values in my system (accessing can be done by a caching macro very efficiently based on id’s).
    Makes dataexchange extremely flexible between different machines
    and allows also more flexible architecture.

    Currently i’m extending the system with an factory mechanism to generate also functionality classes and so i can modify much of my code very easy by an xml structure.

    Sure not usefull for all cases but in my two cases
    (FlowLine simulation system and spaceship control bridge) it’s more than usefull.

  6. Guido Seifert Says:

    Hi Frans,
    the xml handling in Qt gets better and better. But of course, regardless what you provide, we still want more and more. Get used to it. 🙂

    So are there any plans to integrate the XQuery Update Facility 1.0 into Patternist? Being able to dynamically modify xml trees in a SQL like way in combination with QXmlToQObjectCreator would be awesome.

    In another thread I already asked whether there are plans to combine the search abilities of Patternist with the QDom module. However, as I see it now, I’d say Patternist + XQuery Update Facility 1.0 would make the whole QDom stuff totally superfluous. Though I might overlook something here.

  7. englich Says:

    @Guido:
    Ah yes, saw that comment, here’s the late reply:

    I’d love to do XQuery Update facility, it makes total sense. Especially in combination with QAbstractXmlNodeModel it becomes very interesting, to be able to do modifications to non-XML structures. I think we will do XQuery Update at somepoint, if only to make implementing XProc and XInclude easier behind the scenes. So, I don’t think it’s a question of if, but when, and we’re busy currently. The XSL-T stuff needs a lot of work..

    Since we’re slowly trying to fade out QDom and replace it with new things(Update Facility, other APIs) I think we will aim at that, instead of adding glue code to something which we over time will replace with better technologies.

  8. Jason Says:

    We need a way of using and generating WSDL files. We need a away to fetch a WSDL file, create a local proxy object on the fly, then call/connect signals and slots to it. This local object would then relay the requests and paramters through SOAP to the remote system.

  9. Jason Says:

    You need to abstract this further. XML is only a n-way node tree. There are 3 fundamental operations: push(), pop() and item(). “push();item();item();pop()” creates a 2-node array. “push();item();push();item();pop();pop();” creates a leaf-of-leaf list (a linked list). Aside from the data differences of the item types (attributes, etc) you can represent any structure this way. If you had say, a recursive map class, or a tree model, you could then seamlessly move from to the other. Imagine tree[“Node”][“Subnode”].value()=QVariant(“text”); Or XML: text, and make attributes be a QVariantMap avilible by attributes(). Anyway, XML is nothing more than trees, we should be able to effortlessly use XML, recursive maps, and trees interchangeably. The QObject just adds a fourth way to organize the data.

  10. Gordon Schumacher Says:

    You mentioned this briefly at the DevDays in Redwood City, but I will admit to being too much in “information overload” to really consider what this would mean.

    The reason that I’m excited by this, actually, is the possibility of using this to use the Qt XML classes to populate a QAbstractItemModel – presto, instant visualization of XML data!

    The pastebin code’s gone missing; any chance of reposting it somewhere? I’d love to play with this – I have a couple of uses for this immediately, and I’d be more than happy to provide my feedback on improvements and kudos.

  11. englich Says:

    Gordon, sorry for the late reply, maybe I could mail the files to you? Anyone who’d like the source are welcome to drop me a mail; concat(“frans.englich”, “@nokia.com”).

  12. Frank Says:

    This is extremely useful, and another class is necessary:
    QXmlFromQObjectCreator or QObjectToXmlCreator…

  13. englich Says:

    @Frank:

    We sort of already have it, see examples/xmlpatterns/qobjectxmlmodel/.

  14. frank Says:

    That is great! Thanks!

    On other things, how can I reconstruct the object tree from the output xml file? Note there could be my derived classes of QObject in the file…

    Also, how to handle shared objects? for example, A could be “owned” by B and C, in this case, one would construct A and set it to B and C. I guess this needs to use reference count to track if A is used by others, and destroy it when reference count is zero.

    Thanks!

    -frank

  15. englich Says:

    @Frank:

    Sorry for my late reply; I really think you should subscribe to the qt-interest mailing list and post a question or two there, it’s much better for these things:

    http://lists.trolltech.com/qt-interest/

  16. Christoph Says:

    Hi,

    is the example code available anywhere? This looks pretty much like osmething I’m up to. Nice idea!

    Cheers,
    Christoph


  17. It appears u actually fully understand a good deal about this issue and that exhibits throughout
    this post, termed “XML to QObjects: QXmlToQObjectCreator Profound Titles No One Gets”.
    I am grateful -Rebecca

  18. Mari Says:

    I was searching for techniques for my personal website and discovered ur blog post,
    “XML to QObjects: QXmlToQObjectCreator | Profound Titles No One Gets” optionsonstock , do you
    really care in the event I really implement a number of ur concepts?
    Appreciate it -Lois


  19. Pokemon*, and how creepy, but that first crocheted Pikachu is AWESOME! I wish i could find a pattern for that! Click https://twitter.com/moooker1


Leave a comment