Oleg Tkachenko har nu frigivet nxslt 2.0, som er et commandline værktøj til udførsel af Xsl transformeringer. Værktøjet er skrevet i Microsoft .NET Framework 2.0 og udnytter den nye super effektive System.Xml.Xsl.XslCompiledTransform. Nu ved jeg godt at VS.NET 2005 leveres med en hidtil uovertruffen Xsl editor med mulighed for debug o.s.v., men der er tilfælde hvor dette værktøj har sin berettigelse. Har du f.eks. en applikaton, som producerer Xml filer på en server, så kan du nemt lave en Schedule, som tager denne Xml-fil og transformerer den med en Xsl, for til sidst at uploade resultatet som en Html-fil til en webserver.

Er det ikke skønt at kunne sige: "værsgo her er e-handelsstatistikken vist på virksomhedens intranet!", til salgschefen?

Ja det er jo kun fantasien der sætter grænsen, og det bedste af det hele: Oleg har frigivet nxsl2 på Open source under BSD license

Hent den her: Link

Så stødte jeg ind i een af de der irriterende fejl med et Xslt som transformerer et Xml-datasæt til en Javascript array (du kender det nok...):

Det går fint - lige ind til der er en bruger som begynder at putte apostrof ind i @name. Så får vi fejl med uafsluttede strenge Javascript. Der findes ikke en Replace funktion i Xsl, så vi må hen og være mere kreative. Jeg besluttede mig for at bruge funktionen translate, som foruden strengen, også tager to parametre. Den første er den karakter som der skal søges efter, og den anden er den karakter, som der skal oversættes med (hvis disse parametre kun indeholder een karakter, er det det samme som en replace funktionalitet. Jeg prøvede først med følgende:

Hvilket gav uheldige Xsl-parserfejl, da ' bliver tolket som en almindelig apostrof, og så er det jo pludselig Xsl'en som har uafsluttede strenge. Og min parameter nr 2: \' vil heller ikke virke, da translate kun kan erstatte een karakter med een karakter. Løsningen indbærer et lille kompromis. Ser man på karakteren apostrof (') og acute accent (´), så kan man se at de minder meget om hinnanden rent grafisk, og mit kompromis går ud på at jeg sagtens kan leve med acute i stedet for apostrof ;-). Det løser kun halvdelen af problemet. Problemet med uafsluttede strenge, kan løses ved at bytte rundt på dobbelt anførselstegn og apostrof. Det kan sagtens lade sig gøre, da begge dele er velformet Xml. Jeg ender så op med følgende Xslt:

Så lykkedes det at få mine apostrof indeholdende strenge over i Javascript. Kan man ikke leve med acute i stedet for apostrof, kan man så lave en Javascript replace efterfølgende, men det er en helt anden historie.

Hvad er en Url? Ja, spørgsmålet lyder nok lidt banalt, men det er ikke desto mindre relevant. En kollega, som lige er begyndt at eksperimenterer med Xsl og Xml, ringede mig op, og var i vildrede over hvordan man skulle udfører en 'simpel' transformering af Xml data til Html.

Han var rigtigt nok begyndt at kikke på XslTransform objektet, men var så kommet i tvivl om hvilken af de mange overloads til Load metoden man skulle bruge (ja - der er 11 overloads). Han var nået frem til at det var den som tog een streng som parameter, som var den mest simple. Dog synes han det var en streg i regningen, at denne parameter var en angivet som en Url, og at man på den måde var nød til at hoste Xsl-filen på en web-server. Jeg har selv brugt denne metode-overload 100 gange, og havde ærligt talt ikke hæftet mig specielt ved beskrivelsen af parameteren som Url.

Jeg blev selv i tvivl, og overvejede hvad en XslTransform egentlig udfører, og hvad den måtte havde brug for for at kunne det. Det er selvfølgelig ikke kun et filnavn, men også en lokation af dette filnavn, som objektet skal bruge. Specielt når der skal løses link til eksterne ressourcer i Xsl'en. Men hvis man nu ikke skal bruge alt det 'fancy hejs', og kun skal bruge Xsl'en som template for noget data, og man bare vil havde filerne liggende i C:/temp? Hvad skal man så med en Url?

Her kommer vi så til pointen i dette indlæg: Hvad er en Url?

Uniform Resource Locator - er hvad forkortelsen står for. Altså en Entydig ressource lokation. Vi er så vandt til forkortelsen, og vi sætter automatisk en Url op i adresse-feltet i Internet Explorer med et Http:// foran. Http:// er dog ikke et nødvendigt element i en Url - det kan lige så godt være ftp:// eller File://. Det er jo bare angivelsen af protokollen, som skal bruges for at man kan hente den angivne fil på den angivne lokation. En Url hænger derfor ikke uløseligt sammen med en web-server, og den kan sagtens henvise til filsystemet.

