Skip Menu |
 

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

Report information
The Basics
Id: 39828
Status: resolved
Priority: 0/
Queue: XML-Twig

People
Owner: Nobody in particular
Requestors: AZED [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 3.32
Fixed in: 3.33



Subject: XML::Twig::XPath breaks XML::Twig::Elt->set_text()
(This is the same issue as in the e-mail I sent earlier. RT came back sooner than I was expecting.) I've discovered that set_text('sometext') stops working for twig elements that are found as descendants of a XML::Twig::XPath twig, but works fine for XML::Twig twigs. The version in use is 3.32, as provided by Debian. Both XML::XPath and XML::XPathEngine are present. I have attached a simple test case extracted from the chunk of my own project. If you run that with a XML::Twig::XPath object, you get back: Query: #PCDATA... ^^^ Invalid query somewhere around here (I think) If you switch to just XML::Twig, it works fine (but then you can't use XPath functions like name() to reduce the search to a single search). If you use set_pcdata instead of set_text, it stops complaining, but the change doesn't appear to be actually made, either -- but this may be a separate bug, since set_pcdata doesn't appear to do anything even when using XML::Twig (or perhaps I misunderstand what it's supposed to do). Using set_cdata() actually modifies the data and works with XML::Twig::XPath, but isn't what I actually want.
Subject: twigbug.pl
Download twigbug.pl
text/x-perl 1k
#!/usr/bin/perl use strict; use warnings; use XML::Twig::XPath; my $twig = XML::Twig::XPath->new(pretty_print => 'record'); #my $twig = XML::Twig->new(pretty_print => 'record'); $twig->parse(\*DATA); my @dates; @dates = $twig->root->findnodes('//dc:date'); push @dates,$twig->root->findnodes('//dc:Date'); #@dates = $twig->root->findnodes("//*[name()='dc:date' or name()='dc:Date']"); #@dates = $twig->root->get_xpath("//*[name()='dc:date' or name()='dc:Date']"); foreach my $dcdate (@dates) { print "Changing '",$dcdate->text,"'\n"; $dcdate->set_text('bad date'); # $dcdate->set_pcdata('bad date'); } $twig->print; __DATA__ <package version="2.0" xmlns="http://www.idpf.org/2007/opf"> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf"> <dc:title>A Noncompliant OPF Test Sample</dc:title> <dc:date event="creation">2008-01-01</dc:date> <dc:Date event="publication">03/01/2008</dc:Date> <dc:date opf:event="badfebday">2/31/2004</dc:date> <dc:Date opf:event="YYYY-xx-DD">2009-xx-01</dc:Date> </metadata> </package>
Download (untitled) / with headers
text/plain 664b
It seems this bug is already fixed in the development version at http://xmltwig.com/xmltwig (and no, I can't figure out why!). Let me know if it works for you. You also mentioned problems with findnodes, get_xpath and find_nodes in your email: if get_xpath or find_nodes is called and fails, while the twig is an XML::Twig::XPath, I will make sure that the error message mentions the fact that findnodes might be different. I only replaced findnodes because originaly, before I created XML::XPathEngine, "native" regexp matching ( /foo[string()=~ /^toto/]) wasn't available, so I gave the option to still be able to use the original methods. Thanks __ mirod
Download (untitled) / with headers
text/plain 973b
I got a couple of odd messages during testing (though all tests that executed passed successfully): option do_not_escape_amp_in_atts not available, probably due to an old version of expat being used: skipping 1 tests and can only test set_strict_namespaces with XML::XPathEngine 0.09+ installed: skipping 12 tests but later down in the configuration it notes that it found: expat : 2.0.1 (required) ... XML::XPathEngine : 0.11 (to use XML::Twig::XPath) XML::XPath : 1.13 (to use XML::Twig::XPath if Tree::XPathEngine not available) That's the latest version of expat that I know of, and XPathEngine is above 0.09. After it was built and installed, however, I ran my original test sample again and set_text() worked fine... but set_pcdata() is still a no-op. Is set_pcdata() supposed to be doing the same thing as set_text for that kind of node? Should I file a separate RT bug for that?
Subject: Re: [rt.cpan.org #39828] XML::Twig::XPath breaks XML::Twig::Elt->set_text()
Date: Mon, 06 Oct 2008 18:28:55 +0200
To: bug-XML-Twig [...] rt.cpan.org
From: mirod <xmltwig [...] gmail.com>
Download (untitled) / with headers
text/plain 1.8k
Zed Pobre via RT wrote: Show quoted text
> Queue: XML-Twig > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=39828 > > > I got a couple of odd messages during testing (though all tests that > executed passed successfully): > > option do_not_escape_amp_in_atts not available, probably due to an old > version of expat being used: skipping 1 tests
Yes, I get this one too at the moment. The seldom used do_not_escape_amp_in_atts cannot be used with old... and very recent versions of expat. I have to investigate this one, or at least change the warning Show quoted text
> can only test set_strict_namespaces with XML::XPathEngine 0.09+ > installed: skipping 12 tests
Weird. I don't get this one. The test is not done on the version of XML::XPathEngine, but on the fact that XML::Twig::XPath offers the set_strict_namespaces method. Show quoted text
> > but later down in the configuration it notes that it found: > > expat : 2.0.1 (required) > ... > XML::XPathEngine : 0.11 (to use XML::Twig::XPath) > XML::XPath : 1.13 (to use XML::Twig::XPath if > Tree::XPathEngine not available) > > That's the latest version of expat that I know of, and XPathEngine is > above 0.09. > > After it was built and installed, however, I ran my original test sample > again and set_text() worked fine... but set_pcdata() is still a no-op. > Is set_pcdata() supposed to be doing the same thing as set_text for > that kind of node? Should I file a separate RT bug for that?
Using set_pcdata on a non-text element is useless, unless you set the tag name to '#PCDATA'. Bottom line, you should use set_text. And I should have added an error check a while ago, except that now I am not sure it's really possible, as people might be relying on that behaviour (and indeed first set_pcdata then set_tag( '#PCDATA')). I have at least changed the docs. Thanks


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.