QPtrDict and DOM::Node ...

[Nicolas Deschildre]

On Sun, 2003-04-27 at 23:53, Koos Vriezen wrote:
> On 27 Apr 2003, ec4 wrote:
> 
> > Sorry for the wrong subject!
> >
> > > On Sat, 2003-04-12 at 03:36, Peter Kelly wrote:
> > > > On Fri, 11 Apr 2003, Josef Weidendorfer wrote:
> > > >
> > > > > On Saturday 12 April 2003 15:36, Deschildre Nicolas wrote:
> > > > > > hi!
> > > > > > I'm currently working on the kafkapart (the WYSIWYG editor) for
> > Quanta
> > > > > > and i would like to submit you a change in khtml: In the
> > kafkapart,
> > > > > > extra information is needed for each DOM::Node to handle the
> > events, and
> > > > > > when an event is raised, the only way i have to get theses extra
> > > > > > informations is to look the quanta node(where the extra infos
> > are
> > > > > > stored) one after one to see if it is the corresponding quanta
> > node.
> > > > > > [...]
> > > > > > Any comments?
> > > > >
> > > > > Hi!
> > > > >
> > > > > I can't decide this, but some comments...
> > > > > If you add a pointer to DOM::Node, make it a QGuardedPtr to never
> > ever get any
> > > > > dangling pointers.
> 
> QGuardedPtr only guards QObject pointers
> 
> > > > >
> > > > > > I can do and commit this, but first, isn't there one simpler
> > way  to do
> > > > > > this that i've missed?
> > > > >
> > > > > Use a hash table (QPtrDict<QuantaNode>) for the lookup of the
> > quanta  node
> > > > > instead a linear search.
> > > > This is the best method IMHO, and this is how the ECMAScript
> > bindings
> > > > handle the same situation (they maintain a separate set of objects
> > > > corresponding to DOM nodes). Have a look at the ScriptInterpreter
> > class
> > > > and methods like KJS::getDOMNode() in khtml/ecma to see how to do
> > this.
> > > Thanks very much for the tip, i'll try with it and see if it is fast
> > > enough.
> > > ++
> > > Nicolas
> >
> > Hi!
> > A small problem while trying to use QPtrDict : the key is of type *void,
> > and DOM::Node isn't a pointer.
> 
> std::map ?
> 
> > 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?

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