I just wrote some damned elegant XSL today. Feeling moderately chuffed about that.
Tag: XSL
DEFENSE
Thank [higher power] for defensively written XSLT. Epic poop storm narrowly averted.
Who needs string-replace()?
Why would XSL use a standard-ish way of naming their string replace function? No, they have to use translate($string,'a','b') for some reason knowable only to the damn committee that wrote the spec.
Thanks StackOverflow for the reminder. I’d be pretty pissed to have written my own string-replace() thing and then run across this at a later date.
Holy Tagmaster, Batman!
How long has it been since I’ve written CSS? Quite the stroll down memory lane today as I prettified some XSL transformed XML reports.
Relatedly, I’d forgotten just how short browser implementation has come on the promise of serving XML and letting the client render things prettily. I’m all for stopping XSS attacks but good lord, DQ’ing an XSL file just because it comes from a different port on the same machine? Heavens forfend!
To summarize:
- XSLT processing strategy: 79%
- XSLT processing implementation: 7%
- Beautification: 5%
- Blogging about it afterwards: 9%
Of course, I don’t have the generator tool work even started. I smell a flunked story on the horizon…