Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

XML::Simple for Perl Developers 186

Posted by Zonk from the weekend-project dept.
An anonymous reader writes "XML has become pervasive in the computing world and is buried more and more deeply into modern applications and operating systems. It's imperative for the Perl programmer to develop a good understanding of how to use it. In a surprisingly large number of cases, you only need one tool to integrate XML into a Perl application, XML::Simple. This article tells you where to get it, how to use it, and where to go next."
This discussion has been archived. No new comments can be posted.

XML::Simple for Perl Developers More

XML::Simple for Perl Developers

Comments Filter:
  • Or in other words, XML-ent!

  • XML::LibXML is where it's at (Score:5, Informative)

    by teknomage1 ( 854522 ) on Saturday February 03, 2007 @08:12PM (#17877786) Homepage
    XML::LibXML is where it's at, it is a) quite a bit faster and b) has a sensible interfce rather than giving you useless empty hashrefs in the middle of a tree.

    • Re:XML::LibXML is where it's at (Score:4, Informative)

      by rvalles ( 649635 ) on Sunday February 04, 2007 @02:42AM (#17879518)
      I agree completely. I've used both recently (and XML::Xpath) and XML::LibXML is much more powerful and sane, while at the same time it is about as easy to learn. There's the added advantages that being just LibXML bindings what's learned is useful in other programming languages, and that nodes are referred using Xpath, which is a really powerful and useful W3C standard that, again, is worth learning.

  • What? (Score:4, Insightful)

    by cliveholloway ( 132299 ) on Saturday February 03, 2007 @08:47PM (#17877978) Homepage Journal

    This is the most pointless article I've seen linked from slashdot in a long time (and yes, I've seen a lot of crap here). What is the point of posting a run of the mill tutorial on something that's been covered many times before? [google.com]

    Having spent a lot of time playing with this crap lately, can I just butt into this pointless thread and say screw XML, use YAML [yaml.org] or JSON [json.org] instead. XML is a steaming, clumsy overrated turd. I benchmarked XML::Simple [cpan.org] against YAML::Syck [cpan.org] - the latter encoded 2.5 times faster and parsed nine times faster than XML::Simple. The syck library is indeed aptly named.

    "Leverage the power of XML" by deprecating it wherever you can for a more sensible cross platform format.

    </rant>

    • Re: (Score:1)

      by archen ( 447353 )
      I'm a YAML convert myself. I used to use XML::Simple quite often for configuration files but generally wasn't to happy with the readability of what it generated. YAML by contrast was pretty easy to read and write your configs by hand if you wanted (a pain with XML). However XML isn't going anywhere soon. In some industries XML is just now starting to grab attention for interoperability and I've had to deal with XML stuff that was just handed to me more and more. In that sense XML::Simple has made my li
    • Ignoring the YAML/XML thing, this is still pointless. How many people using Perl don't know how to use CPAN? How many people using Perl can't understand CPAN docs? How many people reading the XML::Simple docs need further help? It's called XML::Simple for a reason! It really IS simple.
    • Are there XML-RPC equivalents for YAML and/or JSON? Although I'm sure it would be easy to create something I am just wondering if there is any sort of standard.

      How do you process YAML or JSON in Javascript (eg. in a browser)? Most browsers have built-in support for processing XML.

      • Re: (Score:1)

        by maxume ( 22995 )
        eval('(' + json + ')'). There are libraries if you don't trust your source:

        http://www.json.org/js.html [json.org]

        is one.

        • Executing your configuration files? Worst idea ever. (Yes, I'm aware you offer an alternative. It's still... twisted.)

      • Re: (Score:2)

        by hoggoth ( 414195 )
        > How do you process YAML or JSON in Javascript (eg. in a browser)? Most browsers have built-in support for processing XML

        Wow, that must be great having support for XML built into Javascript.
        Oh, by the way, JSON is expressed in valid Javascript syntax. That means JSON is already Javascript. No libraries or support necessary.

        Sorry for the snarkiness. 'Been struggling with some XML code. That always puts me in a bad mood.

    • Re:What? (Score:5, Funny)

      by jtolds ( 413336 ) on Saturday February 03, 2007 @10:13PM (#17878358) Homepage
      "Leverage the power of XML" by deprecating it wherever you can for a more sensible cross platform format.
      </rant>

      1. Advocate XML deprecation.
      2. Use XML style conversation markers.
      3. ???
      4. Profit!!!

    • XML is a steaming, clumsy overrated turd
      You don't like it much then!? ;-)
      • Can you tell I was in a bad mood? :)

        No, I understand that it *can* be well used, just that for 90% of the applications it *is* used for appear to only be using it because the author once read somewhere that leveraging XML was the way forward. If you're dealing with data storage only, XML is always the wrong answer(*).

        cLive ;-)

        (*) unless the question is, "What is the worst format to store configuration data in?" :)

        • Re: (Score:1, Funny)

          by Anonymous Coward
          (*) unless the question is, "What is the worst format to store configuration data in?" :)

          I can think of worse. How about a flat namespace populated with pairs of the form (name, number). After that list, you can have a giant (about 2^19940 bytes long) of 8 byte values, related to the pairs as follows: the key with name 'pair' has the value stored in the M(number)th bin, where M is the Mersenne Twister function. [wikipedia.org]

    • Re: (Score:1)

      by sporb ( 710088 )
      See -> Perl::Troll
    • I agree that the article is pointless. XML::Simple is the oldest Perl XML library in existence, and there are better alternatives available. How does YAML::Syck hold up against XML::LibXML for performance? Is the syntax as easy to use as XML::XPath? Who else uses YAML? I don't want to invest my time in a data format that no one else uses.
      • I don't know but I'm sure you can Benchmark them :) Even if no one uses it, your own apps will be faster. All depends what area you work in, I guess.
    • Hey thank you for pointing this out. I did not know about this. JSON and YAML are pretty nice.
    • Why are you using an XML parser within an inner loop? Or if you aren't, why are you benchmarking it? I still don't like XML, though, it's just not pretty.
    • Thanks for the pointers to YAML and JSON, both of which I thought were interesting. However, I think you're comparing apples and oranges in a couple of different ways. Benchmarking XML::Simple against YAML::Syck doesn't really make sense, because nobody is claiming that XML::Simple should be used on large files, or for performance-intensive applications; its claim to fame, compared to other XML parsers, is just its ease of use. JSON seems like a sensible format to use if what you're basically doing is seria
  • I just today noticed the announcement of XML::Tiny [cpan.org].

    • hmm (Score:3, Informative)

      by XanC ( 644172 )
      It only claims to support a subset of XML, and of course it is called "Tiny", so I guess I can understand not supporting CDATA or attributes (...maybe). But for a ">" in a CDATA block to cause it to fail? It doesn't seem very useful.

      • Re: (Score:1)

        by orkysoft ( 93727 )
        It's still useful if you're only using it to read a limited kind of files, such as configuration files that were generated by the program itself. Of course, when the program needs to parse XML files generated by other programs, a more comprehensive module is needed.
    • Flame me if you want, but that guy's comments at the end of his README, and the link to his Wishlist page, are just too much. Chime in if you read it. /rolls eyes

  • A good tool for small tasks, but... (Score:3, Interesting)

    by Scareduck ( 177470 ) on Saturday February 03, 2007 @09:23PM (#17878142) Homepage Journal
    ... utterly useless for anything of real size. XML::Simple is a huge memory sink, because, as mentioned elsewhere, it insists on generating full hash and array representations of the source XML text. This seems to be the side effect of taking too seriously a lot of Perl advice enthusiastically handed out in the older documentation. (Put file text into a huge array! Don't close your file descriptors!) The rest of us know better.

    • I came in here to say this (Score:5, Interesting)

      by Wee ( 17189 ) on Saturday February 03, 2007 @10:37PM (#17878456)
      Was exactly what I was going to say. I've used XML::Simple a lot, but only for reading in small documents, like config files. It works well for that. But I'd never use it on something that was bigger than, say, 100K. It's too slow and resource intensive. It does, however live up to its name. It's a very simple interface to an XML doc.

      One thing I user it for was representing a database in XML. Once I had the DB layout in a datastructure, it was one line to print it out. Of course, this was before I knew about DBIx::XML_RDB...

      -B

    • The rest of us know better.

      Hey now, it depends on the context. Sometimes it is good to just put text into a huge data structure. Sometimes it's not. In the end, a smart programmer who understands the issues is better than a rule.

      Cheers.
  • In my personal experience, Simple is probably the worst implementation of an XML parser in perl. For a simple implementation, I have found Twig to be much more useful, sensible and fast.
  • This is the same approach that is built-in to the qore language http://qore.sourceforge.net/ [sourceforge.net].

    It makes it really easy to manipulate data in XML format.

    However, qore supports deserialization of mixed text and data and multiple out-of order elements, XML attributes (imagine parsing a docbook file for example), as well as serialization (conversion of a qore data structure to an XML string) with the same features.

    The same limitations regarding streaming input and very large files affect this approach, but in all
  • The author of that article says you'll want to use the magic of perl and XML::Simple because "XSLT can't do arithmetic" and proceeds to do magical things like increase numbers by 20%.

    That's just ... bizarre. Of course you can do that with XSLT! <xsl:value-of select="whatever * 1.2">

    Then he formats a number -- because XSLT, of course, doesn't have a format-number() [w3schools.com] function.

    Next article -- why you should commute to work in an airplane because, as everyone knows, cars can't turn corners.
    • XSLT is disqualified because it's impossible to do anything of any complexity in it without going insane.

      Not only is the syntax horendously complex, but there are major misimplemented features that force strange and illogical workarounds, but people used to real programming languages have a really hard time grasping the template style leading to even more frustrations.

      XSLT is a complete paradox, on one hand it's supposed to let non-programmers manipulate xml, but at the same time it's so hard to use that pr
  • I used XML::Simple in a script I wrote to grab data from my garmin GPS to use at http://www.gpsvisualizer.com/ [gpsvisualizer.com] Worked great without a lot of extra stuff to learn for a simple task.
  • I'd looked into XML::Simple some time back, and gave up because I couldn't successfully install it. So again I went through IBM's install instructions, starting with that "perl -MCPAN" command, which of course told me at the start that I already had a ~/.cpan directory. Anyway, it seemed to be going ok until the "make install", which ended with:

    Running make install
    Warning: You do not have permissions to install into /usr/local/lib/perl5/site_perl/5.8.8/mach at /usr/local/lib/perl5/site_perl/5.8.8/ExtUtils

Slashdot Top Deals

"Nuclear war can ruin your whole compile." -- Karl Lehenbauer

Close