[Java] starten met XML

[Alarmnummer]

op dit moment gebruik ik veel serialized objecten en ik wil nu over gaan op xml. Ik heb al wat dingen zitten inkijken en ik weet wat xml inhoud. Maar ik vraag me af hoe ik hier mee moet beginnen. Moet ik gebruik maken van Dom,JDom of Sax? En ik geloof dat er ook standaar api`s zijn om een bean tot xml om te zetten, wat kan ik hiervoor het beste gebruiken?

[mbravenboer]

Er zijn inderdaad een hoop mogelijkheden . Een overzichtje:

Allereerst heb je drie globale manieren om XML in te lezen vanuit Java:

1. Handmatig met SAX of DOM
2. XML serializatie van Java Beans
3. Java-XML Binding

Allereerst de handmatige manier met SAX of DOM:

Met de DOM methode levert de parser een object-structuur op in het geheugen. Hieruit kan je daarna gegevens gaan halen. Je kan bijvoorbeeld nieuwe objecten aanmaken of wat dan ook. Je krijgt van de parser een boom aangeleverd met elementen, tekst en attributen.

Met de SAX methode krijg je via een interface (ContentHandler) de inhoud van een XML document aangeleverd via een soort events. Als de parser iets tegen komen roept hij een methode aan in deze handler. Je bent zelf verantwoordelijk voor het bijhouden van structuren en gegevens. Als je niets doet, heb je na het parsen niets .

Het verschil tussen SAX en DOM? SAX lijkt op het eerste gezicht lastiger, maar het is voor bepaalde typen van documenten juist veel makkelijker en bovendien een stuk sneller. DOMs hebben de neiging om vrij veel geheugen in beslag te nemen, wat daarna weer allemaal vrij gemaakt moet worden. SAX doet dit niet en is dus voor grote documenten in feite de enige optie (of je moet een lazy DOM implementatie gebruiken). Gegegevens uit DOMs halen is bovendien niet zulk prettig werk. Dit wordt snel hele obscure code.

Welke programma's hiervoor?

JAXP werkt standaard met de DOM van de W3C. Algemeen wordt deze ervaren als een draak van een ding. Gegevens uit een W3C DOM halen is een hel en hij voelt absoluut niet aan als "Java".

JDOM is het alternatief, wat in de toekomst standaard in Java zal worden opgenomen. JDOM levert een klasse-structuur die lekker aanvoelt omdat het speciaal gericht is op Java. Als je dus een DOM oplossing kiest, zou ik zeker voor JDOM gaan. JDOM is overigens geen parser. Het werkt op basis van andere parsers zoals de default JAXP parser of bijvoorbeeld Xerces.

Je kunt gegevens ook uit een DOM halen met XPath. Met XPath (wat ook gebruikt wordt in XSLT) kan je locaties in een DOM aanwijzen. Dit werkt soms een stuk makkelijker dan zelf door de boom te gaan lopen. Voor JDOM is er een goede XPath engine: Jaxen.

SAX kan je eventueel nog iets mooier maken met behulp van een self-dispatcher, maar dat gaat nu iets te ver.

Ok, dat was het DOM en SAX verhaal. Dan nu serializatie naar Java Beans: Ik ben er niet van gecharmeerd. Ik heb eigenlijk altijd al een hekel gehad een serializatie, behalve voor gedistribueerde systemen. Serializatie van Java Beans naar XML is erg makkelijk, maar de XML documenten zijn een stuk minder human-readable dan wanneer je zelf een XMl document zou definieren. Ook moet je je uiteraard erg goed aan de Java Beans standaarden houden.

Tot slot: Java-XML Binding (JAXB). Dit is een toekomstig onderdeel van de JAX pack en op zich wel interessant. Gegeven een DTD en een binding specificatie worden er namelijk klasse gegeneerd die je XML document representeren. Het heeft dus in feite ver iets weg van DOM, maar dan met speciale klassen voor de knopen. JAXB werkt op zich wel aardig en het parsen gaat errug snel omdat het geen generieke code is. De binding specificatie is echter wel wat beperkt en de gegeneerde klassen zijn ook wat vaag soms.

Persoonlijk:
Ik gebruik zelf over het algemeen altijd SAX omdat het snel, safe en simpel is. Als een situatie echt te complex wordt stap ik over op JDOM, eventueel gecombineerd met Jaxen.

[Alarmnummer]

thanx voor je geweldige uitleg, ik zal het allemaal even doorkijken.

[mbravenboer]

Alarmnummer: thanx voor je geweldige uitleg, ik zal het allemaal even doorkijken.

Graag gedaan . Nog even wat links voor diegene die dat niet kunnen raden:

http://www.jdom.org voor JDOM

http://www.jaxen.org voor Jaxen

http://xml.apache.org voor onder andere de Xerces parser van Apache (met XML Schema ondersteuning!

http://java.sun.com/xml/ voor alles wat met JAX te maken heeft

http://www.w3c.org voor standaarden .

[Alarmnummer]

Ik kies voorlopig maar even voor JDom omdat dit een standaard gaat worden. En als het enigsinds kan dan kies ik voor een standaard opl

nog een leuke tutorial jdom en java:
http://www.javaworld.com/javaworld/jw-05-2000/jw-0518-jdom.html

[mbravenboer]

Alarmnummer: Ik kies voorlopig maar even voor JDom omdat dit een standaard gaat worden.

Leuk .

Overigens is SAX ook een standaard.... Serializatie voor Java Beans komt al in 1.4.0 en java-xml binding waarschijnlijk iets later... JDOM is ondertussen al behoorlijk stabiel, maar je weet nog niet wat Sun er mee gaat doen...

[mbravenboer]

Overigens nog een tip:

Ik gebruik regelmatig XSLT om een XML file te vereenvoudigen voordat ik hem inlees. Je kan hem op deze manier ook 'desugaren'. Op deze manier hoef je bij het opstellen van je XML bestandsformaat absoluut geen rekening te houden met de complicaties die je bij het inlezen krijgt. Transformeren gaat supersnel, dus dat is geen punt.

Erg makkelijk dus .

[fluister]
Af en toe is het zelfs zo dat een XML file makkelijk getransformeerd kan worden naar een Properties bestand. Soms gebruik ik dan stiekem Properties om XML in te lezen .
[/fluister]

[MisterData]

Op zondag 18 november 2001 16:22 schreef mbravenboer het volgende:
Serializatie voor Java Beans komt al in 1.4.0

Serializatie is toch al mogelijk met XMLDecoder/XMLEncoder ?

[Alarmnummer]

Ik ben nu paar tutorials van JDom aan het doorkijken en zijn er geen interfaces die je moet implementeren ofzo? Zijn er geen standaard methodes die je moet implementeren bij je objecten, of zijn er afspraken voor hoe de schrijf en lees methodes heten?

[mbravenboer]

MisterData: Serializatie is toch al mogelijk met XMLDecoder/XMLEncoder ?

Dat zei ik toch ook . Met komt in 1.4.0 doel ik op de final vesie. Het zit inderdaad al in de beta, maar niet in lagere versies dan 1.4.0.

[mbravenboer]

Alarmnummer: Ik ben nu paar tutorials van JDom aan het doorkijken en zijn er geen interfaces die je moet implementeren ofzo?

Dat klopt, DOMs zijn generiek voor alle XML bestandens. Ze leveren een boom van Element objecten (en eventueel nog wat meer).

Zijn er geen standaard methodes die je moet implementeren bij je objecten, of zijn er afspraken voor hoe de schrijf en lees methodes heten?

Nee, je hoeft niets te implementeren. Je kan een JDOM gewoon generiek inlezen en wegschrijven naar XML. Daar komen zelfs geen trucks bij kijken.

[Alarmnummer]

ik zie dat ze wel zelf wegschrijf code gebruiken.

http://www.javaworld.com/javaworld/jw-07-2000/jw-0728-jdom2.html

vb.

code:

Element parent = new Element("parent");
Element child1 = new Element("firstChild").setText("I'm number one");
Element child2 = new Element("secondChild").setText("I'm number two");
// Add the kids
parent.addContent(child1);
parent.addContent(child2);

Hoef je dit niet zelf te implementeren maar wordt dat uit gezocht aan de hand van je object structuur? Of moet je een methode hebben in ieder te xml`en object die kan inlezen en wegschrijven?

