XML (Extensible Markup Language) on varmasti yksi kuumimmista tekniikoista tällä hetkellä. Merkintäkielien käsite ei ole uusi, mutta XML näyttää erityisen houkuttelevalta Java- ja Internet-ohjelmoijille. Java-sovellusliittymä XML-jäsentämiseen (JAXP; katso resurssit), joka on äskettäin määritelty Java-yhteisöprosessin kautta, lupaa tarjota yhteisen käyttöliittymän XML-asiakirjojen käyttämiseen. W3C on määritellyt niin kutsutun Document Object Model (DOM) -ominaisuuden, joka tarjoaa vakioliittymän XML-asiakirjan käsittelyyn puuhierarkiassa, kun taas Simple API for XML (SAX) antaa ohjelman jäsentää XML-asiakirjan peräkkäin tapahtumien käsittelymallissa. Molemmat standardit (SAX on tosiasiallisesti standardi) täydentävät JAXP: tä. Nämä kolme sovellusliittymää tarjoavat riittävästi tukea Java-XML-asiakirjojen käsittelyyn, ja lukuisat markkinoilla olevat kirjat kuvaavat niiden käyttöä.
Tässä artikkelissa esitellään tapa käsitellä XML-asiakirjoja, jotka ylittävät tavalliset Java-sovellusliittymät XML: n manipuloimiseksi. Näemme, että monissa tapauksissa XPath ja XSLT tarjoavat yksinkertaisempia ja tyylikkäämpiä tapoja ratkaista sovellusongelmia. Joissakin yksinkertaisissa näytteissä verrataan puhdasta Java / XML-ratkaisua sellaiseen, joka käyttää XPathia ja / tai XSLT: tä.
Sekä XSLT että XPath ovat osa Extensible Stylesheet Language (XSL) -määritystä (katso Resurssit). XSL koostuu kolmesta osasta: itse XSL-kielimääritys, XSL-muunnokset (XSLT) ja XML-polun kieli (XPath). XSL on kieli XML-dokumenttien muuntamiseksi; se sisältää määritelmän - Objektien muotoilu - kuinka XML-asiakirjat voidaan muotoilla esittelyä varten. XSLT määrittää sanaston yhden XML-asiakirjan muuntamiseksi toiseksi. Voit pitää XSLT: tä XSL: nä miinus objektien muotoilu. XPath-kieli käsittelee XML-asiakirjojen tiettyjä osia, ja se on tarkoitettu käytettäväksi XSLT-tyylitaulukossa.
Tässä artikkelissa oletetaan, että olet perehtynyt XML: n ja XSLT: n perusteisiin sekä DOM-sovellusliittymiin. (Katso lisätietoja ja oppaita näistä aiheista kohdasta Resurssit.)
merkintä: Tämän artikkelin koodinäytteet koottiin ja testattiin Apache Xerces XML-jäsentimellä ja Apache Xalan XSL -prosessorilla (katso Resurssit).
Ongelma
Monissa XML-tiedostoja käsittelevissä artikkeleissa ja artikkeleissa todetaan, että se on täydellinen tapa toteuttaa hyvä suunnittelutapa web-ohjelmoinnissa: Model-View-Controller-malli (MVC) tai yksinkertaisemmin sanottuna sovellustietojen erottaminen esitystiedoista . Jos sovellustiedot on muotoiltu XML-muodossa, ne voidaan helposti sitoa - tyypillisesti servletissä tai Java ServerPage -sivustossa - esimerkiksi HTML-malleihin käyttämällä XSL-tyylitaulukkoa.
Mutta XML voi tehdä paljon enemmän kuin vain auttaa mallinäkymän erottamisessa sovelluksen käyttöliittymässä. Tällä hetkellä havaitaan yhä enemmän komponenttien (esimerkiksi EJB-standardilla kehitettyjen komponenttien) laajaa käyttöä, joita voidaan käyttää sovellusten kokoamiseen, mikä parantaa kehittäjien tuottavuutta. Komponenttien uudelleenkäytettävyyttä voidaan parantaa muotoilemalla tiedot, joita komponentit käsittelevät tavanomaisella tavalla. Voimme odottaa yhä enemmän julkaistuja komponentteja, jotka käyttävät XML: ää käyttöliittymien kuvaamiseen.
Koska XML-muotoiset tiedot ovat kielineutraaleja, ne tulevat käyttökelpoisiksi tapauksissa, joissa tietyn sovelluspalvelun asiakasta ei tunneta tai jos sillä ei saa olla riippuvuuksia palvelimesta. Esimerkiksi B2B-ympäristöissä ei voi olla hyväksyttävää, että kahdella osapuolella on tietojensiirtoon riippuvuus konkreettisista Java-objektirajapinnoista. Uudet tekniikat, kuten Simple Object Access Protocol (SOAP) (katso resurssit), vastaavat näihin vaatimuksiin.
Kaikilla näillä tapauksilla on yksi yhteinen asia: tiedot tallennetaan XML-asiakirjoihin, ja sovellus tarvitsee niitä käsitellä. Esimerkiksi sovellusten, jotka käyttävät eri toimittajien eri komponentteja, on todennäköisesti muutettava (XML) -tietojen rakennetta, jotta ne sopivat sovelluksen tarpeisiin tai noudattavat tiettyä standardia.
Koodi, joka on kirjoitettu käyttämällä yllä mainittuja Java-sovellusliittymiä, tekisi tämän varmasti. Lisäksi on olemassa enemmän ja enemmän työkaluja, joilla voit muuttaa XML-asiakirjan JavaBeaniksi ja päinvastoin, mikä helpottaa tietojen käsittelyä Java-ohjelmassa. Monissa tapauksissa sovellus tai ainakin osa siitä vain käsittelee yhden tai useampia XML-asiakirjoja syötteenä ja muuntaa ne eri XML-muotoon ulostulona. Tyylitaulukoiden käyttö näissä tapauksissa on toteuttamiskelpoinen vaihtoehto, kuten näemme myöhemmin tässä artikkelissa.
Paikanna solmut XML-asiakirjassa XPathin avulla
Kuten edellä todettiin, XPath-kieltä käytetään XML-asiakirjan tiettyjen osien paikantamiseen. Sellaisena se on tarkoitettu käytettäväksi XSLT-tyylitaulukossa, mutta mikään ei estä meitä käyttämästä sitä Java-ohjelmassa, jotta vältetään pitkä iterointi DOM-elementtihierarkiassa. Voimme todellakin antaa XSLT / XPath-prosessorin tehdä työn puolestamme. Katsotaanpa, miten tämä toimii.
Oletetaan, että meillä on sovellusskenaario, jossa lähde-XML-asiakirja esitetään käyttäjälle (mahdollisesti sen jälkeen, kun tyylitaulukko on käsitellyt sen). Käyttäjä päivittää tietoja ja lähettää verkon kaistanleveyden säästämiseksi vain päivitetyt tietueet takaisin sovellukseen. Sovellus etsii päivitettävää lähdeasiakirjasta XML-fragmenttia ja korvaa sen uusilla tiedoilla.
Luomme pienen näytteen, joka auttaa sinua ymmärtämään erilaisia vaihtoehtoja. Tässä esimerkissä oletetaan, että sovellus käsittelee osoitetietueita osoitekirja. Näyte osoitekirja asiakirja näyttää tältä:
John Smith 250 18th Ave SE Rochester MN 55902 Bill Morris 1234 Center Lane NW St.Paul MN 55123
Sovellus (mahdollisesti, vaikkakaan ei välttämättä, servlet) säilyttää osoitekirja muistissa DOM-muodossa Asiakirja esine. Kun käyttäjä vaihtaa osoitetta, sovelluksen käyttöliittymä lähettää sille vain päivitetyn elementti.
elementtiä käytetään yksilöimään osoite; se toimii pääavaimena. Tällä ei olisi paljon järkeä todelliselle sovellukselle, mutta teemme sen täällä pitämään asiat yksinkertaisina.
Meidän on nyt kirjoitettava Java-koodi, joka auttaa meitä tunnistamaan lähdepuun elementti, joka on korvattava päivitetyllä elementillä. findAddress () alla oleva menetelmä osoittaa, kuinka se voidaan saavuttaa. Huomaa, että otoksen pitämiseksi lyhyenä olemme jättäneet asianmukaisen virheenkäsittelyn ulkopuolelle.
public Node findAddress (String name, Document source) {Element root = source.getDocumentElement (); NodeList nl = root.getChildNodes (); // iteroi kaikki osoitesolmut ja etsi se, jolla on oikea vastaanottaja (int i = 0; iYllä oleva koodi voidaan todennäköisesti optimoida, mutta on ilmeistä, että iterointi DOM-puun yli voi olla tylsää ja virhealtista. Katsotaan nyt, kuinka kohdesolmu voidaan sijoittaa yksinkertaisen XPath-käskyn avulla. Lausunto voi näyttää tältä:
// osoite [lapsi :: vastaanottaja [teksti () = 'Jim Smith']]
Voimme nyt kirjoittaa edellisen menetelmän uudelleen. Tällä kertaa käytämme XPath-käskyä haluamasi solmun löytämiseen:
public Node findAddress (String name, Document source) heittää Exception {// täytyy luoda uudelleen muutama auttajaobjekti XMLParserLiaison xpathSupport = new XMLParserLiaisonDefault (); XPathProcessor xpathParser = uusi XPathProcessorImpl (xpathSupport); PrefixResolver prefixResolver = new PrefixResolverDefault (source.getDocumentElement ()); // luo XPath ja alusta se XPath xp = new XPath (); Merkkijono xpString = "// osoite [lapsi :: vastaanottaja [teksti () = '" + nimi + "']]"; xpathParser.initXPath (xp, xpString, prefixResolver); // suorita nyt XPath select -lauseke XObject list = xp.execute (xpathSupport, source.getDocumentElement (), prefixResolver); // palauta tuloksena oleva solmu return list.nodeset (). item (0); } Yllä oleva koodi ei ehkä näytä paljon paremmalta kuin edellinen kokeilu, mutta suurin osa tämän menetelmän sisällöstä voitaisiin kapseloida auttajaluokkaan. Ainoa osa, joka muuttuu jatkuvasti, on varsinainen XPath-lauseke ja kohdesolmu.
Tämän avulla voimme luoda XPathHelper luokka, joka näyttää tältä:
tuo org.w3c.dom. *; tuo org.xml.sax. *; tuo org.apache.xalan.xpath. *; tuo org.apache.xalan.xpath.xml. *; public class XPathHelper {XMLParserLiaison xpathSupport = null; XPathProcessor xpathParser = null; PrefixResolver prefixResolver = null; XPathHelper () {xpathSupport = uusi XMLParserLiaisonDefault (); xpathParser = uusi XPathProcessorImpl (xpathSupport); } public NodeList processXPath (String xpath, Node target) thrws SAXException {prefixResolver = new PrefixResolverDefault (kohde); // luo XPath ja alusta se XPath xp = new XPath (); xpathParser.initXPath (xp, xpath, prefixResolver); // suorita nyt XPath select -lauseke XObject list = xp.execute (xpathSupport, target, prefixResolver); // palauta tuloksena oleva solmu paluulista.nodeset (); }} Kun olemme luoneet auttajaluokan, voimme kirjoittaa etsintamenetelmämme uudelleen, mikä on nyt hyvin lyhyt:
public Node findAddress (String name, Document source) heittää poikkeuksen {XPathHelper xpathHelper = new XPathHelper (); NodeList nl = xpathHelper.processXPath ("// osoite [lapsi :: vastaanottaja [teksti () = '" + nimi + "']]], lähde.getDocumentElement ()); return nl.item (0); } Helper-luokkaa voidaan nyt käyttää aina, kun solmu tai solmujoukko on sijoitettava tiettyyn XML-dokumenttiin. Varsinainen XPath-käsky voidaan jopa ladata ulkoisesta lähteestä, jotta muutokset voidaan tehdä lennossa, jos lähdeasiakirjan rakenne muuttuu. Tässä tapauksessa uudelleen kääntämistä ei tarvita.
Käsittele XML-asiakirjoja XSL-tyylitaulukoilla
Joissakin tapauksissa on järkevää ulkoistaa XML-asiakirjan koko käsittely ulkoiseen XSL-tyylitaulukkoon, joka on joiltakin osin samanlainen kuin edellisessä osassa kuvattu XPath-käyttö. XSL-tyylitaulukoiden avulla voit luoda tulosdokumentin valitsemalla solmut syöttöasiakirjasta ja yhdistämällä niiden sisällön tyylitaulukon sisältöön mallisääntöjen perusteella.
Jos sovellus muuttaa XML-asiakirjan rakennetta ja sisältöä ja tuottaa uuden asiakirjan, voi olla parempi ja helpompaa käyttää tyylejä tyylitaulukon kanssa kuin kirjoittaa sama työ suorittava Java-ohjelma. Tyylitaulukko on todennäköisesti tallennettu ulkoiseen tiedostoon, jolloin voit muuttaa sitä lennossa tarvitsematta kääntää uudelleen.
Voisimme esimerkiksi suorittaa prosessin osoitekirja näyte luomalla tyylitaulukko, joka yhdistää välimuistissa olevan version osoitekirja päivitetyn kanssa, mikä luo uuden asiakirjan päivityksineen.
Tässä on esimerkki tällaisesta tyylitaulukosta:
//mymachine.com/changed.xml
