Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

XML-ish Data::Dumper?

by agelina (Novice)
on Dec 31, 2001 at 11:45 UTC ( #135347=perlquestion: print w/ replies, xml ) Need Help??
agelina has asked for the wisdom of the Perl Monks concerning the following question:

I want to have XML config files for an application that are really representations of Perl objects. For example, the Perl object might contain some scalars, references to other aggregated-in objects, and some arrays. I would like to be able to freeze/thaw (persist/restore, whatever) these objects as files, but instead of using Data::Dumper's Perl-eval-able format, I'd like to use XML. This way someone who understands XML (but not necessarily Perl) might be able to edit the XML file containing the object and maybe add a new element to a list, change a scalar string, etc. When the application was run again and the file was restored as an object, the new element(s) in the list would now be in the Perl object in memory.

I think XML::Simple would be misapplied here (it doesn't like to write out blessed hash refs passed to XMLout). I think I need something more industrial strength but so far my CPAN search has been fruitless. If this does not make sense, please ask for clarification. I'm a little tired now. TIA for your help, -A.

Comment on XML-ish Data::Dumper?
(crazyinsomniac) Re: XML-ish Data::Dumper?
by crazyinsomniac (Prior) on Dec 31, 2001 at 12:22 UTC
Re: XML-ish Data::Dumper?
by belg4mit (Prior) on Dec 31, 2001 at 13:58 UTC
    Or XML::Dumper even...

    --
    perl -pe "s/\b;([st])/'\1/mg"

      Or *maybe* not. I'm not sure. The link you give says it's *alpha* quality, and I wouldn't use alpha quality stuff:
      XML::Dumper : Perl module for dumping Perl objects from/to XML [ docum +entation ]Contained in the XML-Dumper-0.4 distribution Download / quickinstall XML-Dumper-0.4.tar.gz Size: 4.732 kB Last modified: Jun 20, 1999 CPAN id: E/EI/EISEN Version: 0.4 DSLI (development, support, language, interface) informat +ion: Development: Alpha testing Support: Mailing-list Language: Perl only, no compiler needed, should be platform independe +nt Interface: Object oriented using blessed references and/or inheritanc +e

      Ok, that argument didn't sound too strong in my opinion, so I did some testing:

      F:\dev\>perl -MXML::Dumper -e"print XML::Dumper->new()->pl2xml({ {a,bl +ess {}, 'Foo'},{1,[1,2,3]}})" <perldata> <hash> <item key="HASH(0x17655c4)"> <hash> <item key="1"> <array> <item key="0">1</item> <item key="1">2</item> <item key="2">3</item> </array> </item> </hash> </item> </hash> </perldata> F:\dev\>perl -MData::DumpXML=dump_xml -e"print dump_xml({ {a,bless {}, + 'Fo o'},{1,[1,2,3]}})" <?xml version="1.0" encoding="US-ASCII"?> <!DOCTYPE data SYSTEM "dumpxml.dtd"> <data> <ref> <hash> <key>HASH(0x17655a8)</key> <ref> <hash> <key>1</key> <ref> <array> <str>1</str> <str>2</str> <str>3</str></array></ref> </hash></ref> </hash></ref></data> F:\dev\>
      So my conclusion is that XML::Dumper just dumps a bunch of xml (no DTD), and Data::DumpXML has a somewhat retarded interface (has one function, doesn't export it by default). Data::DumpXML includes Data::DumpXML::Parser for reading back the values, while XML::Dumper does it both. Either look good, although I would opt for Data::DumpXML, simply because of the DTD (and also because Giselle Ans *is* maintaining it). However, I would patch both of them to use, non oo interfaces. They would both export two functions: Dumper, and Thumper (or Undumper, Dumperun, Dumpun, punDump,...)

       
      ______crazyinsomniac_____________________________
      Of all the things I've lost, I miss my mind the most.
      perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

        I dunno, I don't have as many qualms as most other monks seem to about using newer and "alpha" quality modules. If it works for what you want, great! If not, patch it or at least poke the author. I guess one reason for this is because it seems so much of CPAN is unmaintained.

        --
        perl -pe "s/\b;([st])/'\1/mg"

Re: XML-ish Data::Dumper?
by lachoy (Parson) on Dec 31, 2001 at 21:44 UTC

    A brief meta note here: are you sure you want your configuration files in XML? My experience (which you should take with the appropriate grain of salt) has been:

    - As an application framework developer XML configuration files are great. There are readily available parsers and transformation frameworks out there, just about everyone knows enough about XML to know what's going on, and serialization to/from XML is quite easy. (There's the grey area of when to use element data versus attribute data, but whatever.)

    - As a user, I hate it. It's a PITA to edit in a normal editor, particularly when you start getting deeper and deeper into nested data structures.

    And since as an application developer I try to think of users, I don't user XML configuration files. I've found that the INI structure is expressive and easy to edit. It also prevents me from putting too much 'deep' information in a config file because INI represents very complex data structures awkwardly.

    There was an interesting discussion about these sorts of things on the P5EE mailing list.

    Chris
    M-x auto-bs-mode

Re: XML-ish Data::Dumper?
by mirod (Canon) on Dec 31, 2001 at 22:21 UTC

    The difference between XML::Dumper and Data::DumpXML is that XML::Dumper outputs a much simpler structure, while Data::DumpXML's output is more strctured and more complex. If you just want to dump the config file and read it later then it makes no difference (but then why use XML?), if you want to process it using XML tools then it depends on what you want to do.

    I would definitely use Data::DumpXML as it is more complete (it can output properly anything but code references) and as XML::Dumper is not maintained anymore.

    As a side comment I never rely on the alpha/beta/whatever status of a module, mainly because the developer is really not the one who should assign it (but then who?):

    • some modules are simple and are stable once version 0.03 is out, even though their status is never changed from alpha,
    • if the developer uses the module then it probably works for her (hence its production level, even if nobody else can use it),
    • some module authors have really high quality expectations, and give alpha status to code that would work in nearly all cases but has no bugs in really specific (and documented) cases (eg Matt Sergeant's XML::SAX::PurePerl), while others release a first version as 1.6 and pretend it's already beta (me ;--)

    Hence the need for moreModule Reviews on PerlMonks!

Re: XML-ish Data::Dumper?
by stefp (Vicar) on Jan 01, 2002 at 09:05 UTC
    If you want a data/code serialization format that is human readable and you are ready to drop the use of an XML format (which is not very human readable by BTW) you may find interesting to check out the perl module YAML written Brian Ingerson. YAML YAML stands for YAML ain't a markup-language. There are or will be a YAML module written for other languages.

    -- stefp

Re: XML-ish Data::Dumper?
by Anonymous Monk on Jan 01, 2002 at 18:53 UTC
    Can these modules turn created XML structure back to Perl structure... if needed ...
      The short answer is yes.

      The long answer is: Did you not read the original question? I quote

      I want to have XML config files for an application that are really representations of Perl objects. For example, the Perl object might contain some scalars, references to other aggregated-in objects, and some arrays. I would like to be able to freeze/thaw (persist/restore, whatever) these objects as files, but instead of using Data::Dumper's Perl-eval-able format, I'd like to use XML. This way someone who understands XML (but not necessarily Perl) might be able to edit the XML file containing the object and maybe add a new element to a list, change a scalar string, etc. When the application was run again and the file was restored as an object, the new element(s) in the list would now be in the Perl object in memory.
      Did you not read any of the replies? documentation?

      You should definetly go and read How to RTFM, it's absolutely invaluable.

       
      ______crazyinsomniac_____________________________
      Of all the things I've lost, I miss my mind the most.
      perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://135347]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (7)
As of 2014-12-28 02:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (177 votes), past polls