Jeg skrev for et stykke tid siden en række poster med den fælles overskrift Træer (Se her). I een af disse poste, lavede jeg et eksempel, hvor jeg brugte de nye hierakiske kontroller i ASP.NET til at vise en hierakisk Xml-struktur. I den forbindelse er der flere der har efterspurgt en forklaring/forslag til hvordan man kan danne en Xml-repræsentation af en filstruktur. Altså hvor rodelementet er en vilkårlig mappe, og underelementerne repræsenterer filer og mapper. Xml strukturen kan f.eks bruges til en Explorer agtig webside med oversigt over filer på en host.

Opgven er faktisk lige til, da vi jo har en XmlWriter klasse, som kan bruges til at generere det hierakiske output, og som sikre at Xml'en bliver formateret/struktureret korekt. Man kan ikke instatntierer en XmlWriter med en konstruktør (new), da det er en abstrakt klasse. I .NET 2.0 kan man dog danne en instans af XmlWriter klasse via den statiske metode Create, som har 10 overloads der tage forskellige typer. Her i blandt også en streng, som repræsenterer et filnavn - i nedenstående eksempel, har jeg dog brugt den overload der tage en Stream. Så er det så dejligt nemt at se hvad der sker i en konsol-applikation.

Når XmlWriteren er instantieret, er det blot at starte fra toppen af strukturen, og danne sit rodelement (her root), og så bare forsætte i en rekursiv metode, ind til alle underelementer er blevet renderet.

Læg mærke til at den rekursive metode tager både et DirectoryInfo- og et XmlWriterobjekt. På den måde indlejres alle filer og undermapper fint i hinnanden...

1using System.IO;
2using System.Text;
3using System.Xml;
4
5namespace ConsoleApplication1
6{
7 class Program
8 {
9 static void Main(string[] args)
10 {
11    #region XmlSettings
12    XmlWriterSettings settings = new XmlWriterSettings();
13    settings.Indent = true;
14    settings.NewLineHandling = NewLineHandling.Entitize;
15    settings.NewLineOnAttributes = true;
16    settings.Encoding = Encoding.UTF8;
17    #endregion
18    DirectoryInfo dir = Directory.GetParent("../../");
19    XmlWriter w = XmlWriter.Create(Console.Out, settings);
20 
21    w.WriteStartDocument();
22    w.WriteStartElement("root");
23    w.WriteAttributeString("name", Path.GetFileName(dir.FullName));
24       WriteSubElements(dir, w);
25    w.WriteEndElement();// root
26    w.Close();
27
28    Console.Read();
29 }
30
31 private static void WriteSubElements(DirectoryInfo dirInfo, XmlWriter w)
32 {
33    // Først alle undermapper
34    foreach (DirectoryInfo dir in dirInfo.GetDirectories())
35    {
36       w.WriteStartElement("dir");
37       w.WriteAttributeString("name", Path.GetFileName(dir.FullName));
38       w.WriteAttributeString("changed", dir.LastWriteTime.ToString("s"));
39       // Og rekursivt...
40       WriteSubElements(dir, w);
41       w.WriteEndElement(); //dir
42    }
43    // Så alle filer
44    foreach (FileInfo fi in dirInfo.GetFiles())
45    {
46       w.WriteStartElement("file");
47       w.WriteAttributeString("name", Path.GetFileName(fi.FullName));
48       w.WriteAttributeString("changed", fi.CreationTime.ToString("s"));
49       w.WriteEndElement();//file
50    }
51 }
52 }
53}

Som det fremgår, så er det ret simpelt, når blot man lige holder styr på sine start- og end-elementer.

Code on...

Technorati : Xml

Her kommer den foreløbigt sidste post i min lille serie om træstrukturer (index).

Nu er vi bevæbnet til tænderne med metoder til generering af træstrukturer i XML, og vi har netop downloadet beta 2 af VS.NET 2005. Skulle vi så ikke tage et kik på et par af de nye kontroller, som er blevet introduceret til os med ASP.NET 2.0, og se om ikke kan fremstille nogle flotte træstrukturer.

