change HTMLDocumentImpl.getElementById(String) to first attempt lookup from
"identifiers" map, otherwise fall back to old behavior
----------------------------------------------------------------------------------------------------------------------------------
Key: XERCESJ-1200
URL: http://issues.apache.org/jira/browse/XERCESJ-1200
Project: Xerces2-J
Issue Type: Improvement
Components: DOM (HTML)
Affects Versions: 2.8.1
Reporter: Jacob Kjome
As discussed on the mailing list [1], I'd like
HTMLDocumentImpl.getElementById(String) to make an attempt at an optimized
lookup of the element by calling the superclass's getElementById(String), which
looks up from the "identifiers" hashmap. If found, it is returned. If not, it
falls back to pre-existing behavior, which walks the DOM looking for an element
with an "id" attribute of the value provided.
There's a difference between what I proposed on the mailing list and here. On
the mailing list, I proposed adding Id's to the "identifiers" map as they were
found via the fallback method. The idea was that the next time the Id was
looked up, it would be pulled from the "identifiers" map and, therefore, be
optimized. The main problem pointed out with this was the inconsistencies
between the ID'ness of the "id" attribute at document load time and after the
first call to getElementById(String), as well as the same issue after a call to
normalizeDocument().
This proposal is more limited in scope. If the Id exists in the "identifiers"
map, it is returned, otherwise it just falls back to pre-existing behavior. It
is up to the HTML document parser to properly set up the ID'ness of the "id"
attribute so Id's are either registered or not from the get-go. Note that this
can easily be accomplished using Andy Clark's NekoHTML "filters" capability [2].
I have not addressed the issue of calls to normalizeDocument() here. That
seems to be a more complicated issue, so I'd rather not tackle that here.
However, I don't think it is much of a problem. Why would someone want to
revalidate an HTML Document? There's no DTD, so there's nothing to validate.
In fact, I currently use normalizeDocument() without loss of ID'ness of "id"
attributes. I have the following properties set...
config.setParameter("namespaces", Boolean.FALSE);
config.setParameter("well-formed", Boolean.FALSE);
In any case, my proposal makes no proactive modification of ID'ness of "id"
attributes. The parser either sets them up for optimzation or it doesn't and
there's always fallback to pre-existing behavior.
Patch coming up....
[1] - http://marc.theaimsgroup.com/?t=115890536600001&r=1&w=4
[2] - http://people.apache.org/~andyc/neko/doc/html/filters.html
Jake
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