[mbravenboer]

Hum je moet de klepel nog een beetje zoeken .

Stel je hebt dit XML document:

code:

<cd-collectie>
    <cd>
      <titel>Beats for the Feet</titel>
      <artiest>Gigi D'Agostino</artiest>
    </cd>
</cd-collectie>

dan krijg je als je die inleest een Boom terug:

code:

Element: name = cd-collectie
    |
    |- Element: name = cd
      |
      |- Element: name = titel
      | |
      | |- tekst: ....
      |
      |- Element: name = artiest
           |
           |- tekst: ....

Je kan deze boom ook aanmaken via:

code:

Element root = new Element("cd-collectie");
Element cd   = new Element("cd");

root.addContent(cd);

cd.addContent(new Element("titel"));
cd.addContent(new Element("artiest"));
.....

Als je dat output (XMLOutputter) krijg je dus de eerste file.

[Alarmnummer]

ik bedoel:

code:

class Parent
{
    private Kind[] kinderen = null;
    private String naam = null;
    
    .......
    
    public void writeToXML(Element root)
    {
        Element classElement = new Element("Parent");
        root.addElement(classElement);
        
        Element nameElement = new Element("Name").setText(naam);
        classElement.add(nameElement);
        
        Element kinderenElement = new Element("Kinderen");
        classElement.add(kinderenElement);
        
        for(int k=0;k<kinderen.length;k++)
            kinderen[k].writeToXML(kinderenElement);
    }
}