Start med at lave et nyt websted (eller forsæt på et eksisterende), og tilføj en ny webform. På formen slæber du en af de nye datakontroller ind: XmlDataSource-kontrollen. Den har en række egenskaber, men vi vil nøjes med at bruge den der hedder DataFile. Den angiver stien til Xml-filen der indeholder vores træstruktur fra tidligere (i mit web bliver det: "~/Trees/TreeData.xml"). Så slæber vi en webkontrol mere ind på siden: TreeView. I designeren fremkommer der et lille mærke (smarttag), som man kan aktiverer, og få adgang til en række vigtige vizards på den enkelte kontrol.

På TreeView er der flere punkter, men den vigtigste er angivelsen af datakilden, som er repræsenteret ved punktet Choose Data Source. Ud for punktet er der en dropdownliste, som bl.a. indeholder vores XmlDataSource - den vælges. Her efter går vi videre til at skulle redigerer bindingen af vores datakilde til TreeView-delene. Det gøres via Smarttag-punktet Edit TreeNode Databindings....

I den fremkomne vizard er der bl.a. et vindue med et treeview af Xml-dokumentet der genereres af datakilden. Marker een af employee-noderne, og klik på add. Noden vil da fremkomme på listen Selected data bindings, og man kan angive værdier for de enkelte grene i træet. Vi skal her sætte egenskaben TextField og ValueField til henholdsvis Name og ID. Læg mærke til at designeren selv foreslår værdierne fra XmlDataSourcen...nice. Nu skal vi så bare lige havde tilføjet noget sukker til vores layout, og det gøres nemt med Smarttag-punktet Autoformat - her vælger jeg formatet Contacts, da det giver et Messenger look, som egner sig fint til vores organisationstræ. Voilla mere skal der ikke til, og vi har et fuldt funktionelt treeview med vores personhierarki.

Men hov - alle personerne ligger på samme niveau. Vi har glemt een ting - vi skulle transformerer Xml-data for at få hierarkiet. Det gøres nemt via Xslt som vi har set tidligere, og vi kan bare angive stien på vores Xslt i XmlDataSource egenskaben TransformFile (i mit tilfælde vil det være "~/Trees/Tree.xsl").

Læg i øvrigt mærke til i XmlDatasource konfigurationen, at man kan angive et XPath udtryk, hvis man kun ønsker at bruge et delelement af datakilden. Nu er de rigtigt indlejrede under hinanden som de skal, og det ser sådan ud:.

For lige at runde af og opsummerer hvad der skal til for at vise en træstruktur i ASP.NET 2.0.

1. Lav et udtræk af data som indeholder parentid'er
2. Brug det som datakilde for XmlDataSource kontrollen
3. Tilføj den rekursive Xslt der danner hierarkiet
4. Placer en TreeView kontrol på formen, og angiv XmlDataSource kontrollen som datakilde
5. Lav binding til Xml attributterne der indeholder navn og id

Læg mærke til at alt sker i designeren, og alt angives deklarativt i Aspx-filen - der skrives ikke een linie kode i code-behind. Det kalder jeg abstraheret udvikling.

Code on (eller skulle man sige 'Drag'n drop on')

I min blog, for et stykke tid siden, kom jeg til at skrive "...og det kan selvfølgelig også gøres i ADO.NET, selvom der ikke er dynamiske cursorer her" (I posten Træer II). Jeg forklarede om hvordan man genererede træer i ADO før ADO.NET, og der er venlige mennesker der har gjort mig opmærksom på at man kan gøre det samme i ADO.NET ved at bruge en foreach på Rows kollektionen uden dynamisk cursor (skriv endelig jeres forslag her på loggen, for så er der flere der får noget ud af det). Ja - det er rigtigt at man kan lave en rekursiv funktion der nester ind i Rows kollektionen, men hvis man er ude efter at danne en hirakisk XML struktur, er der en langt lettere måde. Nemlig ved at udnytte muligheden for at bruge relationer i et DataSet, og på den måde få ADO.NET til at lave alt det beskidte arbejde for os.

For eksemplets skyld tager vi det samme data, som jeg har brugt i tidligere indlæg:

Det er rimeligt trivielt at indlæse data i et DataSet, og jeg skal holde mig til kode der ikke er provider afhængig - kun klasser fra System.Data. Det kan altså bruges med al data... også Tamino ;-)