Bruger man Lutz Roeders .NET Reflector på XslTransform.Load, kan man se at den bruger en XmlTextReader internt til at indlæse den angivne Xsl, som igen bruger en XmlResolver til at 'afkode' Url'en.

Hvis man blot ønsker at transformerer data, kan man gøre det på følgende simple måde:

Vil man hellere foretage transformeringen i RAM, kan man gøre følgende:

Altså - Url er en lokation.

Jeg har i dag fulgt en tråd på ActiveDeveloper.dk, hvor ossi 05 spørger til hvordan man laver paging i Xsl. Det undre mig lidt at der ikke er noget der har beskrevet dette scenarie tidligere (Google gav intet brugbart, og der er absolut intet på topXML.com!!!). Derfor laver jeg lige denne lille post om emnet.

Jeg tager udgangspunkt i noget Xml-data som frembringes ved en eksport af Produkter-tabellen i Northwind.mdb. Data ser således ud:

For at foretage paging, skal vi havde et par oplysninger: Hvilken side er vi på (CurrentPage)? Hvor mange poster er der i alt (Count)? Hvor mange poster er der på hver side (PageSize)? Disse oplysninger skal vi bruge, for at kunne begrænse udlæsningen, og for at kunne udlæse lige netop de poster som ønskes. Count og PageSize er egentlige konstanter for hele pagineringen, og CurrentPage er variablen der ændres fra side til side. Desuden har vi behov for et entydigt indeks, for at kunne finde frem til hvor i vores data vi er, og til det bruger jeg XPath-funktionen position(), som altid returnerer hvilken position den aktuelle node har i det aktuelle node-set. Med det på plads, kan jeg altså opsætte følgende filter udtryk:

Bemærk at man er nød til at trække een fra CurrentPage, da ikke position() returnerer et 0-baseret indeks. Jeg skal så bare indføje filtret i mit xsl:apply-templates element.

Det begrænser outputtet til kun at indeholde poster fra den ønskede side.

For at danne traditionelle navigations-links kan man bruge en rekursiv funktion. Funktion skal bare kaldes med oplysninger om totalt antal sider og aktuel side, og herefter gentage sig selv til grænsen er nået. Du kan downloade den komplette Xsl fil her: Paging0.xsl

Sådan, nu kan vi page i Xsl, og sådan ser det ud i vores nye Xsl-debugger i Visual Studio 2005 - den er bare så fed...

Som tidligere nævnt, så kommer System.Xml 2.0 med en helt ny XslTransform klasse, XslCompiledTransform. Noget af det jeg har hæftet mig ved, ud over at den er hylende hurtig, er at den er blevet langt mere simpel at bruge. Ja der er lige de nævnte ting, omkring document-funktionen og script-blokke, men ser man bort fra det, så er der tale om et langt simplere api. Prøv for eks. at sammenlign den centrale metode, Transform: XslTransform's metode har hele 18 overloads, hvor XslCompiledTransform kun har 14. Reduceringen af antallet af metode-overloads, skyldes dels at man ikke længere har en overload som returnerer en XmlReader, dels at XPathNavigator nu implementerer IXPathNavigable interfacet. Hvorfor har man ikke tænkt på det noget før?

Nu er input til Transform metoden altså reduceret til: String, XmlReader, eller IXPathNavigable - nice!

Jeg sidder for tiden og bøvler med en ASP 3.0 applikation, som skal havde tilføjet lidt funktionalitet. I den forbindelse laver jeg en del transformeringer af ADO RecordSet objekter. Jeg gør det ved at kalde Save metoden på RecordSet, og tilføje et XmlDocument som parameter - alt sammen meget let. Hvis du kender lidt til den xml der skrives ved brug af denne metode, så ved du også at den i princippet fræser alle rækker ud i hvert sit element, z:row, med en attribut for hver kolonne i posten. Jeg havde så brug for at min output, havde et element for hver attribut. Hvordan er det så lige man udvælger alle attributter som et node-set? Jeg har gjort det før, men kan ikke huske syntaksen, og det fremgår ikke klart af mine Xslt referencer.

Lidt asen og masen, og så kom jeg frem til følgende XPath udtryk:

Simpelt? Ja, men for mig er syntaksen ulogisk, og jeg er nød til at oprette denne post, så ved jeg hvordan næste gang jeg glemmer det...

