51–60 of 157 posts
On XSLT: find something that fills its role completely, with the same level of tooling, and then have a rant about inferior tools being popular, until then it doesn't really matter if it sucks.
Okay, so what am I supposed to use if I want to transform a XML file from one format to another because two different systems needs XML for input /output and they have different fixed formats?
import xml.etree.ElementTree as ET
tree = ET.parse('data.xml')
new_tree = my_transform(tree)
new_tree.write("output.xml")Earlier quoted context omitted.
I want to enter this piece of evidence into the trial: Comma separated string parsing XSLT: http://stackoverflow.com/a/2850181/92493
If you are using XSLT to work on anything other than XML you are doing very strange things.
That's what I call USELESS
What article are we supposed to look at ? It is witty quotes and links, there in no substance is this article, just bashing. Is it supposed to be an answer to this article that had a lot of discussion on proggit ? http://www.reddit.com/r/programming/comments/2o5nvy/why_i_li...
If the alternative look like a (t/n)roff file, I'd gladly take XML, though.
Earlier quoted context omitted.
My definition of powerful and elegant is lisp XML is just death by overengineering
> My definition of powerful and elegant is lisp Dude, XML is just s-exprs and XSLT is macros.
When programming in XSLT it is great to fire up a debugger (let's say oXygen), run your transformation, click on the wrong output and being able to go step-by-step backwards.
How many languages designed before 1999 (yeah, XSLT is 15 years old) can claim to be able to do so?
I believe the fundamental pain of xslt was... that it was an FP language. When teaching XSLT, the difference between those who said "its elegant" vs. those who said "its pain" - is whether the individual could grok FP. Angle bracket overload, verbosity of end tags, library support, poor whitespace handling, namespace pain were all obstacles too but it was FP that made standard problems feel like math proofs and for d…
It's more of a declarative language. Like Prolog.
Earlier quoted context omitted.
My definition of powerful and elegant is lisp XML is just death by overengineering
apples and oranges? There is no other way of encoding structured documents these days than XML. Like it or not, XML is the de facto standard for data exchange (export from databases, product information software,....) XML might be overengeneered (which, except for a few things I don't agree with), but there is currently no alternative for it.
Okay, so what am I supposed to use if I want to transform a XML file from one format to another because two different systems needs XML for input /output and they have different fixed formats?
I would use a language that has a decent XML parser (e.g. python + lxml) for input and a decent templating language (e.g. jinja2) for output. Assuming it was a simple transformation, the python parsing code could be under 10 lines. Most of what you wrote would be templating. It would be 98% declarative. If it got complicated though (e.g. you're doing some aggregation or something), the python bit would grow but it pr…
var result = new XSLTProcessor().importStylesheet(xsl).transform(....);
JSON/Javascript is just easier to learn and work with than XML/XSLT. For starters, you don't need to learn a special language that you'll never use for anything else. Just in case you /do/ need to use XML every day: the primary benefit of XSLT is that it lets you avoid using XML libraries to munge some XML. Because the XML libraries are so horrendous to use from any language.
Unfortuntely running Javascript on the back-end for this purpose is not something most companies do.