class Kind
{
    public void writeToXML(Element root)
    {
        Element classElement = new Element("Kind");
        rootElement.addElement(classElement);
        
        etc etc etc.
    }
}

Niet op de code of methode namen letten et gaat om het idee.

[Alarmnummer]

En een bijkomend probleem is: class A heeft relatie naar B en visa versa. Dan blijf je hiermee een oneindig groot XML document genereren. Hoe wordt dat opgelost?

[mbravenboer]

Alarmnummer :En een bijkomend probleem is: class A heeft relatie naar B en visa versa. Dan blijf je hiermee een oneindig groot XML document genereren. Hoe wordt dat opgelost?

JDOM biedt hier geen voorzieningen voor, omdat het simpelweg een DOM is, die niet speciaal gemaakt is om zo te serializeren...

Ik zou het zelf liever als een Visitor implementeren ipv overal dedicated methoden. Je kunt in de Visitor linking makkelijk oplossen .

Eigenlijk zou je deze sharing generiek moeten implementeren en dat is ook al gebeurd voor andere systemen (ATermen).

[Alarmnummer]

is het dan niet veel handiger om XMLDecoder/XMLEncoder te gebruiken ipv (J)DOM of SAX? Want ik vraag me eerlijk gezegd af wat voor functionaliteit het toevoegd om zelf software ervoor te schrijven met kans op fouten.

[mbravenboer]

Dat kan inderdaad en als dat voor jou een goede oplossing is moet je dat ook gewoon doen.

Het komt echter niet al te vaak voor dat je XML formaat volledig vrij is. Over het algemeen heb je een reden om met XML te gaan werken:

1. Je moet een bepaald formaat inlezen

2. Je wilt een prettig human-readable formaat als opslag van bijvoorbeeld configuratie, document type of wat dan ook.

Voor beide situaties is Java Beans XML serializatie niet geschikt:
(1) je moet dat specifieke formaat inlezen. Dat kan alleen met SAX of DOM (eventueel zou het wel kunnen door eerst naar Java Beans XML formaat te transformeren).

