XML::Twig is too flexible, and too verbose. But it's really quite cool once you get it working ... You didn't give your original hash structure, so I pretended what it was.

use strict;
use XML::Twig;

my $hash = {
    name => 'bob',
    value1 => 'blah',
    value2 => 'blah2',
};

my $twig = XML::Twig->new(pretty_print => 'indented');

my $elt = create_element(newPhone => $hash);
$twig->set_root($elt);

$twig->print();


sub create_element
{
    my $gi   = shift;
    my $data = shift;

    my $t = XML::Twig::Elt->new($gi);

    if (ref $data)
    {
        while (my ($k,$v) = each(%$data))
        {
            create_element($k, $v)->paste(last_child => $t);
        }
    }
    else
    {
        $t->set_text($data);
    }

    $t;
}
[download]

$ perl x
<newPhone>
  <value1>blah</value1>
  <name>bob</name>
  <value2>blah2</value2>
</newPhone>
[download]

XML::Twig is too flexible, and too verbose.

Hey, did you try using the DOM? Now that would be what I'd call verbose!

Seriously, if you have any idea about improvements, please send them my way, I'd be glad to include them (although I don't really understand the "too flexible" bit, I would think that flexible is a quality, see Perl...).

I suppose I would put the XML::Twig::Elt docs into XML::Twig::Elt itself (or, if you have the code for XML::Twig::Elt inside XML/Twig.pm, put the pod into XML/Twig/Elt.pod). The docs are so long, it's hard to get one's head around it all. Maybe even an XML/Twig/Tutorial.pod would be nice (is there one and I'm not aware of it? If so - please put that in XML::Twig's pod! :->). The tutorial itself could just be a cookbook TOC - and there could be XML/Twig/Tutorial/NewTwig.pod (starting without any XML), XML/Twig/Tutorial/Load.pod (loading from string/file), XML/Twig/Tutorial/Handlers.pod, etc.

Too flexible:

$ perldoc XML::Twig | grep -i same.*as | wc -l
     51
[download]

You have a lot of options which duplicate each other. This simply helps obscure the unique options. I was trying to remember how to paste a twig inside another twig. Except that I didn't know it was called paste ;-). It took me probably 45-60 seconds of scanning the docs to find it. I found many ways to set the tag (gi, set_gi, tag, set_tag, ... did I miss any?), before getting paste. I also found (maybe this is just me) that paste was counterintuitive. I was expecting to tell the parent object what to insert, rather than telling the child object what its new parent is. So the first time I ran the above code, I had the create_element($k, $v) mixed up with the $t on the paste line. Of course, it didn't work. And, of course, you can't change this without breaking existing code.

