QPtrDict and DOM::Node ...

[Koos Vriezen]

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?

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.

Koos (sleep walking :-) )