31–40 of 157 posts
Earlier quoted context omitted.
> My definition of powerful and elegant is lisp Dude, XML is just s-exprs and XSLT is macros.
REALLY? http://en.wikipedia.org/wiki/XSLT#Example_1_.28transforming_...
Comma separated string parsing XSLT: http://stackoverflow.com/a/2850181/92493
Our company once had an application that processed the end-of-year high school student results and then published them in various newspapers. The input files were text files generated from the Education Department's database from various regions. The process took around 10-15 minutes (lot's of rules had to be run against the data). I replaced it with a Windows JScript script and XSLT. It took 15 seconds to transform the data.
That said, I still use XSLT regularly but I'd be lying if I enjoyed working with it. Using a decent IDE for development and debugging can help.
Someone did give me a nice tip for working with and learning XLST though - "translate your transformation rules directly from simple English to the template rules".
eg. "I need to insert the node under "
XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don't understand it and that's why can't use it, should just do their home work and learn better
The problem is that it's often misused. Using an XSLT that takes 0.5s to run to transform some XML to HTML during web requests on a busy site? Idiotic. Using it for async transformations - html to pdf, customer message format to your message format. Fine.
1. parsed on server startup for setting up persistence, business rules, REST endpoints etc
2. transformed by XSLT to a) produce nice HTML documentation, including DOT class diagrams b) generate Java source code c) validate declaration integrity and cross-referencing
With the right XSDs, IDE support is excellent (auto complete for everything). Take the time to learn it, apply it according to your needs, and reap the benefits- in the long run, maintenance work is down by an order of magnitude.
Those who rant about XML and XSLT know nothing about what they talk about. 50% of our server's behavior (200,000 Java LOCs) is orchestrated declaratively by a small number of XML files that use around 30 custom namespaces. These are 1. parsed on server startup for setting up persistence, business rules, REST endpoints etc 2. transformed by XSLT to a) produce nice HTML documentation, including DOT class diagrams b) ge…
In fact, the latter point is one of the reasons most people like to avoid XML.
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…
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…
> 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. I've heard this before, but I don't find it to be true for me anyway. XSLT has never really clicked for me, while I really like Clojure and OCaml. Maybe the FP is part of the problem, but I also thin…