I beta 2 releasen af .NET 2.0, er XslTransform klassen blevet markeret som obsolete - dvs. den virker, men der bliver ikke optimeret mere på den, og det anbefales at man undlader at bruge den.. Lidt kedeligt, når man nu har været glad for den klasse, og brugt den i vid udstrækning. Man skal dog ikke græde alt for meget, for der er kommet en afløser, som må siges at være XslTransform på speed - nemlig XslCompiledTransform. Den indeholder en lang række forbedringer, men den vigtiste er at den kompilerer Xslt'en ned i et mellemformat (lidt som CLR for C# og VB.NET), som så bliver cached og genbrugt. Klassen er desuden optimeret og meget hurtigere runtime.

Hvor store ændringer skal man så udfører for at lave sin 1.x kode om til at spille under 2.0? Ikke ret meget vil jeg mene. Lad os tage et standar eksempel, hvor vi transformerer en Xml-kilde, og returnerer den til en stream (f.eks. i en HttpHandler) i 1.1 kompatibel kode:

Bliver til:

Ikke den helt store ændring i forhold til 1.1. Som jeg ser det, er det mest besværlige, hvis man har Xslt'er der indeholder scripting, eller som bruger document() funktionen, for den nye klasse har nemlig deaktiveret disse to som default, og man er nød til at fodre et XsltSettings objekt med i Load metoden for at aktiverer dem:

Det skulle måske genovervejes hvor ofte man tillader scripting i sin applikation. Er der tale om en ASP.NET applikation hvor man lader brugeren få adgang til sine Xslt-filer, jo i sin koncekvens er muligt at eksekverer c# kode på serveren.... Jeg har slet ikke tænkt på det tidligere, men det er da oplagt for enhver hacker ikke?

Code on...

Når der tales om gruppering af data i Xslt, er den mest udbredte og effektive metode, at bruge XPath-funktionen generate-id() sammen med et xsl:key index (læs min artikel om nøgler her). Metoden kaldes også: Muench's metode efter metodens udvikler Steve Muench.

Metoden går i sin enkelthed ud på, at man udnytter key funktionens retur kollektion, som kun indeholder een node (den første forekomst i DOM'en) af noder der matcher nøglen. Har vi f.eks. et Xml dokument med følgende struktur:

• Produkter
  • Produkt
    • VareGruppe
    • VareNr
    • VareNavn

og ønsker en udlæsning af data, der laver en sektion for hver varegruppe. Ja så er metoden nem og hurtig i forhold til loops i DataSet eller rekursive kald. Man starter med at lave sin nøgle, som skal beskrive det index der sorteres på - her VareGruppe:

Vores gennemløb skal så tage udgangspunkt i produktgrupperne med følgende XPath forespørgsel i rod-context:

/Produkter/Produkt[generate-id(.)=generate-id(key('varegruppe',@VareGruppe))]

Husk at XPath-funktionen generate-id returnerer en unik id i det aktuelle dokument. Hvert element i DOM'en kan altså indekseres ud fra denne id...smart. Ovenstående forespørgsel siger altså: "Alle produkter der har en unik-id der matcher nøglen's id (varegruppe key elementet). I praksis vil denne forespørgsel returnerer en kollektion af noder der har forskellige VareGruppe attributter. Efterfølgende kan man så lave en indre forespørgsel, der tager udgangspunkt i Varegruppe.

<xsl:apply-templates select="key('varegruppe',@VareGruppe)" />

Jeg håber alle er med endnu, for det er her man kan styre sit output, da man selvfølgelig kan tilsætte xsl:sort elementer for at finjusterer outputtet 100%. Her følger det Xslt som kæder ovenstående sammen.

<?xml version="1.0" encoding="utf-8" ?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <!-- Vores Varegruppe indeks --> <xsl:key name="varegruppe" match="/Produkter/Produkt" use="@VareGruppe" /> <xsl:template match="/"> <xsl:for-each select="/Produkter/Produkt[generate-id(.)=generate-id(key('varegruppe',@VareGruppe))]"> <!-- Udskriv varegruppen --> <table> <caption><xsl:value-of select="@VareGruppe" /></caption> <!-- Så vælger vi alle Produkter med varegruppen via vores key --> <xsl:apply-templates select="key('varegruppe',@VareGruppe)" /> </table> </xsl:for-each> </xsl:template> <xsl:template match="Produkt"> <tr> <td><xsl:value-of select="@VareNr"/></td> <td><xsl:value-of select="@VareNavn"/></td> </tr> </xsl:template> </xsl:stylesheet>

Det var det hele - sådan sorterer man med Steve Muench's metode. Får du den først ind på rygraden, vil du aldrig slippe den igen.....

Her finder du en række eks. på gruppering med metoden - her

Som jeg nævnte i min blog for et par uger siden, vil jeg prøve at give et par tricks til håndtering af træstrukturer i XML. Jeg vil som nævnt tage udgangspunkt i træstrukturer der gemmes i en relationel database, som har mulighed for at oprette tabeller med selvreferencer - Adjacency List modellen. Een af modelllens svage punkter er den manglende mulighed for udvælgelsen af en green i træstrukturen. Man kan godt udvælge en gren og dens umiddelbare undergrene, men så stopper det også, for man vil så skulle foretage en sub-select for at finde yderligere børne-børn, og så videre - ikke særligt skalerbart. En måde at løse problemet på er ved at lave en XML cache med data fra tabellen, og transformerer det til hirakisk data via XSLT. Lad os tage datasættet fra tidligere:

Udvalgt fra databasen via følgende query:

I gamle dage (ASP 2+3), udlæste jeg selv data fra sådanne forespørgsler via dynamiske cursorer i ADO og rekursive funktioner, som kunne iterere gennem en hel træstruktur. Det kan være en krævende omgang for databasen, hvis der f.eks. er tale om en Access fil på et meget besøgt websted - script-timeout!! Det kan gøres meget lettere, og det kan selvfølgelig også gøres i ADO.NET, selvom der ikke er dynamiske cursorer her. Nemlig med XSLT. Det er faktisk ret lige til, når data er valid (altså ingen ring-referencer med nogen der er boss for en ansats boss), og kommer ud på ovenstående form. Det første man skal gøre i sin XSL er at sammensætte en forespørgsel XPath Query, som returnerer rodelementet - i ovenstående data: Jesper. I modellen er værdien af BossID nullable, og sættes til null på den øverste boss. Bruger man den indbyggede funktion: boolean(val), validerer en null-værdi til false, og man skal så bare inverterer.

Når man så har den node, er det blot et spørgsmål om at lave et rekursivt kald til en template.:

Hvilket f.eks. kunne se således ud:

Læg mærke til $id variabel - det gør jeg for ikke at få navne sammenfald i den rekursive XPath query.

Ville slet ikke gå, dat det ville søge den node som havde enslydende attributværdi for BossID og ID - derfor erklæringen af variablen. Når ovenstående transformering udføres, fremkommer følgende XML:

<?xml version="1.0"?> <staff> <emplyee id="1" name="Jesper"> <emplyee id="2" name="Brian"> <emplyee id="4" name="Ulla"></emplyee> <emplyee id="5" name="Pia"></emplyee> </emplyee> <emplyee id="3" name="Per"></emplyee> </emplyee> </staff>

Hirakisk data (BossID er hermed overflødig ;-) ), som vi nemt kan lave forespørgsler ned i og få returneret hele under-elementer. Man kan evt. lave en funktion der opdaterer en ASP.NET cache med xml-strukturen, og på den måde lave sine søgninger ned i XMLDOM'en via XPath queryes. Søgningen mod toppen fra en given gren - breadcrumbs - er ligeledes let via resultatdokumentet, eller en transformering, som jeg beskrev i en artikl tidligere.