(2) Het Java Beans document formaat is niet bepaald human-readable. Het is in feite niet interessant voor gebruiksvriendelijke editing en kan hooguit dienst doen als debug serializatie.

Uiteraard is die methode wel uitermate geschikt voor serializatie in gedistribueerde systemen (tussen verschillende Java versies) of fast&dirty long-term persistance.
Het hangt dus van de situatie af wat je het beste kan gebruiken. Ik ben in ieder geval nog geen situatie tegen gekomen waarbij het voor mij handig was. Ik maak wel gebruik van SAX, JDOM en JAXB.

[mbravenboer]

Alarmnummer: Want ik vraag me eerlijk gezegd af wat voor functionaliteit het toevoegd om zelf software ervoor te schrijven met kans op fouten.

Ik denk dat het door de vorige post wel duidelijk is, dat je Java Beans XMLDecoder/Encoder dus alleen kan gebruiken op Java Beans XML. Das dus het probleem . Op de Swing Connection van java.sun.com stond er een tijd geleden een artikel over:

http://java.sun.com/products/jfc/tsc/articles/persistence3

[Alarmnummer]

Bestaat voor 'mooie' xml een voorgekauwde ontwerp strategie?

[brammetje]

Op maandag 19 november 2001 21:35 schreef Alarmnummer het volgende:
Bestaat voor 'mooie' xml een voorgekauwde ontwerp strategie?

daar heb je zo'n icoontje voor nodig

maar ja, ik ben ook wel een beetje nieuwschierig al geloof ik niet dat er zoiets is..

mbravenboer, enlighten us

[Alarmnummer]

Op maandag 19 november 2001 21:44 schreef PlayR het volgende:
maar ja, ik ben ook wel een beetje nieuwschierig al geloof ik niet dat er zoiets is..

Zoiets moet al lang zijn uitgewerkt, anders was XML niet zo populair als het nu is. Maar ik zou wel eens willen weten wat de vaste aanpak is. Ik denk niet dat je in 1 object alle xml code wilt neerzetten, krijg je namelijk een ongelovelijke brei van code.

[The - DDD]

Ik heb nog nooit echt gewerkt met XML in Java. Maar als ik het goed begrijp moet je je XML code als een soort boom zien? Waarin elke geneste <..> en </..> (zo was het toch) tag een tak voorstelt?

[Alarmnummer]

Op maandag 19 november 2001 22:32 schreef The - DDD het volgende:
Ik heb nog nooit echt gewerkt met XML in Java. Maar als ik het goed begrijp moet je je XML code als een soort boom zien? Waarin elke geneste <..> en </..> (zo was het toch) tag een tak voorstelt?

Heb je helemaal gelijk in

[mbravenboer]

Je doelt als ik het goed begrijp op een soort design patterns voor het inlezen van XML?

Die ben ik nog niet tegen gekomen, maar dat zou wel erg mooi zijn. Ooit heb ik op javaworld wel een stuk gelezen over een 'mooie' opzet voor inlezen met sax, maar die kon ik niet echt waarderen.

Het inlezen van een DOM vind ik zelf toch het 'mooist' gaat met XPath expressies. Ik probeer eem DOM echt zoveel mogelijk te vermijden en gebruik vrijwel altijd SAX. Voor 'lineaire' xml documenten werkt dit heel eenvoudig en voor niet lineaire situaties kan je vaak een Stack gebruiken. Wel is het handig om dit in cominatie met de eerder genoemde self-dispatcher te doen...

[Alarmnummer]

Op dinsdag 20 november 2001 20:05 schreef mbravenboer het volgende:
Je doelt als ik het goed begrijp op een soort design patterns voor het inlezen van XML?

precies. Maar moet je dan elke keer het wiel opnieuw uitvinden? Want juist met serialized object hoef je dat zelf niet meer te doen. Zelfs a->b b->a problemen worden daar keurig netjes opgelost.

[MisterData]

