[.NET] XML bron voor WinForms control

[tomato]

Ik heb een XML bron, waaruit ik gegevens wil tonen op een form. Zoals ik het wil tonen gaat het om een aantal records, elk met een aantal velden in zoiets als een datagrid.

Het liefst zou ik de XML transformeren en dan direct doorgeven aan een component dat de data vervolgens weergeeft. Ik heb namelijk niet zo'n zin de XML te ontleden en vervolgens zelf een control met de gegevens te vullen. Er moet toch een manier zijn om een control direct XML te voeren waarna rows en columns vanzelf gevuld worden?

Op dit moment transformeer ik de XML naar een tekstuele tabel (ASCII art ja ) en gooi dat direct in een grote textbox. Maar daar kun je er verder natuurlijk niet zoveel mee, hoogstens leuk om in de console de dataflow te kunnen monitoren

Oja, ik doe dit met C#, maar dat hoeft niet echt relevant te zijn lijkt me.

(Zoals je ziet stopt mijn ervaring met Windows GUI's ergens bij VB4 )

[edit] Even bijzeggen dat ik mij al een x aantal uur rotzoek in de .NET Framework Class Library

[mbravenboer]

Hum, voor zover ik weet (maar heb niet veel met WinForms gewerkt) is hier geen standaard voorziening voor. Waarom tranformeer je hem niet naar een table vorm (table, row, cell etc) waarna je dat inleest? Kan aardig generiek en vrij eenvoudig denk ik....

[mbravenboer]

Wat je trouwens ook kan doen: bekijk even de XML serialisatie van een 2d array van Strings en transformeer daarnaar . Dan ben je waarschijnlijk helemaal snel klaar.

[tomato]

mbravenboer: Waarom tranformeer je hem niet naar een table vorm (table, row, cell etc) waarna je dat inleest? Kan aardig generiek en vrij eenvoudig denk ik....

Ja, als ik goed begrijp wat je bedoelt is dat ook wel wat ik hierna van plan was.

Ik heb nog wel even doorgezocht en gevonden dat je een ADO Dataset kunt vullen met XML. Ik weet niet zeker in welk formaat, maar desnoods lees ik eerst een gevulde Dataset in XML uit en kijk ik hoe het eruit ziet.
Wanneer ik de Dataset gevuld heb met de juiste XML (die ik natuurlijk vrij gemakkelijk middels een transformatie kan genereren uit de source XML) wat wel moet lukken, hoop ik dat het ook niet moeilijk moet zijn om een Winforms control te vullen met de Dataset...

[edit] Of lijkt je zo'n dataset overkill als ik een eenvoudige tabel wil weergeven (wijzigen door de gebruiker is niet aan de orde)?

[mbravenboer]

tomato: [table-xml]Ja, als ik goed begrijp wat je bedoelt is dat ook wel wat ik hierna van plan was.

Ik zou voor jouw geval nog even serieus de XML serializatie overwegen. Dat werkt erg makkelijk . Als je hem naar het goede formaat kunt omzetten (vrij simpel) ben je erg snel klaar .

Of lijkt je zo'n dataset overkill als ik een eenvoudige tabel wil weergeven (wijzigen door de gebruiker is niet aan de orde)?

Als je weet hoe het allemaal precies moet werkt het vast wel goed, maar het lijkt mij een vrij complexe oplossing, zeker als je niet wilt editen (dan wordt het natuurlijk een heel ander verhaal).

[tomato]

mbravenboer: Ik zou voor jouw geval nog even serieus de XML serializatie overwegen. Dat werkt erg makkelijk . Als je hem naar het goede formaat kunt omzetten (vrij simpel) ben je erg snel klaar .

Ik weet niet of ik dit de mooiste oplossing vindt, maar het zal inderdaad wel vrij gemakkelijk (en efficient) zijn. Ik denk dat ik dit maar eens ga proberen vanavond.

Als je weet hoe het allemaal precies moet werkt het vast wel goed, maar het lijkt mij een vrij complexe oplossing, zeker als je niet wilt editen (dan wordt het natuurlijk een heel ander verhaal).

Precies, ik denk dan ook dat ik het hier maar niet ga zoeken. Daarnaast zit ik waarschijnlijk vrij vast aan een datagrid oid wanneer ik dergelijke constructies ga gebruiken. Die serializatie is wat dat betreft een stuk vrijer.

[mbravenboer]

tomato: Ik weet niet of ik dit de mooiste oplossing vindt, maar het zal inderdaad wel vrij gemakkelijk (en efficient) zijn.

Dat is juist een hele mooie oplossing . Het formaat van de XML serializatie is het formaat waarmee je data-structuren uit C# kan representeren in XML. Door de XML naar dit formaat te transformeren, transformeer je dus in feite naar een C# data-structuur. Mij lijkt dat een prachtig oplossing .

[tomato]

mbravenboer: Dat is juist een hele mooie oplossing . Het formaat van de XML serializatie is het formaat waarmee je data-structuren uit C# kan representeren in XML. Door de XML naar dit formaat te transformeren, transformeer je dus in feite naar een C# data-structuur. Mij lijkt dat een prachtig oplossing .

Ik heb stiekem al eventjes rondgeneusd in de XmlSerializer class en het ziet er erg krachtig uit! Ik denk dat het op deze manier niet echt een probleem meer zal worden. Naar het zogenaamd geserializeerde object transformeren zal in ieder geval erg gemakkelijk gaan.
Tegenover het serializen van objecten stond ik eigenlijk altijd nogal huiverig, maar op deze manier is er eigenlijk niets mis mee.

Bedankt voor de tip

[edit] En op deze manier hoef ik mee ook niet direct zo erg bezig te houden met het echte presenteren van de data (visueel), dat zal nu vanzelf wel goed komen.

[mbravenboer]

tomato: Tegenover het serializen van objecten stond ik eigenlijk altijd nogal huiverig, maar op deze manier is er eigenlijk niets mis mee.

Ik ben er ook niet erg dol op (behalve voor speciale gevallen, is pas al te spraken gekomen).

Maar dit biedt wel aardige mogelijkheden. Je kunt nu in feite direct XML content naar runtime-objecten transformeren .

Bedankt voor de tip

Graag gedaan . Ik kwam op het idee omdat Java deze mogelijkheid ook sinds kort heeft. Java heeft sinds 1.4.0 ook XML serializatie van Java Beans. Nu is het inlezen van XML altijd een probleem. Er zijn voor Java al een hoop mogelijkheden (zie: [topic=324232/1/25] ) maar deze Java Beans XML oplossing is nog nooit echt behandeld als een goede oplossing. Ik zie daar echter wel goede mogelijkheden in .

En op deze manier hoef ik mee ook niet direct zo erg bezig te houden met het echte presenteren van de data (visueel), dat zal nu vanzelf wel goed komen.

Inderdaad, als je echte domain-objecten zou gebruiken, zou je zelfs heel goed gelijk deze objecten in kunnen lezen. Die string[][] is natuurlijk nog een beetje aan ranzige oplossing die erg gericht is op de tabel... Het zal waarschijnlijk wel het makkelijkst zijn .

[tomato]

mbravenboer: Maar dit biedt wel aardige mogelijkheden. Je kunt nu in feite direct XML content naar runtime-objecten transformeren .

Precies, en dat maakt het erg bruikbaar en krachtig.

Ik kwam op het idee omdat Java deze mogelijkheid ook sinds kort heeft.

Uiteraard

Inderdaad, als je echte domain-objecten zou gebruiken, zou je zelfs heel goed gelijk deze objecten in kunnen lezen. Die string[][] is natuurlijk nog een beetje aan ranzige oplossing die erg gericht is op de tabel... Het zal waarschijnlijk wel het makkelijkst zijn .

Voorlopig voldoet dit. Domain-objecten zullen de volgende stap kunnen worden, hoewel het idee van serializeren hetzelfde zal blijven.

[tomato]

Wat wel een nadeel is van het transformeren naar een geserializeerd object, is dat je met je transformatie vast zit aan een object. Wanneer ik in plaats van een string[][] een ander datatype wil gebruiken zal ik mijn transformatie ook aan moeten passen.

[mbravenboer]

tomato: Wat wel een nadeel is van het transformeren naar een geserializeerd object, is dat je met je transformatie vast zit aan een object. Wanneer ik in plaats van een string[][] een ander datatype wil gebruiken zal ik mijn transformatie ook aan moeten passen.

Yep, maar dat heb je toch bij alle oplossingen?

Je kunt kiezen: (1) transformeren in XSLT naar XML serializatie of (2) transformeren in de code zelf: XML -> Objecten. Eventueel kan je bij (2) nog een generieke tussen-representatie invoeren: table-XML (3).

Als je een andere data-type wilt in je applicatie zal je bij oplossingen (1) je XSLT transformatie moeten aanpassen. Bij oplossing (2) moet je je transformatie in (niet declaratieve) code aanpassen of nieuwe schrijven. Bij (3) heb je eigenlijk helemaal een probleem .

[tomato]

Ja, daar heb je wel gelijk in. Het is zowiezo natuurlijk verstandig om een soort wrapper voor je datatype te maken die het object vult. Welke weg je ook kiest, bij een ander datatype zul je je wrapper aan moeten passen.
Bij (1) zal dit het aanpassen van je XSL zijn, bij (2) het aanpassen van code, evenals bij (3). Ik vroeg mij af wat je liever zou vermijden, maar ik krijg het idee dat dat vrij triviaal wordt.

[mbravenboer]

tomato: Welke weg je ook kiest, bij een ander datatype zul je je wrapper aan moeten passen.

Exact . Ik denk dat het daarbij het makkelijkst is als de wrapper declaratieve (en compacte) code is en dat is in XSLT bij uitstek het geval...

Ik begin de oplossing steeds leuker te vinden . Ik moet het ook maar eens in Java gaan toepassen....

[tomato]

mbravenboer: Ik begin de oplossing steeds leuker te vinden . Ik moet het ook maar eens in Java gaan toepassen....

Ik zal nog wel laten weten wat er van gekomen is bij mij (hoewel het eigenlijk wat gespeel is in mijn vrije tijd die ik toch al te weinig heb dus misschien duurt het even ).

Morgen je linkjes waarmee je net zo mooi dat topic omhoogschopte eens lezen, nu eerst maar eens slapen

[Yannick]

Misschien dat ik de boot een beetje gemist heb maar waarom doe je niet gewoon:

code:

objDataSet.ReadXML("xmlbestand.xml");

en dan databinden naar een grid control?

[tomato]

Yannick: Misschien dat ik de boot een beetje gemist heb maar waarom doe je niet gewoon:

code:

objDataSet.ReadXML("xmlbestand.xml");

en dan databinden naar een grid control?

Zoals je had kunnen lezen heb ik dat idee ook gehad. Maar ik ben bang dat ik op die manier vast zit aan het grid control. Daarnaast kan ik mij voorstellen dat een ADO DataSet in combinatie met een DataGrid voor de nodige overhead zorgt. Transformeren van de XML zou namelijk nog steeds nodig zijn, anders kan de DataSet deze niet lezen.

[Yannick]

oh dat bedoelde je. Maar wat heeft ADO met een Dataset te maken?

Bovendien geloof ik dat een dataset in memory ook is opgebouwd uit een XML bestand. Verder is een dataset behoorlijk flexibel. Datsets bestaan nl. uit 1 of meerdere datatables en die kun je als het moet cel voor cel aanspreken/wijzigen.

Ook denk ik (wild vermoeden) dat een dataset relatief efficient is omdat ze niet iets in .NET gaan inbakken dat bij voorbaat al minder efficient is dan zelf je dataaccess component schrijven.

[tomato]

Yannick: oh dat bedoelde je. Maar wat heeft ADO met een Dataset te maken?

Uit de docs: The DataSet is an in-memory cache of data retrieved from a database, is a major component of the ADO.NET architecture.

Bovendien geloof ik dat een dataset in memory ook is opgebouwd uit een XML bestand.

Uit de docs: The DataSet stores data using the set of .NET Framework types.
En ik geloof niet dat ieder datatype uit het .NET Framework intern als XML haar waarde opslaat eigenlijk...

Verder is een dataset behoorlijk flexibel. Datsets bestaan nl. uit 1 of meerdere datatables en die kun je als het moet cel voor cel aanspreken/wijzigen.

Dat is waar, er zijn enorm veel mogelijkheden met een DataSet, waarvan sommigen ook heel handig zouden zijn voor mijn 'probleem'.

Ook denk ik (wild vermoeden) dat een dataset relatief efficient is omdat ze niet iets in .NET gaan inbakken dat bij voorbaat al minder efficient is dan zelf je dataaccess component schrijven.

Ik heb het idee dat het voor mij een beetje overkill zou zijn. Misschien zit een DataSet heel efficient in elkaar, maar er zit enorm veel functionaliteit in die ik helemaal niet nodig heb (denk aan databinding, dataadapters). Dat zou het voor mij wellicht inefficient maken...

Maar wellicht dat ik toch beide manieren nog ga proberen (of zal ik even niets daarover roepen tot ik er ook daadwerkelijk mee aan de slag ga, het wisselt nu ieder uur )

[mbravenboer]

Sorry dat ik deze een enorme schop geef. Ik was eigenlijk wel benieuwd hoe het afgelopen was met tomato z'n avontuur .

Ik wilde het eerst in dit topic vragen ( [topic=353615/1/25] ), maar hier leek het mij beter op z'n plaats voor onze lieve, toekomstige search-gebruikers .
Dus: hoe is het afgelopen?

[tomato]

mbravenboer: Sorry dat ik deze een enorme schop geef. Ik was eigenlijk wel benieuwd hoe het afgelopen was met tomato z'n avontuur .

Op dit moment is het avontuur hier:

Een forum dat bij ons in ontwikkeling was bood XML data aan, dus ik vond dat wel een leuk speeltje om mezelf in .NET te introduceren

Zoals je kunt zien heb ik hier een grid-control en ik heb het toen toch opgelost met een ADO Dataset (irritant als mensen hardnekkig weigeren op je aanraders in te gaan he ).

Simpel gezegd draait het eigenlijk alleen hier om:

code:

xsltTransformer.Load (readerStyleSheet);

XmlReader readerTrackerData = xsltTransformer.Transform (xPathTrackerDoc, null);

DataSet dataSetUpdateTracker = new DataSet ("UpdateTracker");

dataSetUpdateTracker.ReadXml (readerTrackerData);

gridTrackerContent.SetDataBinding(dataSetUpdateTracker, "Post");

Enorm eenvoudig dus
Eigenlijk heb ik helemaal nog geen tijd gehad er verder iets mee te doen, maar ik was eigenlijk wel van plan ook de serializatie nog te proberen. Komt er vast ooit nog van.

Dus eigenlijk: _sorry

voor onze lieve, toekomstige search-gebruikers .

Loose the 'toekomstige' dude, alle search-gebruikers zijn immers toekomstig, dat is zo langzamerhand toch wel duidelijk?

[mbravenboer]

tomato: Een forum dat bij ons in ontwikkeling was bood XML data aan, dus ik vond dat wel een leuk speeltje om mezelf in .NET te introduceren

Hum, inderdaad leuk idee .

Zoals je kunt zien heb ik hier een grid-control en ik heb het toen toch opgelost met een ADO Dataset (irritant als mensen hardnekkig weigeren op je aanraders in te gaan he ).

Grrrrrrr . Ik word zo moe van al die mensen die m'n uitstekende adviezen negeren en eigenwijs hun eigen gang gaan .

maar ik was eigenlijk wel van plan ook de serializatie nog te proberen. Komt er vast ooit nog van.

Ik was wel benieuwd hoe het bevallen was (als je het had gedaan ). Ik heb het plan om voor www.javahova.net een serie artikelen over de toepassing van XML in Java te schrijven. Om een beetje origineel te zijn, wilde ik deze aanpak ook bespreken...

Loose the 'toekomstige' dude, alle search-gebruikers zijn immers toekomstig, dat is zo langzamerhand toch wel duidelijk?

Och, wat een frustraties .

[tomato]

mbravenboer: Ik was wel benieuwd hoe het bevallen was (als je het had gedaan ). Ik heb het plan om voor www.javahova.net een serie artikelen over de toepassing van XML in Java te schrijven. Om een beetje origineel te zijn, wilde ik deze aanpak ook bespreken...

Als ik nog eens zoiets doe (al dan niet in deze vorm) zal ik je het wel laten weten of er nog haken en ogen aan zaten

[mbravenboer]

tomato: Als ik nog eens zoiets doe (al dan niet in deze vorm) zal ik je het wel laten weten of er nog haken en ogen aan zaten

Mooi .