An XSLT version of an old favourite
-
Within one of my company's XSLT document's, I came across the following. Seems to be an XSLT version of a familiar coding horror...
<xsl:for-each select="fl:values/fl:dataItem[@field='fl_name']> <xsl:if test="position()=1"> _Output Here_ </xsl:if> </xsl:for-each> -
Within one of my company's XSLT document's, I came across the following. Seems to be an XSLT version of a familiar coding horror...
<xsl:for-each select="fl:values/fl:dataItem[@field='fl_name']> <xsl:if test="position()=1"> _Output Here_ </xsl:if> </xsl:for-each>From time to time it is necessary for me to code xslt. Each time is a horror. the horror the horror
-
From time to time it is necessary for me to code xslt. Each time is a horror. the horror the horror
Personally, I'm torn. I do like the declarative nature of specifying transforms on XML documents. However, two problems remain: 1. XML. Fine for structured data passing between systems. I use it regularly for these purposes. However, as a programming language, I'd say it leaves something to be desired. I'm a C-family developer (C++, Java, C#) and appreciate the terseness, so XSLT makes me shudder with its verbosity. 2. As with many scripting languages, if used well code is fairly readable, but put it in the hands of a less capable developer, and the source is virtually unreadable. Obviously what we need is an XSLT transform to transform badly written XSLT into well-written XSLT ;), and a transform to render (and the reverse) XSLT to more user- (i.e. developer) friendly syntax.
-
From time to time it is necessary for me to code xslt. Each time is a horror. the horror the horror
Doc Lobster wrote:
From time to time it is necessary for me to code xslt. Each time is a horror.
Eh, not so sure about that. Sure, the syntax is horrible, but the semantics make sense IMHO.
-
From time to time it is necessary for me to code xslt. Each time is a horror. the horror the horror
-
Personally, I'm torn. I do like the declarative nature of specifying transforms on XML documents. However, two problems remain: 1. XML. Fine for structured data passing between systems. I use it regularly for these purposes. However, as a programming language, I'd say it leaves something to be desired. I'm a C-family developer (C++, Java, C#) and appreciate the terseness, so XSLT makes me shudder with its verbosity. 2. As with many scripting languages, if used well code is fairly readable, but put it in the hands of a less capable developer, and the source is virtually unreadable. Obviously what we need is an XSLT transform to transform badly written XSLT into well-written XSLT ;), and a transform to render (and the reverse) XSLT to more user- (i.e. developer) friendly syntax.
Well, I don't create XSLTs on a daily basis, only once a month. Each time I have to go back to look at already created ones to see how to do it. It just doesn't seem natural to me, especially dealing with variables and parameters. When I look at XSLTs in bigger projects that have been worked on for a while (by other people) - it makes XSL to look like a self-obfuscating language. People tend to put the whole application into one file (doesn't matter if it got 10.000 lines), do not properly group things, use copy & paste and the rest is done by the overhead of tags and symbols through XML. It makes me think XSL is generally treated as throw-away code, like prototypes going into production.
-
From time to time, it is necessary for me to review procedural XML translation code from people who don't know how to use XSLT. Each time is a horror... ;)
But who is the king of all of these folks?
Spot on - I'm having just such a horror going through current use in my project. I think though that many developer's expect just to leap into XSLT as with most languages, without observing that it requires a paradigm shift from imperative to declarative logic. Still hate the syntax though. XML is just way to verbose for some applications. I've heard justifications that a tree-like structure is well suited to such tasks, but as far I'm aware most parsers form a tree (Abstract Syntax Tree) representing the program structure, so that doesn't cut ice with me.
-
Well, I don't create XSLTs on a daily basis, only once a month. Each time I have to go back to look at already created ones to see how to do it. It just doesn't seem natural to me, especially dealing with variables and parameters. When I look at XSLTs in bigger projects that have been worked on for a while (by other people) - it makes XSL to look like a self-obfuscating language. People tend to put the whole application into one file (doesn't matter if it got 10.000 lines), do not properly group things, use copy & paste and the rest is done by the overhead of tags and symbols through XML. It makes me think XSL is generally treated as throw-away code, like prototypes going into production.
Doc Lobster wrote:
People tend to put the whole application into one file (doesn't matter if it got 10.000 lines), do not properly group things, use copy & paste and the rest is done by the overhead of tags and symbols through XML.
Ouch. Well, slap 'em around a bit. There's just no excuse for that.