En JAXB dan ?? Het beste van twee werelden ??

[mbravenboer]

Het inlezen van XML code is inderdaad een probleem. De grote vraag is hoe je dit goed generiek voor elkaar kunt krijgen.

Het grote probleem is dat XML code vertaalt moet worden naar objecten. In feite is dat dus een soort transformatie. JAXB biedt daarvoor een simpele oplossing: neem een DTD en genereer daaruit Java klassen die zelf de XML code inlezen.

Dat werkt op zich wel goed, maar op dit moment heeft het aan allebei de kanten veel beperkingen: de DTD moet er eigenlijk al een beetje uit zien als een OO klasse ontwerp en de gegenereede klassen voelen naar mijn mening soms niet erg prettig aan.

Serializatie van Java Beans lost het op een andere manier op: verzin een XML Schema om klasses generiek naar XML om te kunnen zetten. Op zich een aardig idee, maar hiermee pas je de XML documenten wel heel erg lomp aan aan de Java structuren.

Zelf doe ik het dus toch handmatig, en via SAX kan dit vaak heel mooi en kort. Met DOMs heb ik iets slechtere ervaringen.

Ik heb nog aan een andere oplossing zitten denken. Ik zei al eerder dat het in feite een transformatie is van XML structuren naar Java structuren. Nu kunnen we Java structuren al in XML beschrijven met behulp van het XML Schema van de Java Beans XML serializatie. Het zou dus wellicht een mooie oplossing zijn om je XML bestand met behulp van XSLT (een declaratieve transformatie taal) te transformeren naar 'JavaBeans-XML'. Je transformatie is nu in ieder geval niet hard-coded en declaratief.

[Alarmnummer]

Ik ben nu weer even met XML bezig, en vraag me af of er vaste namen zijn voor de methodes voor het inlezen en wegschrijven van XML.

[mbravenboer]

Alarmnummer: Ik ben nu weer even met XML bezig, en vraag me af of er vaste namen zijn voor de methodes voor het inlezen en wegschrijven van XML.

Nee niet echt, geef ze gewoon een logische naam zou ik zeggen .

Overigens zou ik de code voor inlezen en wegschrijven niet in de klassen zelf opnemen.

[Alarmnummer]

ik ben bezig aan de hand van dit artikel, en het XML en gaat vrij rap

http://www-106.ibm.com/developerworks/library/j-jdom/

[Alarmnummer]

Op donderdag 29 november 2001 13:50 schreef mbravenboer het volgende:
Overigens zou ik de code voor inlezen en wegschrijven niet in de klassen zelf opnemen.

Je maakt 1 object die alle objecten naar xml wegschrijft?

[mbravenboer]

Alarmnummer: Je maakt 1 object die alle objecten naar xml wegschrijft?

Dat ligt eraan wat je met 'alle' objecten bedoelt... In ieder geval is het zo dat je operaties over data-structuren beter niet allemaal in de data-structuur zelf kunt implementeren met dedicated methods. Het gebruik van een visitor achtige implementatie werkt dan een stuk beter: beter hergebruik, makkelijk aan te passen en makkelijk te specialiseren. Je ziet een simpele vorm hiervan in feite ook in JDOM met de XMLOutputters: de output methoden zitten niet in de klassen zelf. Ook de build methoden zitten er niet in. Voordeel: op verschillende manieren builden.

[Alarmnummer]

Ik heb oa een database, tableList, table, column, columnList, relation en relationList en die wil ik omzetten naar XML. Kan ik hiervoor het beste 1 wegschrijf/inlees object voor maken? Het leek mij eerlijk gezegd het meest voor de hand liggend om xml code wel in je objecten te houden, omdat je dan niet op meerdere plaatsen moet kijken.

vb code van de table.

code:

public Element writeXML()
{
    Element rootElement = new Element("table");
    rootElement.addChild(super.writeXML());
    rootElement.addChild(realTable.writeXML());
    rootElement.addChild(columnList.writeXML());
    return rootElement;
}

