[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QDom usage
From:       Simon Hausmann <shaus () helios ! med ! Uni-Magdeburg ! DE>
Date:       2000-07-31 11:37:53
[Download RAW message or body]



On Mon, 31 Jul 2000, Jost Schenck wrote:

> On Mon, 31 Jul 2000, Simon wrote:
> > Anyway, the basic usage is like this:
> > 
> > - Everything is value based. You will never need/want to with with
> >   pointers in the QDOM API. That makes things extremely handy/easy
> >   and it prevents memory leaks.
> 
> BTW, I have a question about this: In a program of mine I have an internal tree
> structure of Objects that render a document. Up to now it worked like this:
> 1. I get a QDomDocument from a file
> 2. I recurse through the structure and build up my internal tree of objects
> used for rendering/editing etc.
> 3. I discard my QDomDocument
> 4. When saving again, I generate a new QDomTree from my internal tree
> 
> I wondered if it wouldn't be better if I have both a QDom tree and a rendering
> tree in memory, where a rendering object has a pointer to its corresponding
> QDomNode. I think the advantage would be, that if I read an XML-file containing
> tags/attributes/entities I don't have special rendering classes for, this
> information doesn't get lost when loading a file and then saving it again. 
> But it seems to me that this is NOT recommended and that I'll have problems
> doing it like that.
> I don't know if I made my problem clear enough :( 
> Does anybody know which is the preferred way to do such things?

I don't see any problem doing it this way. IMHO this way makes a lot of
sense design wise, and well, that's what the DOM is designed for, no?

Bye,
 Simon

 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]