[xslt] Parameter arrays meegeven

[Dennis]

Hallo,

Ik werk aan een applicatie die binnenkomende opdrachten krijgt in XML formaat, deze verwerkt en vervolgens met behulp van XSL een HTML bestand maakt. Mijn verwerking geeft een aantal waarden retour, en deze stuur ik als XSLT parameters mee naar de XSLT compiler (XsltArgumentList in .NET).

Nou heb ik twee vaste variabelen die elke opdracht meekrijgt en deze leveren geen enkel probleem op. Maar elke opdracht bevat ook een X aantal objecten en die krijgen bij verwerking ook een waarde. Denk even aan de volgende structuur in de XML:

XML:

<objecten><object>...</object><object>...</object></objecten>

Omdat ik van tevoren niet weet hoeveel objecten er zijn, vind ik het slordig om maar 20 vaste parameters hiervoor te maken. Het liefst zou ik natuurlijk een soort array meegeven, maar of, en zoja hoe, dat kan is mij niet duidelijk. Op het internet wordt deze vraag vaker gesteld maar goede oplossingen staan er niet tussen. Er zijn wel wat custom implementaties, maar het liefst werk ik natuurlijk met standaardoplossingen.

Kan dit met een soort array worden opgelost en zo nee, hoe zou ik dit dan wel netjes kunnen oplossen?

[matthijsln]

Ik ken .NET niet, maar is dit niet wat je zoekt?

http://msdn.microsoft.com...t.addextensionobject.aspx

In het voorbeeld wordt een scalar gereturned, maar volgens de docs moet een nodeset ook kunnen.

edit: hiervoor moet je extension object methode een XPathNodeIterator returnen. Zie bijvoorbeeld http://www.tkachenko.com/blog/archives/000034.html

[ Voor 24% gewijzigd door matthijsln op 24-08-2009 16:19 ]

[Dennis]

matthijsln schreef op maandag 24 augustus 2009 @ 16:02:
Ik ken .NET niet, maar is dit niet wat je zoekt?

http://msdn.microsoft.com...t.addextensionobject.aspx

In het voorbeeld wordt een scalar gereturned, maar volgens de docs moet een nodeset ook kunnen.

Hmmm, de link die je hebt gestuurd ken ik niet en is niet echt de oplossing die ik zoek, maar zou wel een goed alternatief kunnen zijn! Het enige wat me nog tegenhoudt en een andere oplossing prefereert is dat dit waarschijnlijk een vrij specifieke .NET-oplossing is. Maar binnen dit model kan ik wel iets maken wat mijn probleem oplost, dus daarvoor bedankt .

edit: hiervoor moet je extension object methode een XPathNodeIterator returnen. Zie bijvoorbeeld http://www.tkachenko.com/blog/archives/000034.html

Hier staat dat het alleen voor .NET 1.0 geldt, en daar werk ik (en de meeste anderen) gelukkig niet meer mee, maar bedankt voor de aanvullende link.

[matthijsln]

Dennis schreef op maandag 24 augustus 2009 @ 16:56:
Hier staat dat het alleen voor .NET 1.0 geldt, en daar werk ik (en de meeste anderen) gelukkig niet meer mee, maar bedankt voor de aanvullende link.

edit...hier stond eerst onzin.:) Die interne XPathArrayIterator bestaat in nieuwere versies inderdaad niet, je kan of zelf de XPathNodeIterator interface implementeren of deze op een andere manier te pakken krijgen zoals in de voorbeelden.

[ Voor 39% gewijzigd door matthijsln op 24-08-2009 17:13 ]

[djc]

.NET zou hier een toepasselijker tag zijn dan XSLT.

[Verwijderd]

Dennis schreef op maandag 24 augustus 2009 @ 15:35:
Omdat ik van tevoren niet weet hoeveel objecten er zijn, vind ik het slordig om maar 20 vaste parameters hiervoor te maken. Het liefst zou ik natuurlijk een soort array meegeven, maar of, en zoja hoe, dat kan is mij niet duidelijk. Op het internet wordt deze vraag vaker gesteld maar goede oplossingen staan er niet tussen. Er zijn wel wat custom implementaties, maar het liefst werk ik natuurlijk met standaardoplossingen.

Kan dit met een soort array worden opgelost en zo nee, hoe zou ik dit dan wel netjes kunnen oplossen?

Misschien dat ik je probleem niet goed begrijp, maar op het moment dat je het antwoord terugstuurd weet je toch hoeveel objecten er gestuurd gaan worden? Je kunt dan toch middels een generieke aanpak die XML opbouwen?

Bijvoorbeeld in pseudo code:

C#:

xmlDoc.AddNode(EersteVasteVariabele);
xmlDoc.AddNode(TweedeVasteVariabele);

foreach (Object o in objectenVoorRequest)
  xmlDoc.AddNode(o);

[Niemand_Anders]

Wij hebben een ViewManager class welke welke via een overloaded method AddData(string name, ISupportXml obj) of zoals AddData(string name, IEnumerable<ISupportXml> collection) data toevoegt aan het XML document welke uiteindelijk aan de XSLT compiler wordt meegegeven.

De ISupportXml interface is erg simpel:

C#:

XElement ToXml();
object FromXml(XElement xmlNode);

De 'name' parameter welke aan AddData wordt meegegeven wordt alleen gebruikt voor het container element welke aan de root van de 'master' XML wordt gekoppeld. De werking is erg simpel:

C#:

IViewManager view = IocFactory.Get<IViewManager>();
view.AddData("Customer", cust);
view.AddData("LastRedraws", IocFactory.Get<ICustomerManager>().GetRedraws(5)); 
view.LoadStylesheet("Resources/Xsl/Customer/Redraws.xsl");

XDocument outputXml = view.Render();

De IocFactory die je voorbij ziet komen in onze IoC onafhankelijk adapter implementatie welke enigszins overeenkomst met de Microsoft CSL implementatie. AddData heeft nog meer overloaded methods, maar deze zijn in deze context verder niet interessant.

Omdat wij de conversie van en naar XML van de objecten bij de objecten zelf hebben gelegd is de ViewManager vrij simpel gebleven. Het enigste object welke bij via de XslArgumentList doorgeven is een algemen presentatie helper class welke het gemakkelijker maakt om datums en bedragen te tonen.

Het is eigenlijk ook vrij logisch dat wat jij wilt standaard niet bestaat. XSLT werkt met XML. That's it, dat is de reden. Wil je geen eigen ISupportXml interface gaan bouwen, dan kun je ook eventueel gebruiken van de SOAP serialization mogelijkheden. XML Serializatie heeft naam mijn mening er veel attributen nodig en gebruik ik persoonlijk dus nooit.

[Dennis]

Bedankt voor jullie antwoorden net nog. Ik zie ze nu, omdat ik vanochtend bezig ben geweest de oplossing van Matthijs te implementeren.

Ik moet zeggen, dat is wel appeltje-eitje. Ik zou nog wel de code van de oplossing willen plaatsen, maar die is eigenlijk exact gelijk aan het voorbeeld op msdn. Dat heeft dus niet zoveel toegevoegde waarde.

Ik denk overigens ook dat deze oplossing toch wel de simpelste is. Daarnaast blijft de scheiding van code, data en opmaak hiermee zoveel mogelijk gescheiden, doordat ik geen hele kant-en-klare xml hoef aan te maken in mijn C# code.

Nogmaals bedankt dus allemaal .