weet je misschien nog een paar tutorials of iets dergelijks waarin veel ontwerp kwesties worden aangekaart? Niet algemeen verhaal over XML maar over hoe je nu het beste het kan implementeren.

[mbravenboer]

Alarmnummer: Ik heb oa een database, tableList, table, column, columnList, relation en relationList

Wauw, heb jij even behoefte aan geparameterizeerde typen .

Kan ik hiervoor het beste 1 wegschrijf/inlees object voor maken? Het leek mij eerlijk gezegd het meest voor de hand liggend om xml code wel in je objecten te houden

Je hebt je algoritme dan verspreid over een hoop klassen. Dat is onduidelijk. Je moet voor een aanpassing in je 'operatie' een hoop klassen veranderen. Als je een nieuwe operatie wilt toevoegen moet je dit ook in een hoop klassen doen. Het Visitor pattern zorgt voor een scheiding tussen data-structuur en operaties over die data-structuur. Je operatie wordt dan een visitor over de data-structuur...

weet je misschien nog een paar tutorials of iets dergelijks waarin veel ontwerp kwesties worden aangekaart?

Tja, het boek is natuurlijk "Design Patterns van Gamma". Verder komt er op Javaworld weleens iets langs (zeker over Visitors).

Niet algemeen verhaal over XML maar over hoe je nu het beste het kan implementeren.

Design artikelen die speciaal gericht zijn op XML ken ik helaas niet.

[aphx]

Ik ken geen design patterns, maar het enige lastige in het begin vond ik de vraag:

Wanneer moet ik nou een "element" gebruiken en wanneer en "attribuut"?

En het enige houvast wat ik heb is, een "attribuut" zegt iets over een element...

Heeft iemand hier nog goede ideeen over?

[Alarmnummer]

Ik vind het niet zo erg om een wrapper om een collection type (arraylist,hashmap ed) te zetten. Heb meestal implementatie klaarliggen (die al tijd gebruikt word en goed getest is) en dan met replace even op maat maken voor specifiek geval. En ik heb ook niet de behoefte dat mijn wrapper dezelde functionaliteit heeft als een collection type. (kies zelf er voor wat voor methodes er zijn).

Wat me nog meer niet aanstaan aan geparametriseerde types is dat je niet rechtstreeks aan de code kan zien over wat voor soort objecten je het nu hebt. Bijvoorbeeld de add(Object item) krijg je te zien ipv add(Table table), en ik vind het laatste toch een stuk duidelijker. Als je alleen naar de 'template' functionaliteit gaat kijken van geparametriseerde types dan vind ik persoonlijk dat het niets toevoegd wat je met een wrapper ook kan doen. (in theorie kan ik wel iets bedenken.. maar in de praktijk heb ik het nog nergens nodig gehad).

[Alarmnummer]

Weet je misschien nog een freeware slimme xml editor? Dus niet alleen een met syntax highlighting, maar een die alles weer in bomen kan zetten ed.

[mbravenboer]

Zie trouwens ook dit topic: [topic=335243/1/25] . Hier komt de XML serializatie oplossing ter sprake.

aphx: Wanneer moet ik nou een "element" gebruiken en wanneer en "attribuut"?

Tja, dat is voor iedereen een probleem .

Heeft iemand hier nog goede ideeen over?

Ik gebruik meestal de regel: gegevens die alleen relevant zijn voor het 'systeem' en niet direct 'data' zijn zou je attribuut moet maken. Hierbij kan je denken aan identifiers en referenties.
Een andere visie die ook wel interessant is zag ik pas in Stratego. Deze gebruikt namelijk een ander universeel data-type: atermen. Deze atermen zijn erg vergelijkbaar met XML. In atermen heb je ook een soort attributen, maar daar zijn het meer decorations, annotations (aantekeningen, opleukingen) en maken niet direct deel uit van de data. Je kan hierin bijvoorbeeld extra informatie opslaan die niet direct van toepassing is voor de data.

[Alarmnummer]

