15 Apr 2008 23:15
Re: Is it possible to extend nsIDOMNode and alike?
fchen8 <at> gmail.com <fchen8 <at> gmail.com>
2008-04-15 21:15:55 GMT
2008-04-15 21:15:55 GMT
On Apr 14, 7:54 pm, Jonas Sicking <jo... <at> sicking.cc> wrote: > fch... <at> gmail.com wrote: > > On Apr 11, 6:22 pm, Jonas Sicking <jo... <at> sicking.cc> wrote: > >> fch... <at> gmail.com wrote: > >>> I have Mozilla embedded in my application through Java-xpcom. I want > >>> to attach certain reference (to Java object) to each of the nodes in > >>> the DOM tree. In another word, once I get a nsIDOMNode from Mozilla, I > >>> would like to call methods on its attached reference. I can certainly > >>> build a map and store the references in it. But it won't scale well > >>> and constantly adding/removing from a big map is kind of expensive. > >>> Since nsIDOMNode is an interface, I am thinking if I can wrap > >>> Mozilla's implementation in my own class and somehow provide that > >>> class back to Mozilla DOM then I should be able to achieve what I > >>> need. The problem now lies in how to provide the class back to > >>> Mozilla. nsIDOMDOMImplementation looks like a potential entry point > >>> but is read-only on nsIDOMDocument. Is the route I am taking even > >>> possible in xpcom? Are there any other solutions that you can suggest? > >>> Thanks in advance for your help. > >> Passing back another object is unlikely going to work. The nodes in > >> mozilla have to implement a large number of interfaces and you'd have to > >> get them exactly right for all types of nodes for things to work properly. > > >> What you could do instead is to QueryInterface the node to nsINode and > >> use the Get/Set/Delete/UnsetProperty API to store any additional > >> information about the node that you need. > > >> Note though that behind the scene that is implemented using a hash > >> table, so if you're worried about performance with that then this API > >> isn't going to help you much. > > >> That said, hash tables generally scale really well. It shouldn't be any > >> slower to use a hashtable with 1000 entries, than one with 2 (not > >> entirely true, but sort of). > > >> / Jonas > > > Thanks Jonas. I think the QueryInterface route you suggested would > > satisfy what I need. Just want to confirm that you meant nsIDOM3Node > > which has that propety API. As I understand, this means one hashtable > > per node. Is it correct? If so then there should be no performance > > issue because I won't have that many properties per node. What I was > > concerned previously was that I would have a hashtable with each of > > the node as the key, so as the number of the node increased this > > hashtable might have performance problems. > > No, I did in fact mean nsINode. The problem with using nsIDOM3Node is > that the properties you set would be exposed to web content. I.e. a web > page would be able to get to the data you stick in there, or you could > potentially even be overwriting data that the web page had stored. > > Using nsINode you can use a category which would store the data in a > place where it's separate from the data stored by the web page. > > We don't use a hash table per node no, we currently use one per > document. However the performance characteristics for a hash table is > such that that should not be significantly slower just because you store > more stuff in it. > > Have you tested to make sure that a single hash table is too slow for > your means? > > / Jonas I couldn't find nsINode in Java xpcom API. Is it exposed at all? I tried setUserData and getUserData on Level 3 DOM API and it seemed to work ok. I also tried to read it from web (getAttribute on the element) and what I got back was null. Can you clarify a little bit how the data set in nsIDOM3Node this way is exposed to web content? Thanks a lot. Feng