Really? That seems like a better alternative than writing your own dispatch table? Even using the built in handlers, you still have to write the subroutines themselves. I guess from an abstraction perspective it is appealing but consider my existing code looks like:

my $twig = XML::Twig->new();
while (<$fh>) {
    $twig->parse($_);
    # ...
}
[download]

Will now need to look like:

while (<$fh>) {
    my $twig = XML::Twig->new($data_struct);
    $twig->parse($_);
    # ...
}
[download]

I have no idea the extent of the performance overhead but it is probably less than the alternative:

my $twig = XML::Twig->new($data_struct);
while (<$fh>) {
    $twig->parse($_);
    # ...
    my $copy = deep_copy($data_struct);
    $data_struct = clear_structure($data_struct);
}
[download]

I am not saying it is a bad idea - it just doesn't feel clean to me.

Cheers - L~R

Hmm I guess it's just a question of personal style what "clean" is. But I do actually agree with the idea of the dispatch table, it's just that I would put that in the instance variable of my own class, sorry if that wasn't clear in my post. But I would need to see more of the code to have a really good idea what "clean" is relative to it, without going against your style.

One world, one people

Maybe the 'simplify' method would work.

use Data::Dumper;
use XML::Twig;

my $file = $ARGV[0] || 'file.xml';

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

my $config = $twig->parsefile( $file )->simplify(
    # keyattr    => 'key',
    # group_tags => { columns => 'column', },
);

print Dumper( $config );
[download]

First you can have a look at the simplify, which is compatible with XML::Simple's XMLin, that might help.

Then if simplify is not what you are looking for, the "official" way to pass parameters to a handler is to use a closure. I am not sure why you deem this to be "not very elegant". It is a widely used technique, described for example in Achieving Closure (nearly 9 years ago!).

The code would look like this:

   my $data; # a ref to the data structure
   XML::Twig->new( twig_handlers => { foo => sub { foo( @_, $data); })
            ->parsefile( 'my.xml');

  sub foo
    { my( $twig, $foo, $data)= @_;
      # update the data referenced by $data
    }
[download]

It is even a FAQ: I want to pass additional arguments to XML::Twig handlers, not just the twig and the element, and I'd rather not use global variables. Can I do this?. I will add a paragraph about it in the main docs of the module though.

mirod,
I love closures. See How A Function Becomes Higher Order, and Understanding And Using Iterators for examples ;-)

I believe I did a poor job of explaining my goal and my hangup. I am processing a log with millions of XML messages. Each message must be converted to a distinct perl data structure. While I can see several ways of accomplishing this, none of them seem to let me have my cake and eat it too.

To use a closure in the way you describe, I would need a factory to create a brand new closure for each message and either instantiate a new instance of XML::Twig for each message or call $twig->setTwigHandlers() in between each call to $twig->parse(). The alternative would be to leave the XML::Twig object alone and perform a deep copy and "reset" of reference that was closed over in between each message.

My comprimise - which I am fine with, was to write my own dispatch table where I could do something akin to:

# ...
my $twig = XML::Twig->new();
while (<$fh>) {
    chomp;
    my $msg = {};
    $twig->parse($_);
    for my $child ($twig->root->children) {
        my $handler = $child->tag;
        if ($dispatch{$handler}) {
            $dispatch{$handler}->($child, $msg);
        }
        else {
            die "Haven't written handler for '$handler' yet";
        }
    }
    # do something with $msg
}
[download]

I asked for advice here to make sure I wasn't missing anything obvious. I will certainly check out simplify.

Cheers - L~R

Show me a few example messages and the desired datastructure and let's see how it goes with XML::Rules ... and whether you like the resulting code. This really looks like a perfect task for that module.

Jenda
Enoch was right!
Enjoy the last years of Rome.

My bad, I did not notice who had asked the original question. If I had paid attention I would have assumed you knew what a closure was!

I still don't understand very well what your problem is though. Is it that each message is a different XML "document"? In this case the ever helpful FAQ has something to say about it: Q22: I need to process XML documents. The problem is that they are several of them, so the parser dies after the first one, with a message telling me that there is junk after the end of the document. Is there any way I could trick the parser into believing they are all part of a single document?. If that's not the problem, then either post an example of the data, an an example of what it is you do with the data you generate for each message... or live happily ever after with the solution you have ;--)