Op donderdag 29 november 2001 16:48 schreef mbravenboer het volgende:
Je hebt je algoritme dan verspreid over een hoop klassen. Dat is onduidelijk. Je moet voor een aanpassing in je 'operatie' een hoop klassen veranderen. Als je een nieuwe operatie wilt toevoegen moet je dit ook in een hoop klassen doen.

daar zit wel iets in, ivm a->b b->a relatie problemen.

Het Visitor pattern zorgt voor een scheiding tussen data-structuur en operaties over die data-structuur. Je operatie wordt dan een visitor over de data-structuur...

Kun je misschien een voorbeeld geven waar je gebruikt maakt van de Visitor pattern?

Tja, het boek is natuurlijk "Design Patterns van Gamma". Verder komt er op Javaworld weleens iets langs (zeker over Visitors).

vanmorgen besteld over 3 week is het boek er. Samen met concurrent programming van Doug Lee..

[mbravenboer]

Alarmnummer: Wat me nog meer niet aanstaan aan geparametriseerde types is dat je niet rechtstreeks aan de code kan zien over wat voor soort objecten je het nu hebt. Bijvoorbeeld de add(Object item) krijg je te zien ipv add(Table table), en ik vind het laatste toch een stuk duidelijker.

Mwah, dat is niet helemaal zo. In een geparameterizeerde klasse heb je een afkorting (E bijvoorbeeld) voor de klasse waarmee je parameterizeert. Je ziet dus add(E item) ipv add(Object item). Dat vind ik zelf dus wel een stuk duidelijker . Om het nog maar niet over type-safety te hebben.

Als je alleen naar de 'template' functionaliteit gaat kijken van geparametriseerde types dan vind ik persoonlijk dat het niets toevoegd wat je met een wrapper ook kan doen. (in theorie kan ik wel iets bedenken.. maar in de praktijk heb ik het nog nergens nodig gehad).

Geparameterizeerde typen zijn wel iets anders dan templates (maar je kunt ze inderdaad voor hetzelfde gebruiken). Geparameterizeerde typen hebben als belangrijkste voordeel ten opzichte van speciale klassen dat je gemakkelijk generiek kunt werken zonder dat je type-safety op hoeft te offeren. In jouw geval moet je al je wrappers gaan aanpassen als je iets anders wilt. Geparameterizeerde typen zijn bovendien niet alleen handig voor collections. Ze nodigen op veel manieren uit tot generiek werken.

XML editor? Er zijn er veel en ook wel aardig goede geloof ik. Zelk ben ik tevreden met jext in combinatie met een validator.

[mbravenboer]

Alarmnummer: Kun je misschien een voorbeeld geven waar je gebruikt maakt van de Visitor pattern?

Hier staat een artikel over Visitors, waarin ik nog een wat ingewikkeldere variant voorstel (die je kan negeren). Ik denk dat het daarmee wel duidelijk moet zijn. Op Javaworld stond ook eens een leuk artikel. Op dit forum heb ik ook weleens eens een Visitor voorbeeld gegeven.

vanmorgen besteld over 3 week is het boek er. Samen met concurrent programming van Doug Lee..

Cool .

[mbravenboer]

Ik kwam hier een behoorlijk goed artikel tegen, wat een zeer uitgebreid overzicht geeft met wat voorbeelden. Zag er erg goed uit .

http://developer.java.sun.com/developer/technicalArticles/xml/JavaTechandXML/

Het is deel 1 van een hele serie, dus de hele serie wordt een leuke voor de FAQ .

[Alarmnummer]

Thanx

[Alarmnummer]

Op donderdag 29 november 2001 16:54 schreef aphx het volgende:
Ik ken geen design patterns, maar het enige lastige in het begin vond ik de vraag:

Wanneer moet ik nou een "element" gebruiken en wanneer en "attribuut"?

En het enige houvast wat ik heb is, een "attribuut" zegt iets over een element...

Heeft iemand hier nog goede ideeen over?

