Subject: [gdome] sumup on small pb
From: Mathieu Lacage (lacage@email.enst.fr)
Date: Sun Jan 09 2000 - 13:19:15 EST
hi,
I have come upon a small detail lately on gdome:
Nodes implement directly the EventTarget functionality.
this means we have:
gdome_n_addEventListener,
gdome_n_removeEventListener
and gdome_n_dispatchEvent
this is not consistent with our mapping of the DOM spec
our mapping would ask to have
gdome_evntt_addEventListener,
gdome_evntt_removeEventListener
and gdome_evntt_dispatchEvent
to have the latter, (I can't even think we should keep the
first one), we can do:
- a bad hack -> a wrapper around the gdome_n API
this would require removing the EventTarget from the DOM.idl
file and implement the wrapper by hand in a separate file
- a nicer solution -> we implement the Node's query_interface method
to return an EventTarget's structure when asked so.
This is exactly what query_interface was made for but the main
pb with this approach is that the user will have to call
explicitely gdome_n_query_interface before calling gdome_evntt_*
We can't do direct casting like evrywhere in gdome.
My prefered solution is the second one with a refinement.
We could define a set of macros which cast objects from Element to Node
for example. most of these macros would be just simple casts.
Here they would be a call to gdome_n_query_interface.
for example: gdome_evntt_addEventListener (GDOME_EVNTT_N (node), listener, ...)
this looks nice...
anyone firmly against this ?
if not, I'll implement the second solution next week: I'll begin on wednesday.
Mathieu
---- message from gdome@rufus.w3.org Archive at http://rufus.w3.org/tools/gdome/messages/ Unsubscribing: echo "unsubscribe gdome" | mail majordomo@rufus.w3.org
This archive was generated by hypermail 2b27 : Sun Jan 09 2000 - 09:54:01 EST