Hvordan findes Ullas boss via XPath??? ;-)

En kollega kom forbi med et lille XML søge problem. Hun havde en (enorm) XML fil, som skulle gennemsøges for forekomsten af en streng. Selve XML'en så således ud:

Hendes fremgangsmåde gik ud på at læse hver node een for een, og checke med en RegularExpression (applikationen havde XMLDom'en i hukommelsen i forvejen). Fremgangsmåden var god nok, men spørgsmålet var om det kunne gøres mere effektivt. Jo, når XML'en nu er i hukommelsen som et XmlDocument, så er det jo nærliggende at transformerer sig ud af problemet. Man kan bruge den indbyggede XSL-funktion contains( str1, str2 ), som tager to strenge, og returnerer true, hvis den ene er indeholdt i den anden. På den måde kunne man opsætte et XPath udtryk, som foretager søgningen:

Den vil returnerer et nodeset med alle Key-elementer, som indeholder teksten 'søgestreng'. Fordelen er selvfølgelig at man direkte kan formaterer sit søgeresultat:

<?xml version="1.0" encoding="UTF-8" ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:param name="QUERY"/> <!-- $QUERY indeholder søgestrengen --> <xsl:template match="/"> <xsl:apply-templates select="/Data/Key[contains(.,$QUERY)]" mode="Result"/> </xsl:template> <xsl:template match="Key" mode="Result"> <li><xsl:value-of select="@name"/></li> </xsl:template> </xsl:stylesheet>

Ovenstående vil i dette tilfælde lave en LI-liste med navnene på de Key-elementer der indeholder $QUERY

Wrooom - det speedede processen op. Vær opmærksom på at ovenstående kun er en god ide, hvis XML'en er i hukommelsen i forvejen, ellers vil det være langt mere effektivt at bruge een af de hurtige 'Fire-hose'-readers, som f.eks. XmlReader.