Skip Menu |
 

This queue is for tickets about the XML-LibXML CPAN distribution.

Report information
The Basics
Id: 20833
Status: resolved
Priority: 0/
Queue: XML-LibXML

People
Owner: Nobody in particular
Requestors: robin.berjon [...] gmail
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in:
  • 0.91
  • 0.92
  • 0.93
  • 0.94
  • 0.96
  • 0.97
  • 0.99
  • 1.00
  • 1.30
  • 1.31
  • 1.40
  • 1.49
  • 1.50
  • 1.51
  • 1.52
  • 1.53
  • 1.54
  • 1.54_0
  • 1.54_1
  • 1.54_2
  • 1.54_3
  • 1.54_4
  • 1.55
  • 1.56
  • 1.57
  • 1.58
  • 1.58_1
  • 1.59
Fixed in: (no value)



Subject: getElementById does not exist
Download (untitled) / with headers
text/plain 477b
Hi, the DOM method to get an element by its ID is getElementById, but in XML::LibXML that's for some reason called getElementsById (notice the "s"). The original error is a typo, but since a lot of code probably relies on it it can't just be changed: the fix is to provide an alias for the correct name. I think I reported this (with patch) before there was RT, but it's still not fixed :) I can't find the patch now but it's just a one line method alias. -- --darobin
Hi Robin, I fixed it in the axkit Subversion repository (the old name is only kept as a compatibility alias, as I stated in the docs), together with some related improvements: 1) I reimplemented this method. Previously, getElementsById was just findnodes("id('$id')"), which has some overhead unnecessary overhead, which becomes apparent if the method calls are extremely frequent. 2) I added $attr->isId DOM Layer 3 method 3) make getAttribute/setAttribute/hasAttribute/getAttributeNode/...etc now work with full attribute names rather than just localnames (sic!). Although DOM Level 3 spec is not very clear about the behavior of these methods for attributes in a namespace, it certainly does not imply that getAttribute('foo') should return value of a bar:foo, which was the old behavior. 4) all NS variants of these methods should now also work correctly for attributes without namespace if nsURI is undef (as required by the specs) This should appear in 1.60 when it's out (won't take as long as 1.59 :-)). Dahut! -- Petr
CC: RBERJON [...] cpan.org
Subject: Re: [rt.cpan.org #20833] getElementById does not exist
Date: Sun, 6 Aug 2006 21:26:57 +0200
To: bug-XML-LibXML [...] rt.cpan.org
From: Robin Berjon <robin.berjon [...] expway.fr>
Download (untitled) / with headers
text/plain 1.8k
Hi Petr! On Aug 04, 2006, at 23:23, via RT wrote: Show quoted text
> 1) I reimplemented this method. Previously, getElementsById was just > findnodes("id('$id')"), which has some overhead unnecessary overhead, > which becomes apparent if the method calls are extremely frequent. > > 2) I added $attr->isId DOM Layer 3 method
That's very good news, thanks! Show quoted text
> 3) make getAttribute/setAttribute/hasAttribute/getAttributeNode/...etc > now work with full attribute names rather than just localnames (sic!). > > Although DOM Level 3 spec is not very clear about the behavior of > these methods for attributes in a namespace, it certainly does not > imply that getAttribute('foo') should return value of a bar:foo, which > was the old behavior.
I agree that the DOM is not as clear as it could be on these, and after having spent quite a long while working on specifications related to it I am happy to help if you have any doubts on any part of it. You are entirely correct that the non-NS methods shouldn't return attributes based on their local names, they should return them based on their qualified names (i.e. the .nodeName property). Show quoted text
> 4) all NS variants of these methods should now also work correctly for > attributes without namespace if nsURI is undef (as required by the > specs)
Does it work the same for the empty string and for undef? There is no normative binding for Perl, but I think that the two should behave the same. More importantly, if .namespaceURI returns undef when created with an undef namespace, it should still return undef when created with an empty string namespace. Likewise for elements. The normalisation is important for interoperability. I can investigate further into test cases if you have doubts. Dahut, and thanks a *lot* for maintaining this very essential module! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Download (untitled) / with headers
text/plain 998b
Show quoted text
> > 4) all NS variants of these methods should now also work correctly
for Show quoted text
> > attributes without namespace if nsURI is undef (as required by the > > specs)
> > Does it work the same for the empty string and for undef?
It should, at least that was my intention when doing my revision of the code. Show quoted text
> There is no > normative binding for Perl, but I think that the two should behave > the same. More importantly, if .namespaceURI returns undef when > created with an undef namespace, it should still return undef when > created with an empty string namespace. Likewise for elements. The > normalisation is important for interoperability. I can investigate > further into test cases if you have doubts.
If you have time, I would very much appreciate if you could contribute some test cases to be included in our test-set stressing specifically these aspects of the API (I case they fail, I'd of course fix the code). I'm closing this ticket now, you know my mail. Thanks, -- Petr


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.