Hoe XML correct te gebruiken
XML als hulpmiddelVeelgebruikte afkortingen- CDATA: Karaktergegevens
- DOM: Documentobject Model ( objectmodel document)
- E4X: ECMAScript voor XML (ECMAScript voor XML)
- IDE: Integrated Development Environment (geïntegreerde ontwikkelomgeving)
- W3C: Wereldwijd Webconsortium (WWW-consortium)
- XML: uitbreidbaar Opmaaktaal(uitbreidbare opmaaktaal)
- XSLT: Uitbreidbare stylesheet-taaltransformaties
XML wordt nu als vanzelfsprekend beschouwd. Hij is overal! Maar als je van buitenaf kijkt, zie je dat dit een krachtige technologie is. Er zijn geïntegreerde ontwikkelomgevingen waarmee u XML-bomen kunt bouwen. Er zijn een aantal technologieën om de juistheid van XML-code te controleren. Er is XSLT - een speciale taal XML-transformaties. XML-ondersteuning is zelfs rechtstreeks ingebouwd in de syntaxis van sommige talen (zoals E4X in ActionScript).
Maar XML heeft dat ook achterkant. Het kan verkeerd worden gebruikt. Het kan slecht worden gebruikt. Het kan te complex zijn. Het kan zijn dat het ondergespecificeerd is. Hij kan moeilijk zijn om mee te werken. Wat moet er nog meer gebeuren effectief gebruik deze krachtige technologie? In mijn artikel geef ik 10 tips die helpen deze vraag te beantwoorden.
Gebruik XML niet als bestandsnaam of roottagVaak heb ik gezien dat XML-code is opgeslagen in bestanden met de extensie .xml. Het is zinloos. Zo'n extensie zal mij niets vertellen dat ik niet al weet door het simpelweg te doen katten commando. Zodra ik de tags zie, weet ik meteen dat het XML is. Gebruik in plaats van deze extensie een extensie die zinvol is voor de gebruiker. Je kunt ook gebruiken unieke uitbreiding dus wanneer Google-zoekopdracht heeft koppelingen geretourneerd naar documentatie of voorbeelden van uw XML-bestandsindeling.
Een ander probleem in sommige XML-documenten is het gebruik van de root-tag. Dit betekent wederom niets. Wat staat er in dit bestand? Als dit een lijst met contactpersonen is, moet het hoofdknooppunt de tag zijn. XML moet leesbaar zijn, dus gebruik tag- en attribuutnamen die relevant zijn voor het bedrijfsprobleem waaraan u werkt. Als het hoofdknooppunt , verwacht ik de tags te zien, en vervolgens de tags , , , enz.
Overschrijf generieke of taalspecifieke constructies nietIk begrijp dat XML een formaat is voor het opslaan van gegevens. De meeste talen bieden een manier om datastructuren in XML op te slaan. Het is goed als u zeker weet dat alleen processen die in dezelfde taal zijn geschreven, uw XML-code ooit zullen lezen of schrijven. Dit is echter zeldzaam. Als uw toepassing iets naar een bestand schrijft, is de kans groot dat dit op een bepaald moment door een gebruiker of een toepassing in een andere taal zal worden gelezen.
Hiermee bedoel ik dat taalspecifieke constructies buiten XML moeten worden opgeslagen. Hoe vaak hebben jullie elkaar ontmoet op 18-07-2010? Wat is NSDate? Ja, dit is de naam van de klasse voor het werken met datums op het applicatieplatform. Wat gebeurt er als ik van platform of taal verander? De NSDate-tags moeten worden omgezet naar iets anders dat op het nieuwe platform wordt gebruikt.
Houd taalspecificaties buiten XML en gebruik eenvoudige tags, bijvoorbeeld ... . Zo'n tag is gemakkelijk te begrijpen, leesbaar en onafhankelijk van een specifieke taal of raamwerk.
Nog één ding belangrijke regel– Vermijd het gebruik van onnodige generalisaties in XML. Kijk eens naar het volgende voorbeeld():
Lijst 1. Gegeneraliseerde jack-node-boomWat betekent dit? Ik realiseerde me dat dit een lijst met gebruikers is. Maar het is moeilijk voor een persoon om te lezen en te bewerken. Wat nog erger is, is dat deze XML erg moeilijk te gebruiken is in tools als XSLT of te valideren aan de hand van een schema. B laat zien wat bovenstaande XML-code eigenlijk betekent.
Lijst 2. Een efficiëntere jack-node-boomIs het niet beter zo? De code zegt wat er staat en betekent wat er staat. Het is gemakkelijker te lezen en te analyseren. Het is gemakkelijker om te controleren en te converteren wanneer XSLT-hulp. Het is zelfs nog kleiner van formaat.
Maak bestanden niet te grootIk weet wat je zult zeggen: " Schijfgeheugen het is goedkoop. Voor tien cent koop ik nog een terabyte." Dat is waar. Je kunt inderdaad gigabyte XML-bestanden maken. Maar programmeren gaat over voortdurende compromissen. Je moet veranderen schijfruimte voor een tijd of een herinnering voor een tijd. En als je met een enorm XML-bestand werkt, krijg je slechtste kanten beide. Het bestand neemt veel schijfruimte in beslag en het analyseren en controleren ervan kost veel tijd. Daarnaast, groot bestand elimineert het gebruik van een DOM-parser, omdat het bouwen van de boom oneindige tijd en een enorme hoeveelheid geheugen vereist.
Wat is het alternatief? U kunt meerdere bestanden maken. Eén fungeert als index en de andere bevatten grote bronnen die mogelijk niet door alle gebruikers van deze XML nodig zijn. Een andere optie is om alle grote CDATA-fragmenten uit het XML-bestand te verwijderen en in uw eigen bestand te plaatsen eigen bestanden met uw eigen formaten. Als u alle gegevens bij elkaar wilt houden, pakt u alle bestanden in nieuw bestand met een nieuwe uitbreiding. Elk populaire taal programmeren heeft modules die het snel in- en uitpakken van bestanden vergemakkelijken.
Gebruik geen naamruimten, tenzij dit absoluut noodzakelijk isNaamruimten vormen een krachtig onderdeel van het XML-lexicon. Ze vergemakkelijken de implementatie van uitbreidbare bestandsformaten. Jij kunt bepalen basisset tags voor alle behoeften van uw toepassing, en sta gebruikers vervolgens toe hun eigen gegevens toe te voegen aan hun eigen naamruimte in het bestand zonder uw objectboom te beïnvloeden.
Naamruimten maken het echter erg moeilijk om gegevens te ontleden en te manipuleren. Ze verwarren programmeertaalextensies zoals E4X. Ze maken het moeilijk om XML in XSLT te gebruiken. Ten slotte maken ze XML-bestanden veel moeilijker leesbaar.
Gebruik daarom alleen XML-naamruimten als je ze echt nodig hebt. Gebruik ze niet simpelweg omdat 'XML het toestaat'. XML werkt prima zonder naamruimten.
Niet gebruiken speciale karaktersAl mijn tips zijn erop gericht om uw XML-code schoon, eenvoudig en gemakkelijk leesbaar te houden. In die zin staat zelfs de XML-specificatie veel toe dat niet noodzakelijkerwijs wordt gebruikt. U kunt bijvoorbeeld een streepje gebruiken in de namen van elementen en attributen. Maar dit maakt het erg moeilijk om dergelijke XML-code te gebruiken in taalextensies zoals E4X. De vraag is: is het het waard?
Gebruik XML-schemaXML-parsering is geen gemakkelijke taak. Voor een nauwkeurige analyse is het noodzakelijk om dit te doen geweldig werk over het beschermen van code tegen mogelijke afwezigheid en onjuist gebruik van tags of attributen. Dit extra werk over het schrijven van code, het toevoegen van complexiteit en het verdoezelen van de echte bedrijfslogica waar u zich het meeste zorgen over maakt. Hoe kun je dit vermijden? Valideer XML voordat u het gebruikt. Hiervoor kunnen verschillende standaarden worden gebruikt. U kunt opgeven Documenttype Definitie (DTD) of XML-schema (links naar informatie over DTD en XML-schema vindt u in de sectie). Persoonlijk vind ik XML Schema veel gemakkelijker om mee te werken, maar als je nieuw bent, probeer het dan eens diverse systemen juistheidscontroles.
Het grote voordeel is dat zodra de XML op juistheid is gecontroleerd, u er vertrouwen in kunt hebben. Dit is mogelijk niet nodig voor de interne XML-bestanden van uw toepassing. Maar het is erg handig als de XML door een andere applicatie wordt gegenereerd of handmatig wordt geschreven.
Nummer de versiesHet is heel gemakkelijk om uit het oog te verliezen dat XML die in bestanden is opgeslagen, gelijkwaardig is aan een bestandsformaat. Het eerste dat een bestand van welk formaat dan ook moet bevatten, is een versienummer. Het is eenvoudig genoeg om toe te voegen: ... . De code die het bestand leest, moet controleren of het versienummer niet groter is dan dit huidige versie en genereren uitzonderlijke situatie als dit niet het geval is. Dit zorgt ervoor dat eventuele volgende versies van de code bij het gebruik van nieuwe tags niet in conflict zullen komen met oudere versies. Uiteraard moet u ervoor zorgen dat alle oudere versies van de bestanden worden ondersteund terwijl u doorgaat met het ontwikkelen van uw applicatie.
Combineer knooppunten en attributenIngenieurs zijn behoorlijk luie mensen. Ik kan dit zeggen omdat ik zelf ook zo ben. Maak geen ruzie, zo zijn we allemaal. Als de IDE aanbiedt om de XML-export voor ons te doen, zullen we het daar waarschijnlijk mee eens zijn. Maar doorgaans produceert het raamwerk zeer slechte XML. Je bent waarschijnlijk al iets tegengekomen dat lijkt op:
Lijst 3. Lijst met gebruikers 1 jackMoet het een label zijn? Ik ben van mening dat het een attribuut moet zijn. De code wordt korter en betekenisvoller, en het wordt mogelijk om naar een gebruiker te zoeken op ID met behulp van een eenvoudige XPath-expressie (/users/user[@id=1]).
Om de code leesbaar te maken, is het ongetwijfeld beter om attributen te gebruiken, zoals weergegeven in .
Lijst 4. Een handiger lijst met jack-gebruikersHet is duidelijk dat het raamwerk genereerde, omdat het altijd veiliger is om knooppunten te gebruiken. Maar attributen stellen ons in staat te identificeren belangrijke elementen in de DOM-structuur, dus u moet ze gebruiken.
Gebruik CDATA, maar gebruik het niet te veelXML legt veel beperkingen op aan het gebruik bepaalde karakters: aanhalingstekens, ampersands, kleiner dan en groter dan-tekens, enz. In de praktijk worden deze symbolen echter zeer vaak gebruikt. Daarom moet je óf alles omzetten in iets veiligs XML-formaat, of het plaatsen van grote stukken tekst, code of iets anders in CDATA-blokken. Het lijkt mij dat ontwikkelaars het gebruik van CDATA vermijden omdat ze denken dat dit het parseren moeilijk zal maken. Maar CDATA-secties zijn niet moeilijker te parseren dan wat dan ook: de meeste DOM-parsers verwerken ze zelf, dus je hoeft er niet eens over na te denken.
Nog één belangrijke reden Het gebruik van CDATA is bedoeld om de nauwkeurige gegevensopmaak te behouden. Wanneer u bijvoorbeeld een Wiki-pagina exporteert, wilt u waarschijnlijk de exacte posities van tekens behouden, zoals regelterugloop en regelinvoer, aangezien deze worden afgespeeld bijzondere rol in Wiki-formaat.
Waarom niet altijd CDATA-partities gebruiken? Omdat ze het document erg moeilijk leesbaar maken. Dit is vooral vervelend als ze niet nodig zijn. Gebruik ze dus en moedig gebruikers aan om ze in uw XML-bestanden te gebruiken in situaties waarin u verwacht dat de gegevens speciale tekens bevatten en waar u de oorspronkelijke opmaak wilt behouden. Maar gebruik CDATA niet in andere situaties.
Bewaar optionele gegevens in een apart gebiedTot nu toe heb ik het gehad over rigide opgemaakte XML-documenten. Ik raadde zelfs aan een validatietechnologie te gebruiken (zoals XML Schema) die een rigide structuur garandeert. Daar is een goede reden voor: gestructureerde gegevens zijn gemakkelijker te analyseren. Wat als u enige flexibiliteit nodig heeft? Ik raad aan om optionele gegevens in een apart blok in een eigen knooppunt te plaatsen. Kijk bijvoorbeeld eens op .
Lijst 5. Buitengebruikstellingsrecord voor gebruiker Jack D Herrington 8:00Dit record bevat alle verwachte gebruikersgegevens. Ik ben het eens met first, middle, last, maar waarom is runningspace hier? Is dit nodig? Zult u veel van deze velden hebben? Zullen ze uitbreidbaar zijn? Als het antwoord op al deze vragen ja is, zou ik aanraden dit te doen (zie):
Lijst 6. Goed gestructureerd bericht voor gebruiker Jack D Herrington 8:00Met deze aanpak kunt u zoveel velden hebben als u wilt, zonder dat de naamruimte onoverzichtelijk wordt ouderelement. U kunt zelfs de geldigheid van dit document controleren en toegang krijgen tot een specifiek veld met behulp van een XPath-expressie (//user/userdata/field[@name="runningpace").
ConclusieDenk na over wat ik heb gezegd. Ik heb vijf dingen aanbevolen die je moet doen en vijf dingen die je moet vermijden. Niet al mijn adviezen zijn in alle omstandigheden van toepassing. Soms is XML slechts een formaat voor het opslaan van gegevens die via het netwerk worden verzonden en die slechts enkele milliseconden duren. In dit geval hoeft u zich nergens zorgen over te maken. Maar wanneer met behulp van XML als bestandsformaat moet u mijn advies opvolgen en de hier gepresenteerde aanbevelingen toepassen.
Om de inhoud van XML-bestanden automatisch te converteren naar een voor mensen leesbare vorm/formaat (html, rtf, pdf, txt, vrml, svg, java, enz.), moet u XSLT gebruiken in plaats van CSS te gebruiken.
Nadelen van CSS:
1. CSS kan de volgorde van elementen in een XML-document niet wijzigen. Als je sommige elementen wilt sorteren of filteren op een bepaalde eigenschap, dan zal CSS je hier zeker niet mee helpen.
2. CSS doet geen berekeningen. Als u een waarde wilt berekenen en weergeven (bijvoorbeeld som numerieke waarden alle elementen in het xml-document), CSS zal niet bij u passen.
3. CSS kan geen documenten samenvoegen. Als u een paar dozijn XML-documenten met inkooporders wilt combineren en een samenvatting van alle bestelde producten wilt afdrukken, dan zal CSS u opnieuw niet helpen.
Een klein voorbeeld van het gebruik van XSL
Er is een xml-bestand voor plug-ininstellingen:
De plug-in bestuurt de instellingen van AutoCAD-tekenlagen. Hieronder vindt u een tabel met de items die worden gecontroleerd.
De laagnaam controleren
WAAR
Controleren of de laagnaam voldoet aan de naamgevingsregel
De laagkleur controleren
WAAR
Controleren of aan de laag kleuren zijn toegewezen vanuit het palet "Indexkleur".
Lijntypecontrole
WAAR
Controleren of aan lagen alleen lijntypen uit een bepaalde set worden toegewezen
Lijndiktes controleren
WAAR
Controleren of aan lagen alleen lijndiktes uit een bepaalde set worden toegewezen
Controleren op een notitie
WAAR
Elke laag moet een notitie hebben die het doel ervan ontcijfert
Vaste lagenset
vals
Moet het gebruikers verboden worden om extra lagen te maken, volgens de regels vastgelegd in de Standaard?
De plug-in moet de instellingen daaruit uitlezen en in overeenstemming daarmee werken. Tegelijkertijd moet er enige documentatie zijn die de gebruiker kan lezen en begrijpen. Bovendien moet het materiaal dat in de documentatie wordt gepresenteerd overeenkomen met de instellingen die zijn ingesteld huidige moment. Om er niet aan te denken dat u na het aanpassen van de instellingen de documentatie moet gaan bewerken, kunt u dit alles in de vorm van één xml-bestand presenteren. De plug-in leest de instellingen ervan en de gebruiker opent deze in de browser en... ziet deze in een "menselijke" vorm... Maak hiervoor een bestand styleSheet.xsl met de volgende inhoud:
Plugin-instellingen
Parameter Betekenis Opmerking
Als een gebruiker ons xml-bestand in een browser opent, zal hij geen verwarrende (vanuit zijn gezichtspunt) onhandige xml-tekst zien, maar dit:
IN in dit voorbeeld Ik heb geen selectie, sortering, filtering, verschillende soorten bewerkingen en berekeningen laten zien (ze waren hier niet nodig), maar indien nodig kan dit allemaal worden gedaan met XSLT.
Doel van de les
Inleiding tot XML-technologie. Ontdek de mogelijkheid om XML-documenten in HTML weer te geven. Gebruik JavaScript-scripts voor het navigeren door een XML-tabel en het organiseren van gegevenszoekopdrachten op voorwaarde. Aanbevolen lectuur.
Korte theoretische informatie
XML-technologie (eXtensible Markup Language) ontstond eind jaren negentig van de vorige eeuw. De belangrijkste voordelen van XML-tekst:
□ heeft een databasestructuur, toegankelijk voor computers en mensen;
□ gemakkelijk verwerkt door middel moderne talen programmering;
□ eenvoudig vertaald naar HTML.
Beschouw het volgende voorbeeld van een tekstdatabase geschreven in XML:
Drie mannen in de boot
Jerom-K-Jerom
12000
Notre Domme de Paris
V.Hugo
15000
Een oorlog en vrede
L. Tolstoj
16500
Angelika - de minnares van geesten A en S. Gallen
9000
Dit is een voorbeeld van een correct samengestelde XML-document, waarvan de elementen tags , , , , , zijn
Elementen in de tekst zijn gerangschikt als een boom met een kopelement. Aan elk element is een afsluitend element gekoppeld. De reikwijdte van elk element wordt beperkt door de openings- en sluitingselementen. Het is niet toegestaan om de reikwijdte van elementen te overschrijden, d.w.z. De gebieden liggen in elkaar genest of snijden elkaar helemaal niet. Een element waarvan de reikwijdte de reikwijdte van alle andere elementen omvat, wordt het rootelement genoemd. Een XML-document kan worden gezien als een tekstdatabase. De waarde van een element is de informatie die tussen de definiërende tags wordt geplaatst dit onderdeel. De waarde van het eerste element is dus de string
Drie mannen in de boot.
Typ deze tekst in een willekeurige editor en sla deze op als eenvoudig tekstbestand met een xml-extensie - noem dit bestand bijvoorbeeld textbd.xml. U kunt dit bestand bekijken Internetbrowser Verkenner op dezelfde manier waarop u HTML-bestanden hebt bekeken. Als er een fout optreedt, wordt de XML-interpreter weergegeven gedetailleerde informatie over de locatie en de essentie van de fout.
Nu zullen we laten zien hoe u deze uitvoer naar een tabelvorm kunt converteren. HTML-formulier, die wordt uitgevoerd met behulp van HTML. Laten we creëren volgende bestand HTML (Lijst 2.12).
Lijst 2.12. HTML-document dat moet worden weergegeven XML-tabellen
