Hash implementation of getElementById

[Thomas DeWeese <Th...@Kodak.com>]

Hi all,

    I have a working implementation of getElementById built around
a Document Hash Table.  It handles all the nasty cases pretty well.

    In writing the test I noticed some deviation from expected
behavior by the Adobe viewer as well as previous versions of
Batik.  In particular it appears that getElementById for both
always search the _entire_ document tree, even if the svg element
is 'disconnected' from the main tree.

    This behavior isn't hard for me to implement but it seems
quite wrong to me.  There was a fairly long discussion on this
in www-svg with the end of the discussion being that the DOM spec
doesn't even define what Document.getElementById is supposed to
search, much less the SVG spec specifying what
SVGSVGElement.getElementById should search.

    My current inclination would be to have getElementById
"search" the entire 'fragment' it is associated with (document
or disconnected subtree).  This still diverges from Adobe where
they will search the main tree even when called on a disconnected
subtree, but this is probably more in keeping with what will be
needed for Shadow tree's.

   Any comments?

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org

Re: Hash implementation of getElementById

[Thomas DeWeese <Th...@Kodak.com>]

Hi Cameron,

Cameron McCormack wrote:

>>   I have a working implementation of getElementById built around
>>a Document Hash Table.  It handles all the nasty cases pretty well.
> 
> Nice!  Have you handled the case where (in DOM 3) an attribute is set to
> be an id attribute?

    It does not currently, although it shouldn't be hard to
handle this.  It ties into the DOM Attribute changed stuff
and defers to the ownerDocument the decision if an attribute
is an 'id'.  So I would suspect that you might need a little
extra code to trigger an id check when some set's the idness.

    BTW I also moved getElementById up into AbstractDocument
like you did (although I didn't implement the idness check there).

> I can try to modify your implementation for the
> svg12 branch once you check it in, if not.

    Ok, I think we need to be a little careful in merging
changes between the two branches, in order to avoid making
future merges more complex.  In general I think we need to
merge whole sets of changes (like everything since the svg12
branch was created).  There are only a few more issues I
wanted to try and address before the release at which point
I would expect development to move over to the svg12 branch.

>>   My current inclination would be to have getElementById
>>"search" the entire 'fragment' it is associated with (document
>>or disconnected subtree).  This still diverges from Adobe where
>>they will search the main tree even when called on a disconnected
>>subtree, but this is probably more in keeping with what will be
>>needed for Shadow tree's.
> 
> That seems sensible to me.

    Ok, this is a smallish change.  Expect something later tonight.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org

Re: Hash implementation of getElementById

[Cameron McCormack <ca...@aka.mcc.id.au>]

Hi Thomas.

Thomas DeWeese:
>    I have a working implementation of getElementById built around
> a Document Hash Table.  It handles all the nasty cases pretty well.

Nice!  Have you handled the case where (in DOM 3) an attribute is set to
be an id attribute?  I can try to modify your implementation for the
svg12 branch once you check it in, if not.

>    My current inclination would be to have getElementById
> "search" the entire 'fragment' it is associated with (document
> or disconnected subtree).  This still diverges from Adobe where
> they will search the main tree even when called on a disconnected
> subtree, but this is probably more in keeping with what will be
> needed for Shadow tree's.

That seems sensible to me.

Cameron

-- 
  e-mail : cam (at) mcc.id.au    	icq : 26955922
     web : http://mcc.id.au/	        msn : cam-msn (at) aka.mcc.id.au
  office : +61399055779		     jabber : heycam (at) jabber.org

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org