XML serialization functionality

Frans Englich frans.englich at telia.com
Thu Mar 16 11:47:50 GMT 2006

On Wednesday 15 March 2006 21:04, David Faure wrote:
> On Wednesday 15 March 2006 00:04, Frans Englich wrote:
> > On Monday 13 March 2006 21:39, David Faure wrote:
> > > On Sunday 12 March 2006 19:02, Frans Englich wrote:

> > The advantage I see with sub-classing
> > QXmlContentHandler(it should be that one instead of QXmlDefaultHandler,
> > on my TODO) is that the class can act as a lego-brick. The serializer
> > class can be plugged directly into arbitrary code that uses SAX, and one
> > can pipe SAX streams by chaining several content handlers.
> But the goal is to write XML, not to read it.


> I don't see the point in 
> doing this from a SAX handler.

SAX isn't limited to reading or writing, as I see it. It is a set of classes 
which allows a stream of XML events to be sent from A to B. That's what makes 
SAX nice, it is so simple.

By being a content handler, it can be plugged into /arbitrary/ code, that 
produces SAX events. To me that's surely an advantage. It's also API re-use, 
and therefore harness familarity. I don't see any drawbacks with being 
sub-classing ContentHandler, enlightenment is welcome.

It's popular in Java land:


> > I will probably think/code on this and post. I really think we should
> > lobby for Qt inclusion since it belongs on that level(IMHO), but more on
> > that later on.
> There are enough things that we need that -must- be in Qt. A completely
> independent class like this is just fine in kdelibs. After all, we're
> discussing writing KDE apps here, not Qt-only apps, right? ;)

But but but but.. I want the trolls to maintain it! 

I bet two cookies on that Qt will during 4.x add something in this direction, 
so I'm mostly trying to be one step ahead in order to avoid ending up with 
the classic "KDE class duplicates Qt class". I also think it would enrich Qt; 
I would find it practical to have it in Qt-only apps.

But right, it's not exactly the largest issue which needs worrying about.



More information about the kde-core-devel mailing list