[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: <quote>XSL is NOT easy</quote>

Subject: Re: <quote>XSL is NOT easy</quote>
From: "Karl Stubsjoen" <kstubs@xxxxxxxxx>
Date: Tue, 26 Jun 2007 07:33:57 -0700
Re:  <quote>XSL is NOT easy</quote>
Also, Karl, what version of XSLT  are you using? I think XSLT 1.0 can
get confusing if you require recursion and you are not used to
functional programming.

Currently, using XSLT 1.0, but interested in 2.0, just have not taken the step. I guess the hang up is that we are on the .NET platform, so no native support for XSLT 2.0. In my home projects, I am transforming xml/xslt with the Mvp XML assemblies (Mvp.Xml.dll), thanks to M. David Peterson for setting me up with this (showing me where to find it).

Oh, and recursion isn't too bad, the simple ones... I've witnessed
(borrowed and tweaked) some recursion templates which are seriously
"magical", thanks:  Carlisle, Kay, novatchev (and others).

On 6/26/07, Kamal Bhatt <kbhatt@xxxxxxxxx> wrote:
bryan rasmussen wrote:
> actually I find that most of the really bad code is written by
> programmers.
>
> classical sins:
> 1. overuse of for-each. The worst ever: match on the root then do a
> for each on the document element!! followed by a for-each of every
> child of the document element, for-each of each of those etc. it was
> for-each all the way down. Matching of attributes using for-each,
> comparison of two attributes was done using for-each  down all
> attributes until attribute with the name of the to be matched
> attribute, save the value of that attribute into a variable, do a
> for-each of parent::*/@* until the attribute to be compared with was
> found then doing two ifs for if the value matches and if the value
> does not match.
>
> I submit that this was the most depraved and perfectly developed
> example of a for-each fetish ever discovered in the history of XSL-T.
>
>
> 2.  I once worked with a computer science graduate/programmer, he
> didn't just know mainstream languages but also Standard ML and Scheme.
> He had been writiing XSL-T for more than a year, and his code was
> littered with stuff like
> <xsl:if test="count(record) &gt; 0"><xsl:apply-templates
> select="record"/></xsl:if>
>
>
Another sin that I committed when I first started is the abuse of
call-template, ie assuming some XML coming into a call template. That is
just confusing.

I will add that XSLTs become more complex when the XML coming into them
are poorly structured. If you have properly structured XML, XSLTs seem
to flow and are simple, but if there is too little structure (or too
much) then XSLTs and XPath becomes very difficult.

Also, Karl, what version of XSLT  are you using? I think XSLT 1.0 can
get confusing if you require recursion and you are not used to
functional programming.

As for XSLT being hard to learn, it took me less than a week to get my
head around XSLT and I am not exactly a gifted programmer. Our web
designer (note, not programmer) can do simple XSLT work without too much
difficulty and doesn't have too much trouble maintaining XSLTs.

--
Kamal Bhatt

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.