Ik zit met hetzelfde probleem. Wanneer gebruik je een attribuut en wanneer een element?

[Alarmnummer]

ik heb nu het volgende XML bestaand gemaakt (gedeelte)

code:

<multiDatabase>
  MultiDatabase
  <databaseList>
    <database name="ASA" label="">
    <realDatabase name="ASA">
      <driverName>sun.jdbc.odbc.JdbcOdbcDriver</driverName>
      <url>jdbc:odbc:ASA 7.0 Sample</url>
      <loginName />
      <password />
    </realDatabase>
    <tableList>
      <table name="contact" sqlName="contact" label="contact">
        <columnList>
        <column name="id" type="int" key="true" view="false" sqlName="id" label="id" />
        <column name="last_name" type="string" key="false" view="false" sqlName="last_name" label="last_name" />
        <column name="first_name" type="string" key="false" view="false" sqlName="first_name" label="first_name" />
        <column name="title" type="string" key="false" view="false" sqlName="title" label="title" />
        <column name="street" type="string" key="false" view="false" sqlName="street" label="street" />

En waar ik mee zit is wanneer je nou een attribuut en wanneer je een element gebruik. Stel dat ik alle eigenschappen van de column op een aparte regel zou zetten, dan wordt het onoverzichtelijk. Doe ik het niet dan krijg ik lange (en dus minder leesbare) regels.

[mbravenboer]

code:

<multiDatabase>
  MultiDatabase
  <databaseList>

Hum, ik zie hier mixed-content, dat zou ik zoveel mogelijk vermijden...

Verder is het erg makkelijk om niet al te 'vette' XML files te maken. Het is heel makkelijk om de zaak een beetje te verdelen over verschillende files. Dit heeft een aantal voordelen: overzichtelijker en veel makkelijker in te lezen.

In dit geval zou je bijvoorbeel 3 verschillende typen files kunnen maken:

1. file met database typen. Hierin kan je een database type definieren, met de vorm van de URL en de gebruikte driver. Dit heb ik zelf geimplementeerd. Als je een voorbeeld wilt zien hoe ik dat gedaan heb, gewoon ff een gil geven .

2. file met beschikbare databases, of gewoon zelfs voor elke database een aparte file. Dit wordt dus in feite een 'database-account'. Hierin refereer je naar een database type. Ook hiervan heb ik wel een voorbeeld liggen.

3. file met tabellen van een database.

Uiteraard kan je er ook 1 grote file van maken, maar bij het inlezen is het dan erg makkelijk om met behulp van een stylesheet eventjes de file onder te verdelen in de drie genoemde aspecten.

Als je gebruik maakt van JDOM (en dat doe je ) is het ook erg makkelijk om met XPath te werken om gegevens uit je boom te halen. Voor JDOM kan je hierbij Jaxen gebruiken.

Over attributen versus elementen: meestal wordt alleen systeem-data als attribuut gebruikt. Wat systeem-data is, is natuurlijk een vage beslissing. Een groot voordeel van attributen is dat je in een DTD of XML Schema default waarden kunt opgeven. Je hoeft deze default waarden dan niet in elke XML file op te nemen. Ook lezen attributen meestal een stukje makkelijker in... Sowieso moet je natuurlijk altijd iets wat eventueel sub-structuur kan hebben niet als attribuut gebruiken.

Het is eigenlijk jammer dat XML attributen geen sub-structuur kunnen hebben. Attributen zijn sterk te vergelijken met aantekeningen. Als deze aantekeningen ook sub-structuur konden hebben (zoals in andere systemen) zou de keuze vaak veel duidelijker zijn...

[mbravenboer]

Omdat dit topic een aardig overzicht geeft van technieken om XML in te lezen post ik dit hier maar even.

Javaworld heeft een leuk artikel waarin het idee van XML data binding wordt uitgelegd. Ze behandelen een simpel voorbeeld van JAXB en Castor...

Veel plezier .

http://www.javaworld.com/javaworld/jw-12-2001/jw-1228-jaxb.html?