[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] xsl:key in a function?


Subject: Re: [xsl] xsl:key in a function?
From: "Imsieke, Gerrit, le-tex" <gerrit.imsieke@xxxxxxxxx>
Date: Tue, 06 Mar 2012 00:24:32 +0100

On 2012-03-05 23:32, Andrew Welch wrote:
On 5 March 2012 21:56, ihe onwuka<ihe.onwuka@xxxxxxxxxxxxxx> wrote:
On Mon, Mar 5, 2012 at 8:15 PM, Andrew Welch<andrew.j.welch@xxxxxxxxx> wrote:
Well I know the solution - keys, read the file once and stick it in a
variable, however this is not an option because they don't want to let
me tweak the generated code.

Write a stylesheet that imports the generated code and override the relevant part.


Can't for 2 reasons.


1. They want all the code to be generated.

2. The generated code doesn't use template rules, all the iterations
are done with xsl:for-each

...and for that reason, I'm out.


:)

I wasnt in yet, but Im out, too.


Wrong life cannot be lived rightly.

Next year, I promise, youll see a brand new Adorno quotation, because apparently I used this one before:
http://markmail.org/search/?q=wrong%20life%20rightly%20gerrit#query:wrong%20life%20rightly%20gerrit+page:1+mid:vmyo2mz7kzxmat3f+state:results


Its not that Im against generating code. Generating XSLT code (particularly: generating matching patterns) can give you lots of flexibility without the need to sacrifice performance.

But generated for-each instructions is a different game, its plain wrong life in most cases, wronger than poor XQuerys typeswitch statement. Because we can do better.

One of the worst pieces of XSLT code that Ive ever seen was some xsl:for-each ejaculate that came straight off of an Altova StyleVision file. Maybe it was maintainable with StyleVision, which I dont use. But fixing the generated XSLT code seemed to be so much more effort than re-creating more reasonable transformations from scratch, and thats what we did.

Redesigning their generator code may prove to be worth the while.

Gerrit


Current Thread
Keywords