Re^2: XML::LibXML - WHAR HASH TREES WHAR?!

Yes, gmpassos is M.I.A., this means you can take over maintenance/development of XML::Smart -- you can also fork the codebase at any time.

That's not my point, and something I don't have the time for right now. XML::Smart is mostly dead and XML::LibXML is now the currently maintained XML module. My point is that with all of the development and talk about how great this module is, why hasn't there been some efforts to make it more elegant and "sugary"?

Actually, no, it really isn't. It is quite comprehensive and complete; in any case, as they say, patches welcome

A typical RTFM-like response, hmm?

And again, the docs are spread all over creation. Quick, tell me how to create a XML tree of nodes. Well, that's going to diving into 4-5 different module docs to look up the appendChild, setText, etc. methods. Not to mention that there are about 10 different ways to create these things and there is no tutorial saying "Okay, this is the RIGHT way to do it that uses the least code."

For that manner, can anybody tell me how XML::LibXML::SAX works? Because the documentation there doesn't give me any methods to use. Even the other sections, like this one, literally say "Usage is as above", which means "I'm too lazy to actually list out the methods for this module." Meanwhile, XML::LibXML::SAX::Parser, the class that isn't "DEPRACED" has absolutely no documentation.

Actually, no it wasn't. jQuery was created because html/browsers did not expose xpath to javascript. XML::LibXML gives you xpath.

And did they implement XPath? No. They used the CSS selector language to grab nodes. Why? Because everybody was familiar with it and we don't need Yet Another Selector Language. Just stick with one and be done with it.

Any idiot can define a one char shortcut for document.getElementById

Yes, and when millions of "idiots" are defining one-char shortcuts for a function, there is something wrong with the function.

Eh?

Okay, that's just a list of random modules.

Comment on Re^2: XML::LibXML - WHAR HASH TREES WHAR?!

Replies are listed 'Best First'.
Re^3: XML::LibXML - WHAR HASH TREES WHAR?! by Anonymous Monk on Jul 16, 2011 at 03:35 UTC
That's not my point, and something I don't have the time for right now. XML::Smart is mostly dead and XML::LibXML is now the currently maintained XML module. If its not your point, why dwell on it? If you find it useful and convenient, why not keep it updated? Software only dies if you stop using it. My point is that with all of the development and talk about how great this module is, why hasn't there been some efforts to make it more elegant and "sugary"? Hmm, why does an interface to a standards based library not come with sugar? Perhaps, because diabetes is an epidemic? I don't know -- seems like too much work for one man A typical RTFM-like response, hmm? Is it? I found it quite civil in comparison to your post. I feel the same as Re: XML::LibXML - WHAR HASH TREES WHAR?! And again, the docs are spread all over creation. Why is that a problem? Perl documentation doesn't come all on one page either -- you could always make one page with all the docs :) Quick, tell me how to create a XML tree of nodes. Well, that's going to diving into 4-5 different module docs to look up the appendChild, setText, etc. methods. http://cpansearch.perl.org/src/SHLOMIF/XML-LibXML-1.80/t/04node.t Not to mention that there are about 10 different ways to create these things and there is no tutorial saying "Okay, this is the RIGHT way to do it that uses the least code." Interfacing to libxml is a big enough job -- the docs aren't there to teach you programming, oo concepts, patterns, paradigms (like event-based programming ), xml ... For that manner, can anybody tell me how XML::LibXML::SAX works? Because the documentation there doesn't give me any methods to use. Even the other sections, like this one, literally say "Usage is as above", which means "I'm too lazy to actually list out the methods for this module." Meanwhile, XML::LibXML::SAX::Parser, the class that isn't "DEPRACED" has absolutely no documentation. The docs say XML::LibXML provides an interface to libxml2 direct SAX interface The SAX interface of XML::LibXML is based on the famous XML::SAX interface. It uses the generic interface as provided by XML::SAX::Base. So XML::SAX, XML::SAX::Base, http://cpansearch.perl.org/src/SHLOMIF/XML-LibXML-1.80/t/14sax.t, SAX is the Simple API for XML, SAX Yes, and when millions of "idiots" are defining one-char shortcuts for a function, there is something wrong with the function. No there isn't. You still use `print` don't you? or `say`? You're not using `p` or `s` are you? Or in javascript terms, you're still using `$('a[href]').each(` aren't you? You're not using `$('a[href]').e(`? And did they implement XPath? No. They used the CSS selector language to grab nodes. `$('a[href$="pdf"]')` -- looks like xpath to me -- sure, its called "css2", but its xpath -- in anycase, xpath is the standard for xml	[reply] [d/l] [select]
Re^3: XML::LibXML - WHAR HASH TREES WHAR?! by SineSwiper (Beadle) on Jul 15, 2011 at 23:42 UTC
Okay, why did nobody mention XML::Compile? (Well, besides stuffing it in a list above.) It uses XML::LibXML directly. It's a mature and well-supported set of modules. It creates hash trees, and it uses those to create XML from schema files. Why isn't, like, 100% of the Perl community using this?	[reply]
Re^4: XML::LibXML - WHAR HASH TREES WHAR?! by Anonymous Monk on Jul 16, 2011 at 02:55 UTC
Why isn't, like, 100% of the Perl community using this? They're probably too busy being appaled by XML::Smart/XML::LibXML	[reply]