Det første vi skal gøre er at frembringe relationen - ParentChild:

Og outputtet/resultatet:

Lige klar til XSLT eller som datakilde til en TreeView.
Ja - andet skal der ikke til i ADO.NET for at lave en hirakisk XML struktur - DataRelation.Nested er din ven.
Code on...

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??? ;-)

Arbejder man med data, som på den ene eller anden måde skal gemmes som en træstruktur, har man principielt 3 mulige fremgangsmåder:

1. Nested Sets
2. Materialized Path
3. Adjacency List.

Så kan det godt være at der findes flere eller kombinationer, mendet er min overbevisning at der blot er tale om varianter af ovenstående 3 metoder (i gør mig opmærksom på det, hvis jeg tager fejl).

Nested Sets som Joe Celko definerer dem, er nok den smukkeste model, og den har en lang række fordele i forhold til opslag i SQL data. Det er direkte muligt at udvælge en hel gren i een forespørgsel, finde stien til roden og såvidere (læs evt artiklen). Den eneste hage ved modellen, er at den er ret besværlig at indsætte nye grene - det kan i teorien være nødvendigt at opdaterer alle poster i et træ, bare for at indsætte een ny gren. Altså en god løsning til mere statisk data, men i praksis ubrugelig i mere dynamisk data, som f.eks. håndtering af forumtråde eller nyhedsgrupper. Det er ikke sjovt at skulle opdaterer alle poster i AD forum hver gang men opretter en ny post.

Materialized Path er nok den metode, som man først udtænker, når man bliver stillet over for opgaven at skulle gemme hirakisk data i SQL. Her har man en primærnøgle af typen vchar, som ud over at være nøgle også bærer information om postens placering i træstrukturen - f.eks.: '1.1.1.2'. Fordelen er at det er nemt at se på selve posten, hvor den befinder sig i hirakiet. Ulemperne opstår, når der skal slettes grene. Så skal der rekalkuleres og opdateres en lang række poster - dog virker træstrukturen i modsætning til føromtalte nestede sets stadig ved sletning, der er bare ikke længere orden i sagerne. Desuden er der en øvre grænse for antallet af niveauer som tabellen kan holde, da den skrevne sti bliver gemt i et textfelt, og da men ikke gør klogt i at gemme stien i et blob-felt pga. manglende index.

Adjacency List erden sidste, og nok også den mest brugte. Her består hirakieat af to kolonner: Id og ParentID (Name og BossName). Roden i hirakiet er så den post der ikke ar en værdi for ParentID. Her er et banalt eksempel på et organisationsdiagram.

ID BossID Name
==============================
1 null Jesper
2 1 Brian
3 1 Per
4 2 Ulla
5 2 Pia

Heraf fremgår det at Brians chef hedder Jesper, og at han har to under sig; Ulla og Pia. Modellen har en stor fordel i forbindelse med indsættelse - man opretter blot en post med en given ParentID, og med det samme er posten indplaceret i hirakiet. Ved sletning, er man nød til at opdaterer alle poster der er direkte underordnede den slettede post, men det er en forholdsvis nem opgave. Problemerne opstår, når man vil lave en forespørgsel på en hel gren - 'Brian og alle under ham', eller når man ønsker at udvælge en hel kommandovej - 'Ullas vej til toppen'.

Selv hælder jeg mest til Adjacency List- metoden, og det er f.eks. også den model der ligger til grund for AD forum, som indeholder mere end 65000 indlæg. Det havde været umuligt i nogen af de andre modeller. Prøv at forestille dig at oprette et nyt indlæg via Materialized Path-modellen: '1.23.54982.54987.65100' - hvilken størelse skal man sætte på feltet, og hvordan performer det med op imod 100000 poster.

Check min blog ud senere, så vil jeg forklarer hvordan man kan udvidde Adjacency List modellen med XML cache, som speeder udvælgelsen gevaldigt op, og gennemgå hvordan man kan bruge CTE i Yukon til noget af den samme funktionalitet.

(Er der i øvrgt nogen der har links til nogle gode eks. på CTE og hirakier, så smid lige en post).