81–90 of 133 posts
Earlier quoted context omitted.
While SimpleXML gives you an easy way to walk the tree, it still requires you to actually do it. All 3 of those examples would require slightly different calls to SimpleXML to handle.
The moment I realized I could do json_decode(json_encode($simple_xml_object),true); to turn a complex SimpleXML object into an array was the happiest moment of my life.
LINQ to XML. Couldn't be easier!
Earlier quoted context omitted.
Reiterating the point the blog post makes, but: It's very very easy to structure the same data in different ways in XML. While JSON has the same issue, it's a lot harder to do and you have less flexibility in making bad storage decisions. You are absolutely right on walking the structure. JSON just tends to be easier (in my experience), even when working with XML libraries that make it less of a pain.
I'll give the opposing opinion that I find working with XML easier than JSON, but mostly because of QueryPath.
Earlier quoted context omitted.
Apparently one doesn't need to be awake, sane or sober to become an enterprise "programmer".
Apparently one doesn't need to be awake, sane or sober to become a "programmer". Fixed. I've seen plenty of crap programming everywhere, no need to pick on enterprise programmers.
The best way I've encountered to construct XML: first-name John last-name Smith I kid you not. That's what I'm dealing with at work right now. Thank you, enterprise SOAP solutions.
- Has been built by string manipulation and therefore isn't well formed and needs hacky preprocessing before being parsed (no not HTML)
- Is full of redundant information (e.g. count attributes giving the number of child elements)
- Makes evil use of vast numbers of namespaces where the element names are all the same
- Is a basically a container for delimited or fixed format data
- Had attributes that contained entire encoded XML documents
There are probably some other horrors that therapy and/or alchohol have let me forget (like systems doing SQL queries doing string compares on lumps of XML).
I really like JSON these days...
The best way I've encountered to construct XML: first-name John last-name Smith I kid you not. That's what I'm dealing with at work right now. Thank you, enterprise SOAP solutions.
I've worked with worse: John Smith 123 Some Street Blah Blah Blah ... and so on. I can't think of any advantage to (or excuse for) doing it this way. The only possible reason for it that I can think of, is rather comprehensive ignorance of how XML and related standards work.
The best way I've encountered to construct XML: first-name John last-name Smith I kid you not. That's what I'm dealing with at work right now. Thank you, enterprise SOAP solutions.
Are you really having to deal with the SOAP protocol yourself? I mean, their are libraries that handle all this for you. Just read in the WSDL, and call the methods as you need them. No need to muck around with XML.
98% of the time SOAP works without too many problems - the trouble is that those other 2% of cases can be truly awful to debug because you have then got to wade through all of the crap that is in there to support the "easy to use" functionality.
SOAP should die.
Map m = new HashMap(); m.put("a", 1); m.put("b", 2); m.put("c", 3); . . . The single worst thing in Java?
Both of these are a bit lighter yet still far away from JavaScript or Ruby special syntaxes.
The best way I've encountered to construct XML: first-name John last-name Smith I kid you not. That's what I'm dealing with at work right now. Thank you, enterprise SOAP solutions.
It gets so much worse that this. Much of the generated XML I've seen (especially the stuff used for SOAP) is nearly unreadable by humans.