QPtrDict and DOM::Node ...

[Peter Kelly]

On 28 Apr 2003, Nicolas Deschildre wrote:

> > > Does another fast method exists? Else i go back to my original
> > > proposition : a basic public class and a pointer to this basic class in
> > > NodeImpl accesible from the DOM::Node interface so that apps which want
> > > to add extra data to Nodes could derivate the basic class to include its
> > > data and "plug" it into the node. Is it OK to commit this?
> > > ++
> > > Nicolas
> > 
> > Doesn't that make khtml slower just for kafka?
> 
> Well, that will only add to NodeImpl 4 more bytes (the pointer size) and
> that's all! kafka and others apps will take care of derivating, creating
> and assigning the class adress to the Node it will slow khtml only if
> this extension is used!
> Peter Kelly just told me to use handle() for pointers... But i will get
> an NodeImpl pointer... and i don't have the NodeImpl.h public! So i
> won't be able to access the Node methods!
> 
> > 
> > Btw just a thought, but did you consider using javascript? There is
> > a DCOP function for it. Methods like
> > document.createElement/appendChild/setAttribute/.. can do anything you
> > want and probably saves some crash headaches too. Unfortunately,
> > getElementById isn't very fast currently but can be workaround, eg. making
> > lookup tables in javascript itself.
> > 
> 
> Well, my problem is speed : I need to access extra data corresponding to
> DOM::Nodes something like 20 times in Tree that can contains up to 10000
> Nodes so you see... I don't think it could be a solution.
> But tell me, is there a problem about adding the extension to the
> NodeImpl?

I don't understand what's wrong with using the dict method. This is what  
is used by the ECMAScript bindings (in khtml/ecma), which are doing 
essentially the same thing as what you want to do (associating additional
data with a node).

The main problem I have with adding a custom data pointer to node is that
it's only useful for one application at a time. If, for example you want  
to have this additional node data in your application but you are already
using another library which does the same thing for it's own data, you    
have a clash (who gets to use the data pointer?). I agree the extra 4 byte
overhead is small, but it is still desirable to avoid if possible.

The other problem is the ownership of objects in the custom data pointer. 
What happens when a node gets deleted? Should it's data pointer be 
freed/deleted as well? What if it's a shared pointer that is in use by 
multiple nodes? Using the dict method, your app has control over the 
lifetime of these objects.

Have another look at the ECMAScript bindings and see how they do it. They 
don't acccess the NodeImpl class directly; it's all done through Node (and 
derived classes). These are wrappers around the impl classes and you can 
create a node object by passing in the impl to the constructor, and then 
perform all of the neccessary operations through the Node wrapper.

> 
> ++
> Nicolas
> 
> > Koos (sleep walking :-) )
> > 
> > _____________________________________________________________________
> > Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> > http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France
> 
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France
> 

-- 
Peter Kelly
pmk at kde.org