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

Report information
The Basics
Id:
39828
Status:
resolved
Priority:
Low/Low
Queue:

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

BugTracker
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
#!/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>
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
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>
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 runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

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