Don't get me wrong - XML::Twig is great. It has made me look good in my job (which is always important). And the fact that my successor on that project is creating XML by simply printing it out is, I'm sure, going to come back and bite him in the arse. (It's not quite the same physical project - just the same idea.) It just provides, in my experience, a significant learning curve. That said, when I chose to use it, I did look at as many of the XML parsers and handlers as I could on CPAN before choosing XML::Twig. And choose it I did. Because, as you sort of implied, it's the most perlish solution, IMO.

I found the create_element function really useful, have added a slight modification to the above function to handle keys that are in turn array references

sub create_element
{
  my $gi = shift;
  my $data = shift;
  my $node = XML::Twig::Elt->new($gi);

  if (ref $data eq "HASH")
  {
    while (my ($key, $value) = each(%$data))
    {
      if (ref $value eq "ARRAY")
      {
        for my $i (@$value)
        {
          createXmlTree($key, $i)->paste(last_child => $node);
        }
      }
      else
      {
        createXmlTree($key, $value)->paste(last_child => $node);
      }
    }
  }
  else
  {
    $node->set_text($data);
  }

  $node;
};
[download]

Thanks Joseph

Is there any reason you are assembling and parsing the xml by hand as opposed to using SOAP::Lite? I have always had success using this module, especialy when passing around complex data structures via soap.

use warnings;
use strict;
use XML::Simple;

my $hash = {
    name => 'bob',
    value1 => 'blah',
    value2 => 'blah2',
};


my $xs = new XML::Simple;
my $xml = $xs->XMLout($hash,
                      NoAttr => 1,
                      RootName=>'newPhone',
                     );

print $xml;
__END__
<newPhone>
  <name>bob</name>
  <value1>blah</value1>
  <value2>blah2</value2>
</newPhone>
[download]

c.

First, there is probably a way to get XML::Simple to output what you want, but anyway, here is the easiest way I found with XML::Twig: the first new creates the root element, then the map creates its children, each created by the second new.

#!/usr/bin/perl -w
use strict;
use XML::Twig;

my %hash= ( name   => 'bob',
            value1 => 'blah',
            value2 => 'blah2',
          );

XML::Twig::Elt->new( newPhone => map { XML::Twig::Elt->new( $_ => $has
+h{$_}) } sort keys %hash)
              ->print( 'indented' );
[download]

Paul

<newPhone>
  <description>Test AXL addPhone</description>
  <name>SEP0028A9B0B21</name>
  <product>Cisco 7970</product>
  <model>Cisco 7970</model>
</newPhone>

<newPhone>
  <name>SEP0028A9B0B21</name>
  <description>Test AXL addPhone</description>
  <product>Cisco 7970</product>
  <model>Cisco 7970</model>
</newPhone>
[download]

Is this expected ? It seems to be 'the wrong thing' to me.

To answer your question: it seems short-sighted to me. But not disallowed by the XML spec. XML explicitly allows ordering to matter (think of an XHTML doc - very important that the ndoes are in the right order), but for data transfer between programs, I'd not use it unless there are duplicate elements (e.g., more than one "model" tag).

As to solving it rather than griping about it, without a huge amount of thought applied here, the way I would likely approach this is to have an XML template file, say:

<newPhone>
  <name></name>
  <description></description>
  <product></product>
  <model></model>
</newPhone>
[download]

Then I would have XML::Twig load it, and then insert the data. I am not sure that there really is a generic solution here, so here's my offering using my favourite XML editor package ;-)

use strict;
use XML::Twig;

my $hash = {
    name => 'bob',
    product => 'blah',
    model => 'blah model',
    description => 'too much money? gimme!',
};

my $twig = XML::Twig->new(pretty_print => 'indented');

## mirod pointed out that I overlooked that parse can
## indeed handle file handles.  Woops.  :-)
$twig->parse(\*DATA);

my $elt = create_elements($twig->root(), $hash);

$twig->print();


sub create_elements
{
    my $parent = shift;
    my $data   = shift;

    while (my ($k,$v) = each(%$data))
    {
        # get_xpath returns a list.  We should only every find 1
        # node, so extract that.
        my @els = $parent->get_xpath($k);
        my $el = $els[0];
        if ($el)
        {
            $el->set_text($v);
        }
        else
        {
            $el = XML::Twig::Elt($k => $v);
            $el->paste(last_child => $parent);
        }
    }
}

__END__
<newPhone>
  <name></name>
  <description></description>
  <product></product>
  <model></model>
</newPhone>
[download]

Update: Simplified my parse call, thanks mirod!

Yes, the order of elements is significant in XML. Some applications are tolerant of different element ordering, but others are picky. It seems your application is picky, so XML::Simple is definitely not the right tool for the job.

right.. so.. I either kludge this by storing a static list so I know what order to output the tags in, or I read parse the DTD every time to be completely correct, but with the drawback of the additional overhead that would create.

I think I'll just go for a static list indicating the order the tags need to appear.

The NoAttr thing might be the simplest solution, although I also like the idea of building a twig, because I think XML::Twig is more likely to produce exactly what I need than XML::Simple will be.

SOAP::Lite... well.. it might be lite, but it seems so complicated.. I'm not familiar with SOAP at all, and the docs for S:L look like they assume you already know everything about it. Maybe I'll change my code over to that at the next revision..for the moment, I've got a very limited amount of time to get this thing working, so I have to make compromises in terms of elegance in design versus having something work.

I have to wonder if mirod would take offense at implying that XML::Twig is less reliable than other choices ;-)

For something this small, XML::Twig may be overkill. But for the project we're working on at work, "just us[ing] print()" is actually less reliable. Finding and quashing close-tag errors in a multi-MB XML file is painful. Using a module, such as XML::Twig, helps to avoid these errors.

And writing a "toXML" function is exactly the same problem that the OP had - just not objectified. For these, I, personally, would still want to rely on an XML module to handle things for me.

Just my opinion... :-)

In this case you have to make sure you escape properly & and < at least (plus " in attribute values if you have attributes and use " to quote them). Writing XML is a lot simpler than parsing it, but I still would hesitate to recommend using print to a newcomer. There is enough broken XML floating around, no need to risk adding some more.

Oh, and of course you need to make sure that the encoding of your data is OK (pure ascii or utf-8) or you need to add an XML declaration with the proper encoding. And most modules won't help you much there.