|We don't bite newbies here... much|
Re^2: RFC: XML::Pastor v0.52 is released - A REVOLUTIONARY way to deal with XMLby aulusoy (Scribe)
|on Jun 29, 2008 at 21:59 UTC||Need Help??|
Yes, I agree that a comparison chart would be useful. However, it will take some time to gather the information in an exhaustive way.
I will try to be brief and to the point here at this time. But I will try to post a more comprehensive comparison chart sometime soon.
XML::Twig is obviosuly an excellent module. The main difference with XML::Pastor is that, while working with XML::Twig, the code needs to know about the 'xml'ness of the data, whereas, while working with XML::Pastor, the program needs to know -almost- nothing about the xmlness of the data. For the user code, XML elements and attributes are just native Perl objects with accessors and/or regular hash and array access.
Another difference with XML::Twig is the ability to validate against the original W3C Schema in XML::Pastor, and this without needing the schema at run time. By the way, schema validation at run time is stunningly fast, because there is no schema parsing necessary.
In many respects, XML::Pastor goes much with the philosophy of XML::Simple, with one important difference: XML::Pastor has full round-trip binding with XML. This means you can read and write XML with those native Perl objects. With XML::Simple you could do that, but if you have tried anything other than the most trivial, you know you really can't. Really, XML::Simple is useful for reading in a simple config file in xml maybe, but nothing more.
Another comparison with XML::Simple is that, XML::Simple produces one big deep data structure upon parser the XML file. In contrast, XML::Pastor will produce native Perl Objects for each element and attribute with names and methods (accessors and much more) that correspond to the actual data. Nothing stops the monk from coding additional methods for those objects (using the same package names that resulted from code generation), hence building logic around the native object.
Another drawback of XML::Simple is the multiplcity of child elements. In default mode XML::Simple will produce a hash for a single occurence of a given child node, but will produce an array of hashes if that node appears multiple times. This is very annoying. In another mode, it is possible to instruct XML::Simple to produce only arrays for child elements, but then the whole thing becomes quite convoluted. XML::Simple eleviates this problem by counting on the schema to produce the expected result. In reality, XML::Pastor will always prouduce a special kind of array for this situation => XML::Pastor::NodeArray , which has magical properties. If you access it like a hash or with a method call, it will pass it on to the first element. If you access it like an array, you can too. So, you never need to know.
Apart from some pending limitations, the two cons of XML::Pastor are: