1.1. fejezet, JSP/JSF és XML/XSLT integráció, a két világ legjobb dolgai

Bevezető

Ez a fejezet bemutatja hogyan lett a JSF 1.0 és JSP 2.0 a Java servlet technológiának a kezdetektől fogva logikus fejlődésének eredménye. A mérföldkövek, mint a JSP 1.1, a Strust 1.0 és a JSTL 1.0, a szerver oldali Java technológiába fokozatosan beolvasztott sok sikeres módszert a valós élet fejlesztési gyakorlatából. Ezek után bemutatja hogy a Model 2X bevezetése, a JSP technológia és az XML feldolgozás kombinációja folytatása ennek a fejlődésnek, és növeli a megjelenítési réteg rugalmasságát.

A fejezet jobb megértését segíti, ha bepillantásunk van a JSP alapjaiba, az XML és Web alkalmazások architektúrájába.

A Java servlet az alapja mindegyik technológiának. A servlet specifikáció meghatározza hogy a kiszolgáló alkalmazások hogyan vannak csomagolva, hogyan szolgáltatnak adatot, meghatározott szerver oldali komponenskészlettel hogyan állítanak elő dinamikus tartalmat..

A JavaServer Pages (JSP) a servlet technológiára épül, és template megközelítésben generál olyan szöveges tartalmat, mint például a HTML.

A JavaServer Pages Standard Tag Library (JSTL) egy halmaza az alap JSP eseményeknek, másként tag-oknak, amelyek egyszerűsítik a JSP oldalak fejlesztését. JSP lap fejlesztők összetett logikákat gyártanak az oldalakba segítségével Java vagy más scripting nyelv használata nélkül.

A JavaServer Faces bővíthető, komponens alapú, eszközbarát server oldali UI keretrendszer, ami szépen egyesíti a JSP és JSTL technológiákat.

Java servlet

A JSP megvalósítás előtti időkben a szerver oldali Java alkalmazás generálta a HTML kódot, a Java osztályba égetett, html tagokat előállító függvények segítségével. Ilyen eszközre példát láthatunk más nyelvekben is, mint például s sok helyen alkalmazott szerver oldali php script nyelv PEAR csomagjai közül a HTML_QuickForm. Ennek a módszernek a hátránya, hogy minden egyes módosítás után a Java kódot újra kell fordítani, újra csomagolni és szolgálatba beállítani. Sok oldal statikus, nem generált szöveget tartalmaz, ami módosíthatónak kell lennie, és kisebb mennyiségű a dinamikusan generált tartalom benne. Éppen ezért a valós életben erre a problémára a template alapú mechanizmust alkalmazzák. Ez a módszer sokkal természetesebben kezeli a statikus szövegeket és a dinamikus tartalmat. A Java világban a legtöbbször alkalmazott template rendszer így lett a JSP.

JSP mint template

A JSP korai időszakában a HTML kód és a Java kód egybe épült, ezt nevezték JSP oldalnak. Egy JSP motor betöltötte és lefordította a JSP oldalt futás időben. Ezzel a fejlesztési munka egyszerűbb lett. Mellesleg nem volt szükség Java kódra a statikus tartalom előállítására, csal a dinamikus tartalomhoz kellett, amit scriptlet -ekbe zártak. A nyelvek keveredése távolról sem olyan jól olvasható, vagyis eltántorítja a Java-hoz nem értő fejlesztőt a nyelv megismerésétől, és megnehezíti a feladatok és szerepek elkülönítését a fejlesztés során. Ebből a modellből hiányzik az üzleti logika és a megjelenítési logika különválasztása. A JSP 1.1 fejlesztése 1999 novemberében fejeződött be, és jelentős fejlődés volt, azonban azóta nagyjából nevezhetjük nemlétezőnek, annak ellenére hogy az ilyen stílusú oldalak továbbra is számottevőek. A JSP hibáinak kiküszöbölésére szükségessé vált egy keretrendszer kialakítása JSP alapokon.

Strust és MVC

A Strust és az MVC infrastruktúrája az első ilyen keretrendszer, ami megcélozta javítani ezeket a hiányosságokat. Tag könyvtárat biztosít a feltételek, iterátorok és adatkiválasztásokhoz a JSP oldal olvashatóságának növelésére. A bean és a logic tag könyvtárakat használja erre. Az MVC (Model/View/Control) architektúrájába az üzleti logika és a megjelenítési logikát választja szét.

A Strust-ban az MVC architektúra dolgozik az oldal alapokon. Hibrid architektúrán alapul, amit Model 2-nek neveztek el, jellemezve ezzel a servlet és a JSP lap együttműködését.

Az EL mellett a JSP 2.0 a következő új lehetőségekkel bír:

• Expression Language API, egy tag könyvtár, ami egyszerűen kezeli a JSP 2.0 megvalósítást

• Új lehetőségek, melyekkel megvalósítható egyedi eseménykezelés:egyszerűsített Java API-val készíthető egyedi tag könyvtárak, JSP eseménykezelők írhatók tag fájlokba, Java osztályok írása, fordítása és csomagolása helyett.

• Bővített konfigurálhatóság: egyszerűvé vált tag könyvtárak kikapcsolása egy lapon vagy egy egész alkalmazáson belül

A JSTL és EL párosnak további előnyöket is tulajdonítottak:

• Következetesség az XML és HTML terén: a generált oldalak nem egyszerűen csak jobban olvashatók, de jobban kezelhetők is a fejlesztői eszközökkel. Például grafikai eszközök érzékelni vagy beszúrni is képesek egy iterátor tagot, ami jóval összetettebb, ha Java kódot is tartalmaz.

• Nyelvi következetesség: az EL a látókörét kifejezésekre korlátozza. Tag könyvtáraknak jól meghatározott halmazú eseményei vannak. Ez előnyt jelent, mivel a Java arra csábítja a weblap fejlesztőt, hogy megbontsa a az MVC modellt, és üzleti logikát írjon a JSP oldalba.fejlesztőt, hogy megbontsa a az MVC modellt, és üzleti logikát írjon a JSP oldalba.

A JSP legutolsó fejlesztése világosan támogatta a scriptlet mentes fejlesztést, és fordulópontot jelent a JSP fejlesztésében. Ha a fejlesztő követi az ajánlott legjobb praktikákat, a JSP lap átalakul egy szegényes HTML és scriptlet „tag-levesből” egy továbbra is szegényes névtér-kész XML oldallá. Az eredmény egy következetesebb szintaktika, a fejlesztő kevesebb munkával, fejlesztőeszközök használata, és még jobb felügyelet az üzleti és megjelenési logika szétválasztása felett.

A JSF ígérete

Egyszerű oldalakhoz, melyek korlátozott felhasználói párbeszédet igényelnek elegendőnek tűnk a JSP 2.0, a JSTL és az MVC. Azonban összetett web alapú felhasználói felületek kialakítása továbbra is sok fejlesztői munkát jelentett. Kibontani a kérés paramétereit, ellenőrizni és feldolgozni azokat, visszaképezni HTML vezérlőkbe, stb. A megvalósítás fárasztó és hibaforrásban bővelkedő.

Desktop alkalmazások, mint a Swing, már régóta használják a hierarchikus komponens alapú MVC keretrendszert, csillapítva a felhasználói felület fejlesztésének nehézségét. Az ilyen keretrendszerek a felhasználói felület elemeit komponensekbe teszik ki, tárolt/tároló szervezésű kapcsolatban (egy képernyőn több panel, egy panelen többféle beviteli mező). Ez a megoldás arra vezeti a fejlesztőket, hogy grafikus eszközöket használjanak a felhasználói felület kialakításához. Lehetővé válik a komponensek újra felhasználása, és a szerepkörök jobb szétválasztása.

Web alkalmazások általában a vezérlők korlátozott halmaza áll rendelkezésre, korlátozott interaktivitással, de egyéb funkciónalitásban nem különböznek a desktop alkalmazásoktól. Természetes, hogy megpróbálták adaptálni a desktop alkalmazásnál használt modellt a szerver oldali fejlesztésekbe. Ez a megoldás, amit választott a JSF szakértői csapat. Mivel a desktop alkalmazások mégis valamennyire különböznek a szerver oldali alkalmazásoktól, új modellt dolgoztak ki, és nem használták a Swing API-t és modelljét.

Mint a Strust, a JSF is az MVC architektúrát követi. Egy vezérlő servlet-et nyújt, és renderelőkkel, más néven leképezőkkel megengedi a nézet különválasztását, és egy modellt, ami komponens osztályokat szolgáltat, és egy esemény alapú mechanizmust. A JSF-el az MVC architektúra a komponensek szintjén dolgozik egyenként. A JSF komponensek összeszerkesztéséhez Java kód írása helyett, mint ahogy az történik a Swing esetén, a JSP fájlokba XML jelölésekkel határozhatja meg a fejlesztő a komponensek összefüggéseit. A JSF és a JSP kapcsolata opcionális, de remélték, hogy ez less a legjobban preferált technika. Például a JSF általános komponensek halmazát szállítja a Standard JSF Tag Library-ban. Ez lehetővé teszi a Java-t „nem folyékonyan beszélő” számára, hogy kiküszöbölje az összetett felhasználói felületek fejlesztésekor a kódolást, mivel könnyebbé teszi a grafikus eszközök alkalmazását. Ha JSP-vel használják, a JSF tekinthető a Model 2 architektúrának, mivel vezérlő servletet és JSP lapot használ.

JSF újra felhasználható, szerepkört szétválasztó, egyszerű eszközhasználatot ígér, lejjebb viszi a lécet, amit át kell ugrani, és lerövidíti az időt, amit a fejlesztésre kell fordítani ha szerver oldali felhasználói felületet gyárt a fejlesztő. A következőkben a JSF fejlesztés jellegzetes leképező szemléletét taglalom. A felhasználói képernyő leképezése azt jelenti, hogy hogyan tesszük láthatóvá a felhasználó számára az adatot. A szerver oldali programozásban ez többnyire HTML, CSS és JavaScript összetevőkből áll. Gyakorlatilag karakterfolyamot küldünk a böngészőnek.

A JSF hierarchia leképezése egy rekurzív eljárás, amelyben minden Java-ban írt komponensnek lehetősége van magát leképezni. A JSF egy pár lehetőséget ad:

• Leképezés közvetlenül a komponensektől: a kód módosítása nélkül nem áll módunkba módosítani a leképezés stílusát

• Külön álló osztályoknak delegáljuk a leképezést, melyeket RenderKit-nek neveznek: a komponens kódjának módosítása mellőzhető, de a stílus módosítása továbbra is a a RenderKit számára készült Java kód változtatását igényli.

Mindkét módszer nem template alapú, mint a servlet-ek napjaiban volt, szükséges a nem szabványosított megoldás, vagy HTML generálás Java kódból. A leképezők, amelyeket a korai időszakában szállított a JSF, ezt az utat valósították meg. Komponensfejlesztésbe bonyolódtunk, akármikor módosítottunk a leképezésen.

HTML-nek van egy társa, nevezetesen a CSS, kifejezetten a stílus tervezésére fejlesztették. A CSS megoldhatja a JSF leképezés korlátait, a Standart User Interface RenderKit -hez elérhető. Például egy gomb háttérszíne megváltoztatható egy CSS képes böngészőben. A CSS használatával a stílusozás problémájának egy része megoldódott, anélkül hogy megváltoztatnánk a leképezés kódját. Ennek a megközelítésnek a következő korlátai vannak:

• A stílusozásnak nem minden oldalát lehet megoldani CSS-el

• Nem minden böngésző támogatja a CSS-t

Az első pont illusztrálására képzeljük el, hogy elhatározzuk a fejlesztés után, hogy egy táblázatban minden második sor színét meg szeretnénk változtatni. A második pont illusztrálására pedig, hogy CSS támogatás nélküli böngészőben általánosan elterjedt trükk a keret megrajzolásához, hogy beágyazzák a táblát egy külső táblázatba. Hogy megoldjuk ezt a feladatot JSTL-el, minden JSP lapon meg kell dupláznunk a kódot. Ha a fejlesztők sokszor módosítják a használt stílust a fejlesztés során, például módosítási igény kapcsán, a módosítás ismételten elvégezheti az egész alkalmazásban. JSF-el egy egyszerű komponens megalkotásával megoldhatja, de ez azt jelenti, hogy összetett Java kódot kell írnia. Egyik technológia sem segített megvalósítani ezt a típusú
stílusozás technikát. Két megoldás lehetséges:

• JSF leképezőket valósítanak meg template fájlokban, hasonlóan mint a JSP 2.0 tag fájlok. Sem a JSF, sem a JSP nem támogat ilyen modellt, és valószínűtlen hogy a JSF leképező jelentősen változni fog az 1.0-előtt. (A JSF 1.0 technológia 2004 márciusi megjelenése óta eltelt két év alatt eljutott az 1.2-es verzióig. Az 1.1 hibajavítás volt, az 1.2 2006 május 11.-én adták ki, amiben már szerepel egy ideiglenes megoldás a JSP template kezelése)

• XML feldolgozást alkalmazunk, ezt nevezik Model2X-nek

Model2X

A legfontosabb aspektusa a Model2X-nek az XML transzformációs nyelv, a XSLT használata servlet és JSP viszonylatban. A servlet és JSP kimenetek többnyire közvetlenül a böngészőbe kerülnek. A Model2X-ben a kimenet átmegy még egy lépcsőn, az XML transzformáción, mielőtt a böngészőbe érne. Hogy sorba megértsük mi történik, fontos hogy megnézzük a JSP és az XML világ kapcsolatát.

A JSP arra lett tervezve, hogy bármely szöveg formátumot produkálni tudjon, úgy mint a HTML, a CVS, a CSS és a JavaScript. Ebből kifolyólag képes XML-t dokumentumot is generálni. A bökkenő csak az, hogy a JSP nem kényszerít jól formázott XML kimenet készítésére. XML dokumentum generálásakor a következő elővigyázatosságok szükségesek:

• Minden template szövegnek a JSP lapon az XML szabványnak megfelelően helyesen formázottnak kell lennie

• a tag könyvtárak szintén helyesen formázott kimenetet kell produkáljanak

A Sun, hogy megkülönböztesse a helyesen formázott JSP lapot az egyszerű JSP laptól, JSP dokumentumnak nevezi. Az olyan JSP konstrukciókat, mint a <% %> és <%@ %> le kell cserél XML kompatibilisre. Ilyenek a <jsp:directive.include> és <jsp:scriptlet>. Tag könyvtárak gyakran generálnak HTML-t. Ezt generálnak a Strust és az Standard JSF könyvtárak is. Ilyen könyvtárak használatakor módosítani kell azokat, hogy XML kimenetet produkáljanak. A JSF-el egyszerűen írhatunk XML leképezést, kicserélve a HTML leképezőt. Ha szeretnénk meggyőződni, hogy a generált kód XML kompatibilis, át kell küldenünk egy feldolgozón, ami ugyan nem kötelező, de hasznos.

A transzformáció kimenete lehet XML, HTML, vagy bármi szöveges formátum. Az XSLT 1.0 verzióját 1999 novemberében adták ki, ugyan abban az időben, mikor a JSP 1.1-et adták ki. W3C szabvány, és a 2.0-ás változatát 2007 január 23.-án fogadták el. Utóbbi az XPath 2.0-ra épül, ami az új változata az XML kifejezés nyelvnek, sokkal következetesebb, és jóval több funkciót foglal magába, mint az 1.0 kiadás, úgy mint a csoportosítás és a felhasználó definiált funkciók. Egy XSLT programot stíluslapnak hívnak. Az XSLT ezért az a nyelv, ami pontosan arra lett tervezve, ami megcélozza a fentebb megfogalmazódott problémát.

JSF és a Model2X

Most megnézzük, hogyan működik együtt a JSP és a JSF valamint az XSLT. A következő JSP részlet JSF kódot használ az aktuális JSF számkitalálós referencia implementációjából.

<%@ taglib uri='http://java.sun.com/j2ee/html_basic/' prefix='faces'%>
 
  <title>Hello</title>
    <h1>Hello</h1>
    <faces:usefaces>
      <faces:form id="helloForm" formname="helloForm">
        <table>
          <tbody><tr>
            <td>
              <faces:textentry_input id="userNo" modelreference="UserNumberBean.userNumber">
            </faces:textentry_input><br type="_moz" /></td>
            <td>
              <faces:command_button id="submit" commandname="submit"><p>&nbsp;</p></faces:command_button><br type="_moz" /></td>
          </tr>
        </tbody></table>
        <faces:validation_message componentid="userNo">
      </faces:validation_message>
    </faces:form>
  </faces:usefaces>
<p>
Egy XML leképezővel készült lehetséges kimenete ennek a kódnak a következő:
</p>
<blockcode language="HTML">
 
  <title>Hello</title>
    <h1>Hello</h1>
    <form method="post" action="/guessNumber/faces/greeting.jsp">
      <table>
        <tbody><tr>
          <td>
            <input name="/helloForm/userNo" type="text" />
          </td>
          <td>
            <input name="submit" value="submit" type="submit" />
          </td>
        </tr>
      </tbody></table>
    </form>
 

Ha a JSP kimenetét feldolgozzuk egy XSLT-be, könnyen alkalmazható rá bármilyen stílus. Például leképezni minden küldés gombot piros színűre igen egyszerű:

<!-- Find all input elements with a "submit" type attribute -->
<xsl:template match="input[@type = 'submit']">
  <!-- Copy the element found -->
  <input />
    <!-- Copy all existing attributes -->
    <xsl:copy-of select="@*">
    <!-- Add a "style" attribute -->
    <xsl:attribute name="style">color: red</xsl:attribute>
 
</xsl:copy-of>
</xsl:template>
<p>
Az XSLT-nek nem korlátozódik a JSF által generált lapon való manipulációra. Egyszerűen kialakítható vele egy egész oldal képe:
</p>
<blockcode language="xml">
<!-- Match the body element -->
<xsl:template match="body">
  <!-- Copy the element found and set a background color -->
 
    <table border="0">
      <!-- Create a header row -->
      <tbody><tr>
        <td>Header</td>
      </tr>
      <tr>
        <td>
          <!-- Copy the actual body -->
          <xsl:apply-templates>
        </xsl:apply-templates><br type="_moz" /></td>
      </tr>
    </tbody></table>
  </xsl:template>

A Model2X előnyei a következők:

• Jobb modularitás és rugalmasság: a stílusozás központosítható. Egy stíluslap megírható úgy, hogy alkalmazható az összes lapjára egy alkalmazásnak. A kinézet és az érzet újrahasználható az alkalmazások között. Futásidőben változtatható a kinézete egy alkalmazásnak

• Gyors körbeforgás: nem szükséges kódot módosítani, így a JSF kódot elég egyszer megírni, és többet nem kell hozzányúlni. XSLT lap újratölthető míg az alkalmazás fut, nem szükséges újraindítani, és a változás mindig frissen látható.

• Szemléletes erő: az XSLT egy nyelv, kifejezetten az XML és következésképpen az XHTML-re adaptálva. A manipulációk lehetősége végtelen. Az XPath egy kifejező nyelv, sokkal inkább kialakult, mint a JSP 2.0 EL-je vagy a JSTL.

• Szabványos: az XSLT a W3C szabványa, és az adaptációja széleskörű. Ez azt jelenti, hogy töméntelen dokumentáció és eszköz áll a fejlesztő rendelkezésére, több gyártótól, beleértve a különböző teljesítményű Java megvalósításokat. Az XSLT-t támogatja a Java API for XML Processing (JAXP). A Xalan, egy elterjedt XSLT feldolgozó, a J2SE 1.4-be lett beépítve, és minden nagyobb alkalmazás kiszolgálót ellátnak XSLT támogatással.

• Csővezeték technika: XSLT alkalmazható saját kimenetére is.

• Járatosság: sok JSLT konstrukció hasonló az XSLT konstrukciókhoz. Az XSLT-t könnyen megtanulja az, aki járatos az JSLT-ben.

Hátrányai:

• További feldolgozás: a Model2X bevezet egy következő lépcsőt a megjelenítési logika futásába. Legtöbbször azonban a többletterhelés kicsi és az üzemeltetési flexibilitás igénye nagyobb.

• Szükséges újat tanulni: az XSLT-t meg kell tanulni. Azonban könnyen tanulható, ritkán szokott ez problémát okozni

• Fegyelem: mivel a JSP nem ellenőrzi az XML megfelelőséget, a fejlesztő feladata erre ügyelni.

A csővezeték technika előnyei:

• Lokalizáció: egyik módja a nyelvi lokalizációnak, másik a kinézeti lokalizációnak. Egy arab oldalon a menü jobb oldalon szerepel többnyire, míg más nyelveket lehet bal oldalon.

• Több böngésző támogatása: egy stíluslap készíthető az utoljára kiadott CSS verziót támogató böngészőbe, míg egy másik a CSS-t nem támogató számára.

• Több eszköz támogatása: egy külön cső képezhet kimenetet különböző eszközökre, mint például a PDA és a mobiltelefon

• Beemelhetőség: készíthető a JSP lapon kívül is lap, külön stíluslap képezhető a fejlécnek, a láblécnek, a lap törzsének, és ezeket hozzá lehet tenni a laphoz egy csővezetékben.

XSLT a böngészőben

A modern böngészők, mint például az Internet Explorer 6 és ennek újabb változatai, valamint a Mozilla Firefox 1.5 és újabb változatai szintén tartalmazzák az XSLT manipulációhoz szükséges eszközöket. Olyannyira, hogy az AJAX segítségével letöltött XML adatot HTML DOM fává átalakítva beemelhetjük a megjelenített oldalba. Ez a Web 2.0-ás módszer lehetővé teszi a DOM implementációk közötti különbségek áthidalását, az annyira rettegett JavaScript inkompatibilitás részleges kikerülését, böngésző oldali sablonok alkalmazását (példa). Azonban ne tekintsük egyetlen üdvöskének, mert az XSLT kompatibilitása sem tökéletes. Például az Opera 9 sem támogat bizonyos függvényeket és a szabvány folyamatosan bővül új funkciókkal.

XULRunner: minden program magja

A Mozilla csapat kifejlesztett egy kliens oldali alkalmazást az XULRunner nevű projektben, ami tartalmazza a Firefox és Thunderbird programokban alkalmazott komponenseket, XML/XSLT JavaScript futtatására alkalmas, SVG és XUL feldolgozásra képes. Segítségével a böngészőkben megjelenített tartalom mint különálló program használható. Az eszköz könnyen konfigurálható, jól kezelhető, érdemes kipróbálni.

Összegzés

A Java, mint szerver oldali programozás hosszú utat járt be, sokat tapasztalt fejlesztők munkája fut a töméntelen mennyiségű kiszolgálón. Mint minden fejlődő szerver oldali programozási nyelv, bejárta a fejlődés hosszú, rögös útját, és többször megérkezett egy olyan mérföldkőhöz, ami tökéletesnek látszott, ám a fejlesztők mindig találtak és találni fognak hibákat és új megvalósítandó célt. Az irányvonal, amit minden esetben érdemes követni, a feladat és szerepkör kontúr kialakítása, a csapatmunka elősegítése. Ez mutatkozik meg a Java fejlődésében, és ennek eredménye az XML és XSLT technológia megjelenése. Amennyiben egyszerű, könnyen kezelhető weblapot kíván létrehozni a fejlesztő, és kevés dinamikus tartalommal látja el, elegendő a fejlődési szakasz korábbi lépcsőfokain megállnia. A következő lépcsőt csak akkor érdemes meglépni, ha összetett, dinamikus portált fejleszt. Ez a lépcső az XML/XSLT felé vezet, és a W3C támogatásával meg is marad stabil lépcsőfoknak. A böngészőbe implementálás jelzi ezt az akaratot, és a szerver oldalon az adattárházak szolgáltatásai is erre fognak fejlődni.

Források:

Angol eredeti szöveg:
http://www.theserverside.com/tt/knowledgecenter-is/knowledgecenter-is.tss?l=BestBothWorlds

JSF wiki:
http://en.wikipedia.org/wiki/JavaServer_Faces

JSF teljesítménynövelés JSP dump-al
http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html

XULRunner
http://developer.mozilla.org/en/docs/XULRunner:What_XULRunner_Provides

EclipseXUL feature

http://eclipsexul.sourceforge.net

XSLT wiki:
http://en.wikipedia.org/wiki/Xslt

Transzformáció XML és XSLT segítségével:
http://developer.mozilla.org/en/docs/Transforming_XML_with_XSLT

A Mozilla JavaScript interfésze XSLT manipulációhoz:
http://developer.mozilla.org/en/docs/Using_the_Mozilla_JavaScript_interface_to_XSL_Transformations