Re: Is it possible to extend nsIDOMNode and alike?

[email protected] wrote:
> On Apr 15, 7:13 pm, Jonas Sicking <[email protected]> wrote:
>> [email protected] wrote:
>>> On Apr 14, 7:54 pm, Jonas Sicking <[email protected]> wrote:
>>>> [email protected] wrote:
>>>>> On Apr 11, 6:22 pm, Jonas Sicking <[email protected]> wrote:
>>>>>> [email protected] 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.
>> Ah, nsINode is not exposed to Java xpcom. Didn't know you were using
>> that. It's only usable from C++.
>>
>> The implementation does not know who's calling setUserData/getUserData.
>> So if you can use getUserData to get data, so can the webpage. Not sure
>> why that doesn't work for you. What happens if the webpage calls
>> setUserData to set the same data-slot. Does that overwrite the data you
>> stored?
>>
>> / Jonas
> 
> Yes, it does overwrite my data this way. I was mistakenly thinking
> that it would become part of the attributes of the element node which
> would be unacceptable. So nsIDOM3Node should be ok for me even though
> it does expose those data to web content in getUserData/setUserData.
> Do you happen to know if nsIDOM3Node use one hashtable per node or per
> document to store the user data? Thanks.

As previously stated, we use one hashtable per document. As also 
previously stated, I don't think that matters performance wise. In fact, 
we might in the future switch to one hashtable for the whole app.

/ Jonas