XM-Hell

Chady has asked for the wisdom of the Perl Monks concerning the following question:

Hi! I have this website on my hands, and I decided to have it done like that:

one perl file to handle all the requests
one XML file taht contains all the data as follows:

<PAGE level="1" name="about" title="About Us">
 textextext xtextxe
 may contain <b>HTML</b>
</PAGE>
<PAGE .....
[download]

so I started thinking about XML Parsers.. and I'm totally lost.

I really like the get_tag function in HTML::TokeParser

what's my best bet for an XML Parser module... I'm lost with all the XML modules around...

The reason behind this structure is to enable me to make the links section change quickly in the site.. I add a page in the XML file, and it will have its link placed in the correct pages according to some attributes...

He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

Chady | http://chady.net/

Comment on XM-Hell Select or Download Code

Replies are listed 'Best First'.
Re: XM-Hell by mirod (Canon) on Dec 14, 2001 at 17:26 UTC
In this case XML::Simple will not work, as your XML includes mixed content (text with tags inside, such as `<p>foo <b>bar</b> baz</p>`). To make sense of the various XML modules you can have a look at Kip Hampton's excellent column on xml.com, look at my old Processing XML with Perl article or start hanging out on the perl-xml mailing list. The recent trend in XML processing with Perl is to move away from XML::Parser based modules and to use more modules based libXML 2, the GNOME XML library. That said a lot of the "good ole" XML modules would work just fine in your case: XML::Parser of course, but also XML::Twig (of course!), probably XML::PYX, as suggested by Davorg XML::XPath would work too, and XML::DOM would work too (if you decide to use it you might want to check out XML::DOM::Twig). BTW the reason XML::Parser is sortta frowned upon these days is that it has a non-standard interface (newer modules use standard SAX or DOM interfaces, XML::Parser predates both). Those interfaces are sounder and more common, which means that for example you can read CSV data and process it with XML tools if you use a CSV parser with a SAX output such as Illya Strin's XML::SAXDriver::CSV . Last but not least Matt Sergeant would kill me if I failed to mention his new XML::SAX::PurePerl, which is, surprisingly, a SAX parser written in pure Perl, which means you don't have to install external libraries such as expat or libXML 2, which can be a pain on some systems.	[reply] [d/l]
Re: XM-Hell by davorg (Chancellor) on Dec 14, 2001 at 14:55 UTC
The closest thing to HTML::TokeParser is probably XML::XPath. -- <http://www.dave.org.uk> "The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg	[reply]
Re: XM-Hell by vek (Prior) on Dec 14, 2001 at 20:24 UTC
You'll find the perl-xml mailing list to be an invaluable help - I know I have. Personally I like Matts XML::SAX::PurePerl. However, if speed is of importance (and you don't mention that it is) then XML::SAX::PurePerl (because of the very fact that it's written entirely in perl) is not the fastest kid on the block - albeit a nice module. Even though it has fallen out of the limelight, XML::Parser is stll pretty speedy because of expat (C prog). One of my co-workers wrote a quick benchmark suite that compared the many XML modules and XML::Parser came up on top for speed - again second hand info so your mileage may vary...	[reply]
Re: XM-Hell by hakkr (Chaplain) on Dec 14, 2001 at 16:00 UTC
XML::Simple is well pretty simple. I've been told XML::TreeBuilder has good functionality. CGI::XMLApplication might give you a good basis for your application seeing as your using XML for it's stylesheeting abilities	[reply]