"Quick and dirty" often turns to "slow and messy". For example, compare the two "test" scripts in this thread. ;)

Using XML::TreeBuilder was "Quick and dirty". A XML::Twig solution is likely to be more appropriate for a scalable solution. Consider:

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

my $dataCount = 0;
my $str = do {local $/; <DATA>};
my $t= XML::Twig->new (twig_roots => {data => \&data});

$t->parse ($str);


sub data {
    my ($t, $data) = @_;
    
    ++$dataCount;
    print "Data node $dataCount\n";
    
    my @strings = $data->descendants ('string');
    
    print "   ", $_->trimmed_text (), "\n" for @strings;
}


__DATA__
[download]

using the same data as the previous sample orints:

Data node 1
   1 some stuff
   1 some more stuff
   1 yet more stuff
   1 enough stuff
Data node 2
   2 some stuff
   2 some more stuff
   2 yet more stuff
   2 enough stuff
Data node 3
   3 some stuff
   3 some more stuff
   3 yet more stuff
   3 enough stuff
[download]

Note that both samples cheat by wrapping a root element around the data elements to form a more compliant XML document.

Absolutely no debate there, quick-n-dirty is generally not a good way to go. In this case its a project I outlined about a year-and-a-half ago and then had to shelf due to other assignments. Now my boss is telling me he wants it up and running yesterday (nevermind he hasn't actually given me any time to do it). MY own estimation to do the project "right" is a couple of months. He wanted it in three days (by "it" he means something useful he can give to another group that does monitoring, who has nothing at all now). The "real" answer, when I am permitted more time to work on it properly, is to define a well-balanced set of objects, bind them to xml-ish config files and thus make something beautiful and easily reconfigured. It really grates on me doing all this "hard-coding". I hate it. I already have some of the important parts built though, and they're already reasonably configurable. And I'm working from a pretty well fleshed-out concept document that I did awhile back, so I have a pretty-good roadmap to follow. I just wish my boss understood that writing programs takes time. You can't just assign me a program on Monday, tell me its due on Friday, and then suck up all my time on other, unrelated projects all week and then expect it to magically pop out on the other end... (sigh) What can ya do?? :)

I think that part of GrandFather's point is that you would be getting more of the application done in less time if you used appropriate modules wherever possible, instead of doing things from scratch.

A bunch of the code you need may already be written, and you may be able to find it on CPAN faster than you can write it yourself (and some CPAN author will have already put in a lot more time than you can possibly spend in solving a particular part of your task).

(update: Then again, depending on how well a given module is documented, or what it tries to accomplish in addition to the task that you need it for, learning to use it correctly might raise issues in some cases. The (inappropriately named?) XML::Simple module comes to mind... excellent module, really, but the manual is massive, and getting it to do something "just so" for a particular data set might take a while. Grain of salt, anyone?)