QPtrDict and DOM::Node ...

[Nicolas Deschildre]

On Tue, 2003-04-29 at 00:02, Peter Kelly wrote:
> 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.

Hi,
My apologies, i was mixed up with my Nodes and Trees :) Everything is OK
with the dict.
Thanks you very much for your advice.
++
Nicolas

>  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
> > 

_____________________________________________________________________
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