PHP környezetben. Miskolci Egyetem

Szakdolgozat

Miskolci Egyetem

MVC alapú kód-generáló Javascript/PHP környezetben

Készítette:

Burunkai Dániel 4. Évfolyam Gépész - Programtervez® Informatikus

Témavezet®:

Dr. Kovács László Konzulens:

Dr. Házy Attila

Miskolc, 2012

Miskolci Egyetem

Gépészmérnöki és Informatikai Kar Alkalmazott Matematikai Tanszék

Szám:

Szakdolgozat Feladat

Burunkai Dániel (LAHKSP) programtervez® informatikus jelölt részére. A szakdolgozat tárgyköre: Web-fejlesztés A szakdolgozat címe: MVC alapú kód-generáló Javascript/PHP környezetben A feladat részletezése: MVC modell bemutatása xForms áttekintés Javascript/Jquery/AJAX technikák elemzése PHP nyelv ismertetése Kódgeneráló algoritmus rendszerterve Implementáció, tervezés

Témavezet®(k): Dr. Kovács László, egyetemi docens Konzulens(ek): Dr. Házy Attila, egyetemi docens A feladat kiadásának ideje: 2011. szeptember 29.

................................. szakfelel®s

1.

szükséges (módosítás külön lapon) A szakdolgozat feladat módosítása nem szükséges

...................... dátum 2. A feladat kidolgozását ellen®riztem: témavezet® (dátum, aláírás): .............. .............. .............. 3. A szakdolgozat beadható: ...................... dátum

........................... témavezet®(k) konzulens (dátum, aláírás): ............. ............. ............. ........................... témavezet®(k)

4. A szakdolgozat . . . . . . . . . . . . . . . . . . . szövegoldalt . . . . . . . . . . . . . . . . . . . program protokollt (listát, felhasználói leírást) . . . . . . . . . . . . . . . . . . . elektronikus adathordozót (részletezve) ................... . . . . . . . . . . . . . . . . . . . egyéb mellékletet (részletezve) ................... tartalmaz. ...................... ........................... dátum témavezet®(k) 5. bocsátható A szakdolgozat bírálatra nem bocsátható A bíráló neve: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...................... ........................... dátum szakfelel®s 6. A szakdolgozat osztályzata a témavezet® javaslata: ................ a bíráló javaslata: ................ a szakdolgozat végleges eredménye: . . . . . . . . . . . . . . . . Miskolc, . . . . . . . . . . . . . . . . . . . . . . . .

................................. a Záróvizsga Bizottság Elnöke

Tartalomjegyzék

1. Bevezetés 1.1. xForms és PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Téma elméleti kifejtése 2.1. Böngész® alapú kliensek története . . . . . . 2.2. DOM . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Objektum modell . . . . . . . . . . . 2.3. Szoftverfejlesztési trendek . . . . . . . . . . 2.4. XForms kialakulása, jellemzése . . . . . . . . 2.4.1. XPath és az XSLT-vel való kapcsolat 2.4.2. XForms el®nyei és hátrányai . . . . . 2.4.3. XForms dokumentum megnyitása . . 2.5. MVC . . . . . . . . . . . . . . . . . . . . . . 2.5.1. MVC az XForms-ban . . . . . . . . .

6 6

. . . . . . . . . .

7 7 9 9 12 13 14 15 16 17 18

. . . . . . . . . . . . . . . . . . . .

19 19 19 20 22 23 25 25 26 28 28 32 33 36 36 38 40 40 44 46 48

4. Összefoglalás 4.0.1. English Summary . . . . . . . . . . . . . . . . . . . . . . . . . .

53 54

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

3. Fejleszt®i dokumentáció 3.1. Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Modell az XForms-ban . . . . . . . . . . . . . . . . . . 3.1.2. Modell elem leképzése és beolvasása . . . . . . . . . . . 3.2. XForms view elemek HTML-re alakítása . . . . . . . . . . . . 3.2.1. Az átalakítás motorja . . . . . . . . . . . . . . . . . . . 3.2.2. Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3. Secret . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4. Select1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5. Textarea . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6. Egyéb view megjelenít®k, továbbfejlesztési lehet®ségek 3.3. Mintarendszer követelmények . . . . . . . . . . . . . . . . . . 3.4. Mintarendszer fejleszt®i környezet . . . . . . . . . . . . . . . . 3.5. Rendszerterv, interfész . . . . . . . . . . . . . . . . . . . . . . 3.5.1. M¶ködési diagram . . . . . . . . . . . . . . . . . . . . 3.5.2. Példány betöltése . . . . . . . . . . . . . . . . . . . . . 3.5.3. Modell módosítása . . . . . . . . . . . . . . . . . . . . 3.5.4. Példányok kezelése . . . . . . . . . . . . . . . . . . . . 3.5.5. Controller: Export . . . . . . . . . . . . . . . . . . . . 3.5.6. Controller: Import . . . . . . . . . . . . . . . . . . . . 3.6. Tesztelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Irodalomjegyzék

55

Adathordozó használati útmutató

56

1. fejezet Bevezetés

A '80-as években a fejlesztés még karakteren felületen m¶ködött, a programok monolit rendszer¶ek voltak, ahol a programozók nehezen tudtak összedolgozni. Az elkészült programok használatához szintén szaktudás kellett, gyakran programozói ismereteket igényelt. A kés®bbiekben megjelent grakus felhasználói felülettel rendelkez® operációs rendszerek törtek utat afelé, hogy megreformálják az eddigi programozás szemléletet. A grakai szemléltetés tette lehet®vé a GUI vezérl®k elterjedését, melyekhez eseményt lehetett társítani, és a háttérben valós id®ben lehetett az adatokkal dolgozni. A grakus szemléltetéssel egy újfalja felhasználói felület jelent meg. Az új felhasználói környezetben a fejlesztés hatékonysága jelent®sen növelhet®, ha logikailag három részre bontjuk a kódot:van egy modell rész, ahol az aktuális adatokat tároljuk le; egy nézet rész, amit a felhasználó látt és itt kerül interakcióba a programmal; valamint a vezérl®i rész, ami az adatok küldésér®l gondoskodik. Ezt a hármasságot hívjuk angol fordításból eredend®en MVC-nek, azaz model-view-controller szerkezet.

1.1. xForms és PHP

Szakdolgozatomban az MVC szemlélet¶ programozás bemutatására az xForms struktúrát fogom használni, mely egy XML formázású leírás internetes ¶rlapok leírására. Az xForms-ba látványosan elkülönül egymástól az MVC három alkotóeleme, mindegyik kapott külön szekciót. Az xForms szabvány viszont lassúsága miatt nem terjedt el az interneten, valamint sok helyen nem is volt szükség az xForms adta bonyolult lehet®ségekre. A szakdolgozatomba xForms leírást konvertálok át a ma is használatos HTML nyelvre. Az átalakítás során PHP-t használok, mely elemzi az xForms dokumentumot, létrehozza a View részt, és gondoskodik az adatok ki és bemásolásáról. A modell rész kezelését JavaScripttel, és a hozzá tartozó függvénykönyvtárakkal (jQuery és AJAX) oldom meg - feladatuk hogy a modell részt módosítsák amikor egy adatot viszünk fel. A használt két webes programnyelvvel viszonylag jól megoldható az xForms m¶ködésének szimulációja, habár teljesen azonos nem lehet vele, mivel kínál olyan eszközöket is, melyek nem találhatóak meg a HTML nyelvben. Az XML formáció jelen van mind a HTML nyelvben, mind az xForms-ban, így a konverzió során er®sen kihasználom a DOM szerkezeti fájukat, helyes felépítést feltételezve. Ezt a szerkezeti felépítést mind a PHP és mind a JavaScript támogatja. 6

2. fejezet Téma elméleti kifejtése

2.1. Böngész® alapú kliensek története

Annak érdekében, hogy az interneten szörfölhessünk, böngész®re van szükségünk. Manapság rengeteg ilyen program áll rendelkezésünkre, így például egy sovány, de gyors böngész® a Google által fejlesztett Chrome, vagy a még mindig gyenge lábakon álló Internet Explorer a Microsoft-tól, ami kiváló arra hogy meggy®z®dhessünk arról hogy weblapunk helyesen fog e megjelenni. Az XForms szemszögéb®l a Mozilla által kiadott böngész®k a legfontosabbak, mivel ez az alapítvány támogatja leginkább az XForms megjelenítését. Böngész®je a Firefox manapság is nagy teret hódít a piacon. Nem számít milyen böngész®t használunk a mai világban, a céljuk mindegyiknek a helyes megjelenítés, melyet immáron közel két évtizede fejlesztenek. Ezen fejezetben mutatom be hogyan értünk el a mai böngész®kig az 1991-ben megjelent WorldWideWebt®l. [1] A Tim Berners-Lee által fejlesztett WorldWideWeb (1991-) a legtöbb forrás alapján a legels® böngész®nek mondható ami valaha megjelent. A böngész® alap munkálatai még az 1980-as években kezd®dtek, a Commodore64 fénykorában. Hivatalosan 1991ben mutatták be, amikor már képes volt alapvet® stílus deníciókat megjeleníteni, és az egyetlen lehet®ség volt a web böngészésére. Már ebben a böngész®ben lehet®ség volt a navigációra, úgymint a "vissza" vagy az "el®re", valamint egyben szerkeszt®ként is szolgált. A WorldWideWeb-et a kés®bbekben Nexus névre keresztelték, hogy ne legyen zavaró hogy a technológia és a böngész® neve is ugyanaz. A világ els® mutass-és-klikkelj böngész®je az irodalom szerint a Mosaic volt, de a valódi megkülönböztetést már az Erwise (1992-) elérte. Négy Finn egyetemista fejlesztette a Helsinki Egyetemen az Unix és X Windows System operációs rendszer alá. F®bb újdonsága volt az oldalon való keresési funkció, valamint akár 12 weboldalt is meg tudott jeleníteni, és többet párhuzamosan tölteni. A ViolaWWW (1992 Május) megjegyzend® funkciója közé tartozott hogy több féle bet¶típus megjelenítésére is képes volt egy oldalon, valamint képes volt a látogatott oldalt egy másik ablakba mint pl. az el®zmények közé, mely szintén egy újítás volt. Navigáció tekintetébe megjelent a "home" gomb is, valamint egy online súgó, és a könyvjelz®k! VAX számítógépek közében az els® és legnépszer¶bb böngész® a MediasWWW (1992 November) volt, mely eredetileg szintén egy X Browser volt, de kés®bb átírták. Egy karakteres böngész® a Lynx (1992-93), mely a legnépszer¶bbé n®tte ki magát a terminálok körében. Mind a 7

2.1. Böngész® alapú kliensek története

mai napig elérhet® akár Vista 64 bites verzióra is. A HTML nyelv egyre elterjedtebb lett, és újabb verziók jelentek meg, így 1994-ben a 2.0-ás. Ekkortájt népszer¶ böngész® a Mosiac 1.0 (1993) több kompatibilitási hibába is ütközött, mely csak '95-re lettek javítva a 2.x verziókba, ami már a HTML 3 szabványból is, mint pl. a táblázatok és karakter stílusok. Megemlítend® böngész®k közé tartozik az Arena , mely a W3 számára a HTML 3 tesztelésére szolgált; a Cello, az els® Windows-ra is kiadott böngész®; az IBM WebExplorer, Netscape Navigator, ami a valaha elért legnagyobb piaci részesedést (90%) érte el és verziói mind a mai napig frissen tartják az új szabányokra. Nagy áttörést jelentett a JavaScript (eredeti nevén LiseScript), melyet a NetScape és a Sun közösen fejlesztett ki, mely a 2.0-ás verziója óta elérhet®ek. Eredetileg a böngész® Java nyelvéhez szánt kiegészít®, de mára már teljesen kettévált a két programozási nyelv. A Microsoft által fejlesztett Internet Explorer 1995-t®l volt elérhet® a Windows 95 operációs rendszerekre. A böngész® 3.0-ás verziója óta van támogatva a JavaScript nyelv is, mely JScript 1.0-ként volt elnevezve. A nyelvet a kés®bbiek folyamán f®ként a NetScape és az Internet Explorer támogatta különböz® verziószámmal és elnevezéssel, majd 2005-t®l a Firefox-ban is elérhet® lett. A CSS 1.0 stílusleíró nyelv 1996 decemberében jelent meg, és az Explorer az 5-ös verziója óta támogatja. A nyelv a HTML korlátait hivatott átlépni a megjelenítés terén, hogy egy egyszer¶en kezelhet®, mégis látványos megjelenést adjon a weblapoknak. Ma is létez® böngész®, az Opera 1996-ban jelent meg el®ször MultiTong Opera néven. Teljesen különálló módon fejl®dött a Natscape-t®l és az IE-t®l. A 2-es verziójában jelent meg a HTML3 többek közt videó-támogatással és magas fokú session kezeléssel, a 3-as verziójában a JavaScript, a 4-es verzióban a HTML 4 egyéb extrákkal, úgy mint az SSL 2,3 , CSS 1,2 , XML támogatás. 1995 és '96-ban újabb böngész®k láttak napvilágok, a népszer¶bbek közt található az '95-ös Grail, egy "hackelhet®" böngész®, ami Phyton-ban írodott (HTML2 és 3 támogatás), valamint az '96-os Arachne, Amaya, és Oracle PowerBrowser . Az Arachane egy grakus böngész® volt DOS rendszerek alá, méretét tekintve egy 1.44MB oppy lemezre is ráfért, mégis nagy tudású volt: framek, táblázatok, animációk,HTML 4, FTP támogatás, POP, SMTP és egyéb protokollok. A Seamonkey (1998) a mai Mozilla régi böngész®je, a Mozilla Application Suite része a levelez®klienssel, web fejleszt®vel és IRC klienssel együtt. 1996-ban jelent meg a Konqueror nyílt forrás kódú böngész®, JavaScript, Java applets, CSS, SSL és egyéb támogatással. Jelenleg is használatos Linux rendszereken. Mai nagy böngész®k egyike az els®ként 2003-ban kiadott, Apple által fejlesztett Safari melynek csupán 3-as verziója (2007) lett használható Windows-on. A mindenki által ismert Firefox 2004-ben jelent meg el®ször, egy er®sen testre szabható böngész®: az 1.0-ás verziója az alapvet® funkciók mellett tartalmazott beépített RSS támogatást, letölt® manager-t, valamint biztonságosabb böngészési módot lett lehet®vé a VBScript és ActiveX nem támogatása révén (melyek természetesen kiegészít®kkel engedélyezhet®ek voltak). 2-es verziója 2006-ban, a 3-as pedig 2008-ban jelent meg számos tejesítmény beli javítással, melyet a Gecko Engine 1.9 hajtott. Az IE után a 2. leggyakrabban használt böngész®vé vált, míg manapság az egyszer¶ségre és gyorsaságra kifaragott Google Chrome böngész® kezd el terjedni.

8

2.2. DOM

Az id®k során nemcsak a JavaScript, CSS, VBScript, stb. terjedt el, rengeteg olyan funkció létezik melyre egy böngész® jó ha fel van készítve - még ha szabvány alakjában nem is létezik (mint pl. a HTML5). Erre különféle online tesztek is vannak, így pl. az ACID3 teszt, mely ezeket a funkciókat vizsgálja hogy képes e a böngész® kezelni.

2.2. DOM

A DOM egy procedurális kezel®felület az XML dokumentumok tartalmának kezelésére. Nem csak az XML, de a HTML és XForms dokumentumok lekérdezésére, vizsgálására, törlésére és módosítására szolgál. A DOM (Document Object Model) tulajdonsága, hogy a kezel® felület a memóriában deríti fel a teljes dokumentumot egy fa reprezentáció formájában, és a rendelkezésre álló metódusok segítségével teszi ezt a tartalmat elérhet®vé/módosíthatóvá. Ez a kép, mely a memóriában szerepel, tetszés szerint kiírható kés®bb fájl-ba is. A fában minden egy objektumnak feleltethet® meg, így a szövegrészletek, elemek, és az elemek tulajdonságai is. A fa kezelése navigációval történik, tehát a feldolgozás során megjelenik egy feldolgozói pozíció, mely megmutatja hogy épp mely elemmel dolgozunk, és merre lehet tovább folytatni a navigációt. Ez a navigáció alapvet®en a szomszédos elemeket jelenti, valamint módosítás esetén az adott elem tulajdonságát/környezetét. A DOM kezelésére szolgál a DOM API, mely lehet®vé teszi az említett m¶veleteket a fában - mind a törlést, hozzáadás, módosítást és olvasást is. Ezt az API-t jelenleg a PHP5 beépített kezel®je fogja végrehajtani, mely teljes kör¶, viszonylag kényelmes hozzáférést biztosít a fa szerkezetéhez. A feladat egy olyan programkódot írni, melyben elvégezzük a fa módosítását a rendelkezésre álló metódusok segítségével.[2] Mint DOM API szabványt a W3C szervezet által lett kidolgozva 1998-ban. Kés®bb 2004-ben készült el a DOM 2-es szabvány, mely jelenleg is a legfrissebb. A szabvány a funciókat különböz® szintekre osztja: • 1-es szint: fa struktúra, valamint az alap-tartalom parancskészlete. Ez biztosít

lehet®séges a navigációra és a módosításra is,

• 2-es szint: névtér és eseménykezelés, • 3-as szint: az utak leírására szolgáló XPath, valamint a validáció. 2.2.1. Objektum modell

Az objektum modell a logikai szerkezet alapján meghatározott fa szerkezetre épül, melyet már implementáció-függ® elemmel egészítettek ki. A fában különféle csomópontokat különböztetünk meg, melyek közt szerepel a dokumentum maga, mely a teljes fát reprezentálja. Tartalmaz továbbá egy dokumentum séma leírást, mely a fa szerkezetének a megkötéseit (integritási szabályait) írja le. Ezen kívül a szokásos szöveg, megjegyzés, CDATA, elem hivatkozás és elem jellemz® csomópont is megtalálható. A DOM számára tehát minden egy-egy csomópontnak felel meg.

9

2.2. DOM

A beolvasott fából a DOM értelmez® és feldolgozó el®állítja a csomópontokból álló fát. Ezek közt tartalmazási reláció áll fenn. Vegyünk egy alábbi, XForms nyelven írt példát: <style type="text/css"> body { font-family: sans-serif} label { display: inline-block; width: 3em; margin: 0 1em } <xf:model> <xf:instance> 2 <width>3 <depth>4 <xf:input incremental="true" ref="height"> <xf:label>Height
<xf:input incremental="true" ref="width"> <xf:label>Width
<xf:input incremental="true" ref="depth"> <xf:label>Depth
Total volume: <xf:output value="height * width * depth" />

A leíráshoz tartozó fa modellt a 2.1. ábra szemlélteti. Az ábrában a csomópontok, azaz node-ok és text node-ok téglalappal vannak jelölve, az attribútumok nevei pedig ellipszis-be, melyet szaggatott vonallal vannak jelölve mely elemhez tartoznak. Az ábra nem tartalmazza a HTML attribútumait, melyek a dokumentum névtereit nevezik meg; valamint az elemeken használt prexeket sem jelöltem. A fa ilyen kis dokumentum esetén is nagy méretet ölt, f®leg hogy valójában még a dokumentumba írt, olvashatóságot növel® tabulátorok és szóközök is 1-1 csomópontnak felelnek meg! A fában való navigációhoz alapvet®en a következ® lehet®ségek tartoznak: mozgás lefelé (a gyerek elemek felé), valamint visszafelé lépés (a szül® felé), és lehet még a testvérelemekre is navigálni, azaz amelyik egy ugyanolyan szinten helyezkednek is, közös 10

2.3. Szoftverfejlesztési trendek

2.1. ábra. Fa szerkezet szül®vel. Így tehát a body elem a dokumentum gyereke, ® maga pedig a szül®je a 3 input elemnek, a szöveg csomópontnak, valamint az output elemnek. Ezek 5-en testvérek, hisz egy szinten vannak, és a szül®jük közös: body. [11] A DOM API ezen felül rengeteg egyéb lehet®séget is kínál. Ezt f®leg az XPath kifejezés használja fel, mely egy elérési utat képes deniálni a fában (lsd. kés®bb). Egy-egy elem valamint részfa kijelölésére egy tucatnyi lehet®ségünk van, melyek közül párat a 2.2-es ábra jól szemléltet: • ancentors(): Az ®sök. Egy elemhez kapcsolódik, és azt a részfát adja vissza, mely-

b®l ered.

• parentNode: Szül®. Egy elemet ad vissza: az aktuális elem szül®jét. • previousSibling() és nextSibling(): testvérek között lépegethetünk vele - azaz a

fában egy szinten lév®, de közös szül®t®l származó elemek közti navigációra szolgál.

• childElements(): Az aktuális elem összes gyerek elemét adja vissza. • descendants(): A leszármazottak. Az aktuális elem alatt található részfát tartal-

mazza.

• attributes(): Az aktuális elem attribútumai.

Ezeken kívül található még olyan részfát vissza adó utasítások is, melyek a fa bejárása során felrajzolt struktúra alapján jelöli ki az aktuális elem megel®z® elemeit, valamint utána jöv® elemeit. Az XPath-ban ezeket tengelyeknek nevezi, így pl. "attribútum tengely", de önmagát, és a teljes részfát is egy-egy tengellyen jelöl. 11

2.3. Szoftverfejlesztési trendek

2.2. ábra. Lehetséges DOM API nyújtotta bejárási irányok [11] 2.3. Szoftverfejlesztési trendek

A programozási nyelvekkel együtt fejl®dtek a szoftverfejleszt® eszközök és folyamatok . Igen nagy utat tettek meg, amíg eljutottak az integrált fejleszt®i környezetig. [3] Az ®sid®kben a gépi kód közvetlenül került bevitelre: konzolkapcsolókkal, majd kés®bb lyukkártyák segítségével. A '80-as években a szoftverfejlesztés a karakteres alapú alkalmazásokon keresztül történtek. Program nyelvük f®leg Assembler szint¶ volt, kés®bbiekben C, Pure HTML. Nehézség volt a sz¶kös er®forrás is, ami byte szint¶ optimális kódot követelt. Tipikusan kevés fejleszt® volt, egy-egy projectet nem tudtak több fejleszt® számára is programozhatóvá tenni. Több parancssori eszközt is használtak, mely felszabdalta a fejlesztési folyamatot, így külön volt eszköz a kódszerkesztésre, fordításra, hibakeresésre, . . . A '80-as évek vége felé kezdtek megjelenni a hagyományos eszközök, mint pl. a Turbo Pascal, de csak egy részfolyamathoz lehetett használni (pl. kódolás). A '90-as évekre jelentek meg a grakus operációs rendszerek, melyre több különböz® keretrendszer volt elérhet® - így pl. Win32-n a Borland (Delphi, C Builder), és az MS (Visual Studio), míg Linux alatt a QT, Kdeveloper, és a Borland volt a népszer¶. Napjainkban az ipari méret¶ alkalmazások fejlesztése reménytelen integrált fejleszt®i eszközök (IDE) nélkül. Bonyolult és összetett platformokat, XML leírókat használunk, mely utóbbi nem is emberi szerkesztésre van optimalizálva. Napjainkra jellemz®ek a fejlett objektum orientált programozási nyelvek, az IDE-k használata kényelmes, hatékony és gyors - összefogja a gyártó tool-jait, közös keretet adva nekik. A tendencia a nyílt fejleszt®rendsze-rek el®retörését mutatja, melynek számos el®nyös tulajdonsága van, mint pl. egy jól deniált keretrendszer, könny¶ b®víthet®ség, platformfüggetlenség, programozási nyelv független-ség, valamint optimális a gyorsan változó 12

2.4. XForms kialakulása, jellemzése

igényekhez. Az er®források megnövekedésével többé már nem kell byte szint¶ optimális kód kifejlesztése, ezáltal meggyorsul a fejlesztés, valamint lehet®séget ad arra, hogy egy tervezeten több száz fejleszt® is dolgozhasson. Ahhoz hogy több programozó munkáját összehangoljuk, a cél a kód modulokra bontása: • Komponensek újrahasznosítása • Komponensek kicserélése • Programozási feladatok szétbontása • Tesztelhet®ség

Ezekre a problémákra egy lehetséges megoldás az MVC design pattern. Az MVC eredete a '70-es évek végén megjelen® Xerox grakus UI. Nagy gyelmet a webes, illetve az Objective C fejlesztések során kapott, és manapság is meghatározza bármely GUI-val rendelkez® szoftver felépítését. 2.4. XForms kialakulása, jellemzése

Egy interaktív weboldal nem létezhetne ¶rlapok nélkül. Az ¶rlap az a része az oldalnak, amin keresztül kommunikálhatunk a felhasználóval. A weben nagyon sok ¶rlappal találkozhatunk. Például amikor regisztráljuk magunkat egy oldalra, bejelentkezünk, keresünk vagy más hasonló tevékenységeket végzünk, akkor ezt mind ¶rlapokon keresztül tesszük. Fejleszt®i oldalról egy ¶rlap létrehozása egyszer¶, csupán fel kell sorolni a részeit, meghatározni, hogy dolgozza fel az adatokat, és ehhez valamilyen stílust kell deniálni. Ennek az egyszer¶ségnek viszont ára van. Egy HTML ¶rlap nem tudja eldönteni, hogy a felhasználó által bevitt információ a megfelel formában van-e megadva, és egyszer¶ számítások elvégzését sem tudja elvégezni. Erre megoldást a JavaScript nyújthat, amely képes kliens oldalon a weboldalon található mez®k értékét manipulálni, validálni. A scriptek megírása viszont id®igényes, és ha néhány hónap múlva valami miatt hozzá kell nyúlni a kódhoz, nem biztos, könnyen tudunk tájékozódni benne, ha meg nem is mi írtuk, akkor nem kis fejfájást okozhat a kód módosítása. Ráadásul a böngész®kben biztonsági okok miatt a JavaScript letiltható. HTML verziók: • 1990: HTML 1.0 • 1994: HTML 2.0 • 1996: HTML 3.0 • 1997: HTML 4.0 • 1998: A W3C a HTML jöv®jére két féle változatot képzel el:

13

2.4. XForms kialakulása, jellemzése

 Áthozni a tag rendszert XML-be (XHTML)  Forms-okon dolgozni, melyet kés®bb leválasztanak (XForms) • 2000: XHTML 1.0 • 2002: XHTML 2.0

A HTML ¶rlap hiányosságait gyelembe véve a W3C létrehozta az XForms szabványt, ami a webes ¶rlapok következ® generációja. Az XForms képes az adatok validálására, egyszer¶bb számítások elvégzésére, így elkerülhetjük, hogy JavaScriptet kelljen használnunk. Az XForms deklaratív, ezért könnyebb elsajátítani és használni. A kód kés®bbi módosítása is sokkal egyszer¶bb, mint a JavaScript-nél. Ráadásul elkülöníti az adatstruktúrát a megjelenítést®l, ezáltal az egyes részek újrafelhasználhatóak lesznek. Nagy el®nye a HTML ¶rlapokkal szemben, hogy használhatunk beépített adattípusokat, vagy hozhatunk létre saját típust is. Az XForms egy új nyelv a W3C-t®l, amit web- és ¶rlap programok fejlesztésére lehet használni, egyszer¶ ¶rlapok készítését®l a komplex web 2.0 alkalmazásokig. Az XForms dinamikus, rendszerfüggetlen, szkript nyelv független és teljesen szabványos. Nem egy különálló dokumentumtípus, hanem integrálni kell más nyelvekbe, mint az XHTML vagy SVG. Sokat tanult a HTML-beli ¶rlapok jó és rossz tulajdonságából. Az XForms követhet®bbé és tisztábbá teszi azt, hogy milyen adatot is küldtünk el, és hová. Könnyen újra felhasználhatóvá teszi az ¶rlapokat, amik már nem szorosan köt®dnek ahhoz az oldalhoz, amelyiken használják. A klasszikus HTML web ¶rlapok nem különítik el az ¶rlap funkcióját a megjelenítést®l. Ezzel ellentétben az XForms elkülöníti az ¶rlap kezelését, a megjelenítését és az adatait. Így rugalmas megjelenítési beállításokat tesz lehet®vé. Az XForms egyik fontos elve, hogy az ¶rlapja adatait az XForms adatait reprezentáló "instance" elemben lév® elemekben helyezi el. Ezeket az elemeket fogom adat-példányként nevezni. A többi funkció mellett az XForms modell leírja a struktúráját is az adat-példánynak. [5]

2.4.1. XPath és az XSLT-vel való kapcsolat

A Formok adatokat gy¶jtenek, így nem meglep®, hogy az XForms legfontosabb része az adatpéldány, az adat egy bels® reprezentációja, ami le van képezve az ismer®s control elemekre. Els®re talán meglep® az XForms és az XPath társasága, mivel az XPath-ot egy közös rétegként tudjuk az XSLT és az XPointer között, nem pedig a web formok alapkövének. Ahogy az XForms alakult úgy t¶nt, a formoknak nagyobb struktúrára van szükségük, mint amit egy név-érték páros adhat. Ehhez a nagy struktúrához viszont kellett egy olyan kialakítás, amivel az adatok egyes példányát el lehet érni vagy "bind"-elni lehet a form kontrollerek bizonyos részeihez - ezért alkalmazzák az XPath-ot. [6] Ha már az XForms és az XSLT is az XPath-on keresztül kapcsolódnak, érdekes lehet összehasonlítani a két technológiát. Az XSLT általában 3 fával jellemezhet®, melyek XML dokumentumok átalakításával kapunk. Az XForms feldolgozása hasonló, de kombinálja az inputot és az outputot egy fába. 14

2.4. XForms kialakulása, jellemzése

2.3. ábra. Az XSLT és XForms feldolgozásának illusztrációja [6] Feldolgozás XSLT esetében: 1. Az input forrásból (leggyakrabban dokumentumokból) a "source tree" (forrás) és a "stylesheet tree" (stílus) a memóriában van tárolva 2. Ezt a két fát feldolgozva kapunk egy harmadikat, ami a "result tree" (eredmény) 3. Amikor a feldolgozás végbement, az eredmény fa - legtöbb esetben egy új XML dokumentumba - képz®dik le. Feldolgozás XForms esetében: 1. A bemeneti adatok akár a dokumentumba van írva, akár egy XML dokumentum egy szerveren, az adatpéldány a memóriában tárolódik. 2. Egy adatpéldány feldolgozása magában foglalja a felhasználóval való interakciót és feljegyez minden változást az adatokban. 3. Elküldéskor az adatpéldány - leggyakrabban mint XML - leképz®dik, és a servernek küld®dik el 2.4.2. XForms el®nyei és hátrányai

El®nyök: • Elegáns MVC (modell-nézet-vezérl®) kialakítás. • Deklaratív programozási nyelv, amit könny¶ tanulni, és a nyelvvel készített prog-

ramokat egyszer¶ karbantartani, bel®ni.

• Kompatibilis XML szabványokkal, úgy mint CSS, XML Schema és XPath • Kiterjeszthet®ség • Nemzetközisítés: (mivel az XML-r®l van szó, használható az Unikód)

15

2.4. XForms kialakulása, jellemzése

2.4. ábra. Az XForms f® elemeinek és kapcsolódásainak szemléltetése [6] Hátrányok: • Beépített támogatás hiánya Microsoft Internet Explorernél. • Használatához le kell tölteni a böngész®be egy kiegészít®t. • JavaScript alapú megvalósításoknál (pl. FormFaces) az oldal megtekintéséhez egy

kb. 85kb-os állományt szükséges letölteni.

• CSS szükséges ahhoz, hogy az ¶rlapok elfogadható kinézet¶ek legyenek. • A CSS 3 számos tulajdonságát nem támogatja a Microsoft Internet Explorer. • Kevés m¶köd® példaalkalmazás található. • Kevés grakus ¶rlapkészítést segít® alkalmazás van a piacon. 2.4.3. XForms dokumentum megnyitása

Jelenleg egyetlen böngész® sem támogatja teljes mértékben közvetlen módon az XForms technológiát, de több lehet®ségünk is van az XForms használatára. Az egyik lehet®ség, hogy egy beépül® modult telepítünk a böngész®re, ami képes feldolgozni az XForms utasításokat. Mivel a Mozilla is részt vett az XForms kialakításában, így az általuk írt Firefox böngész®vel könnyedén megnyitható az XForms program egy beépül® letöltése után. Ennek a beépül®nek a legfrissebb változata a Firefox 3.5-ös verzióhoz lelhet® fel, így a böngész® ezen verziója szükséges. A másik megoldás egy olyan alkalmazás használata, ami szerver oldalon átalakítja az XForms-ot tartalmazó XHTML dokumentumot egy szabványos HTML oldallá. Ezek az alkalmazások mind 16

2.5. MVC

az Ajax technológián alapulnak, ami azzal jár, hogy az XForms által meghatározott m¶ködést lecserélik JavaScriptre. Ezek kicsit lassabbak, de minden JavaScriptet ismer® böngész® képes ezeket megjeleníteni. 2.5. MVC

A modell-nézet-vezérl® (magyarul MNV; angolul model-view-controller MVC) a szoftvertervezésben használatos szerkezeti minta. Összetett, sok adatot a felhasználó elé táró számítógépes alkalmazásokban gyakori fejleszt®i kívánalom az adathoz (modell) és a felhasználói felülethez (nézet) tartozó dolgok szétválasztása, hogy a felhasználói felület ne befolyásolja az adatkezelést, és az adatok átszervezhet®k legyenek a felhasználói felület változtatása nélkül. A modell-nézet-vezérl® ezt úgy éri el, hogy elkülöníti az adatok elérését és az üzleti logikát az adatok megjelenítését®l és a felhasználói interakciótól egy közbüls® összetev®, a vezérl® bevezetésével. Gyakori egy alkalmazás több rétegre való felbontása: megjelenítés (felhasználói felület), tartománylogika és adatelérés. Az MVC-ben a megjelenítés tovább bomlik nézetre és vezérl®re. Az MVC sokkal inkább meghatározza egy alkalmazás szerkezetét, mint az egy programtervezési mintára jellemz®. [7]

2.5. ábra. Az MVC modell [8] Modell: Az alkalmazás által kezelt információk tartomány-specikus ábrázolása. A tartománylogika jelentést ad a puszta adatnak (pl. kiszámolja, hogy a mai nap a felhasználó születésnapja-e, vagy az összeget, adókat és szállítási költségeket egy vásárlói kosár elemeihez). Sok alkalmazás használ állandó tároló eljárásokat (mint mondjuk egy adatbázis) adatok tárolásához. Az MVC nem említi külön az adatelérési réteget, mert ezt beleérti a modellbe. Nézet: Megjeleníti a modellt egy megfelel® alakban, mely alkalmas a felhasználói interakcióra, jellemz®en egy felhasználói felületi elem képében. Különböz® célokra különböz® nézetek létezhetnek ugyanahhoz a modellhez. Vezérl®: Az eseményeket, jellemz®en felhasználói m¶veleteket dolgozza fel és válaszol rájuk, illetve a modellben történ® változásokat is kiválthat.

Az MVC gyakran látható web-alkalmazásokban, ahol a nézet az aktuális HTML oldal, a vezérl® pedig a kód, ami összegy¶jti a dinamikus adatokat és létrehozza a HTML-ben a tartalmat. Végül a modellt a tartalom képviseli, ami általában adatbá17

2.5. MVC

zisban vagy XML állományokban van tárolva. Habár az MVC-nek sok értelmezése létezik, a vezérlés menete általánosságban a következ®képp m¶ködik: 1. A felhasználó valamilyen hatást gyakorol a felhasználói felületre (pl. megnyom egy gombot). 2. A vezérl® átveszi a bejöv® eseményt a felhasználói felülett®l, gyakran egy bejegyzett eseménykezel® vagy visszahívás útján. 3. A vezérl® kapcsolatot teremt a modellel, esetleg frissíti azt a felhasználó tevékenységének megfelel® módon (pl. a vezérl® frissíti a felhasználó kosarát). Az összetett vezérl®ket gyakran alakítják ki az utasítás mintának megfelel®en, a m¶veletek egységbezárásáért és a b®vítés egyszer¶sítéséért. 4. A nézet (közvetve) a modell alapján megfelel® felhasználói felületet hoz létre (pl. a nézet hozza létre a kosár tartalmát felsoroló képerny®t). A nézet a modellb®l nyeri az adatait. A modellnek nincs közvetlen tudomása a nézetr®l. 5. A felhasználói felület újabb eseményre vár, mely az elejér®l kezdi a kört. A modell és a nézet kettéválasztásával az MNV csökkenti a szerkezeti bonyolultságot, és megnöveli a rugalmasságot és a felhasználhatóságot. 2.5.1. MVC az XForms-ban

Az XForms szabvány a HTML ¶rlapok hiányosságait hivatott orvosolni, XHTML-t kiegészítve XForms elemekkel. F® alapelve az ¶rlap modell és a megjelenítés elkülönítése - azaz a modell és view kettéválasztása. A modell szerepét a dokumentum elején található XML típusú "fej" deníciós rész tölti be, míg a megjelenítés a "törzs"részben található. Minden egyes mez®t egy-egy XPath [xpath] kifejezés csatol a dokumentum modellhez, összekötve a modellt a megjelenítéssel. A felhasználó által beadott adatok bekerülnek a dokumentum modellbe, és a kitöltés végén egy komplett XML dokumentum áll el®. Egy XForms dokumentum ezen kereten belül különíti el az ¶rlap modellt és az ¶rlap megjelenítését. A fejrész a megjelenített ¶rlap mögött lév® adatszerkezetet írja le. Az ¶rlap modell legfontosabb része az egyed (instance), ami az ¶rlap által kitöltött XML dokumentumfát tárolja. Ez az XML lehet az XHTML dokumentumban közvetlenül tárolva, vagy küls® fájlként is tárolható, a dokumentum pedig egy URL segítségével hivatkozik rá. Az ¶rlap megjelenítését az XHTML dokumentum törzs részébe rakható ¶rlapelemek végzik. A legtöbb ¶rlap elem egyszer¶ mez®t reprezentál, egyetlen szöveg, dátum, vagy hasonló típusú adat bekérésére alkalmas. Minden ilyen elemet a modellben szerepl® XML dokumentumhoz lehet kötni, így amikor a felhasználó kitölti a mez®t, a megjelenítés mögött lév® XML egyedben megjelenik a megadott érték.

18

3. fejezet Fejleszt®i dokumentáció

Az XForms manapság nem használt, nem elterjedt adatfeldolgozó eljárás internetes ¶rlapoknál, ezért az újabb böngész®k már nem támogatják, vagy csak nagyon kevés elemet. Olyan szint¶ vezérlést képes nyújtani, mint amelyet a ma használt ¶rlapok az interneten nem - mindehhez pedig csupán XML-t használ. Régebbi XForms dokumentumaink megnyitásához régi rendszer kell, melyhez általában külön kiegészít®k is kellenek a helyes és teljes eredmény megkapása érkedében. Szakdolgozatom rövid programja megpróbálja a legfontosabb elemeket átalakítani a ma is használatos HTML nyelvre. Némelyiket könnyedén, míg másokat egyáltalán nem lehet átírni a HTML-el és JavaScript parancsokkal. A konvertálás során, éppúgy mint az XForms-ban magában, itt is szétválasztódik az MVC három összetev®je. A programom el®ször a view részt hozza létre, eztán tölti be a modell részt, s a hozzá szükséges JavaScript gyel®ket a modell módosítására. A kontroller rész külön nyomógombokkal fog aktiválódni, melyet szintén a PHP vezérel majd le, egy JavaScript esemény hatására. Dolgozatomban el®ször a modell részt fogom részletezni, hogy épül fel egy XForms modell, hogyan készült az elemzése, értelmezése. Ezt követi a view rész, melyben részletezem az XForms adta beviteli lehet®ségeket, és hogy az hogy valósítható meg a HTML nyelvben, valamint hogyan történt annak konverziója. Végül a kontroller rész, mely a modell fa feltöltésér®l, XML dokumentumba való lementésér®l, valamint betöltésér®l szól.

3.1. Modell

3.1.1. Modell az XForms-ban

A f® különbség az XForms és a HTML között az, hogy az elküldend® adatok össze vannak gy¶jtve a head részben, melynek neve model. Csupán a form kontrollerek szükségesek ezek után a body részbe. ... <xf:model> <xf:instance>

19

3.1. Modell

... ...

A modell az XForms dokumentum (leggyakrabban XHTML) fej részében szerepel. A deniálásához egy névtér szükséges, melyet a HTML fejrészben lehet megadni, példánkban az xf prexhez rendeltük azt. Mivel a model nem az XHTML számára vonatkozó teg, ezért használni kell az xf: prexet. A modell rész alapul szolgál a dokumentum beviteli elemeire, ugyanis a beviteli elemek hivatkoznak a modell különböz® elemeire egy ref attribútom megadása révén. A dokumentumba ezáltal a

elem teljesen kihagyható, helyette csupán a kontrollerek maguk kellenek, így például egy szöveg bekér®: Find

A model element-nek van instance nev¶ gyereke (kötelez®), akár több is, ami jelöli a példányokat - szintén prexel ellátott, hogy értelmezze az XForms, nem egy elemr®l van szó, hanem egy újabb pédányosítás következik. Ezen belül található a data, mint alapértelmezett elem. Ezen elem gyerekeire való hivatkozást a ref kulcsszó után közvetlenül megadhatjuk a kontrollerekben, mind példánkban a ref="q". Az ebbe az input mez®be kitöltött adat értékül fogja adni a model rész tartalmának ezt. S®t, lehet®ség van arra, hogy azonnal módosítsa az elem értékét, ne csak akkor mikor elment a fókusz az aktuális mez®r®l - így még szorosabban összekötve a modell-t és a nézetet. Ezen módosított adatok a kés®bbiekben felhasználható kiírásra, vagy további módosításra, esetleg elküldésre/submit-álásra. A letárolás mindig string módon történik, de a dokumentumba több féle képp is lehet az egyes elemekre hivatkozni a kontrollerek segítségével - így például számként egy csúszkával, melyet állítgatva egész számok között váltogatunk. Legtöbbje megtalálható a HTML nyelvben is, csupán egy kisebb fajta átértelmezés szükséges a megismeréséhez, megértéséhez. Ezért is a kés®bbiekben bemutatott felhasználási felület HTML szabányként is megmutatja ezen kontrollerek m¶ködését.

3.1.2. Modell elem leképzése és beolvasása

A megnyitásra szánt XForms fájlt el®bb meg kell nyitnunk, aztán pedig leválasztani róla a modell részt. Hogy a megnyitás ne történjen duplán - mind a PHP és javaScript részr®l - ezért a PHP-t használjuk, hogy beolvassa a fájlt mint egy DOM szerkezeti fát. $dom = new DOMDocument(); $dom -> load('peldaxForms_1.xml');

A dom változónak el®ször megmondjuk, hogy egy DOMDocument típusú objektum jön lérte. Ez azért fontos, hogy a továbbiakban a fában való ugrálást segít® DOM API-t használni tudjuk ezen változón. Azt, hogy épp milyen utasítást adunk a változónak, a 20

3.1. Modell

-> segítségével mondhatjuk meg PHP-ben. Mivel a dom változó el®ször egy üres fára mutat, így be kell neki tölteni egyet, példánkban a peldaxF orms1 .xml fájlt. A betöl-

tés parancsa a load, ami a megadott fájlt letölti (akár más szerveren lév®t is), majd felbontja DOM szerkezet¶re, és átadja azt a $dom változóba.

Az XForms-ban lehet®ség van arra is, hogy a modellt más helyre való mutatással adjuk meg, akár többet is, küls® er®forrást használva. Mivel szakdolgozatom témája csupán egy alap mintarendszer bemutatása, így ezzel nem tör®dünk, mindenképp szerepelnie kell egy <model> résznek valahol. A PHP a DOM fába való keresés során fel képes ismeri azt, hogy az elem nevében mi a prex, és mi az elem neve, így az alábbi utasítás helyes végrehajtást eredményez, és a model nev¶ változóba beletesszük az els® "model" nev¶ részfát: $model=$dom->getElementsByTagName('model')->item(0);

Nincs más teend®, minthogy ennek a változónak a tartalmát átadjuk a JavaScriptnek. Sajnos a PHP nem kínál lehet®séget a részfa tartalmának teljes kiírására mint elemmet, attribútummal, tartalommal együtt. Ehhez a részfát be kell járnunk, és úgy kiíratni. Ezt a feladatot rekurzióval lehet megoldani, egy olyan függvényt létrehozva, mely elemzi a kapott csomópontot, és eldönti, hogy az szöveg csomópont e, elem csomópont, és ha elem, akkor vannak e további gyerek elemei? A programomban ennek a kiírását egy külön DIV elembe íratom ki, melynek stílusát láthatatlanra teszem, hogy végül ne írja ki. function elemez($lista){ $szulo = $lista->childNodes; foreach ($szulo as $elem){ $NN=$elem->nodeName; if ($elem->hasChildNodes()) { print "<".$NN.">"; elemez($elem); print ""; } else { if ($elem->nodeType == 3) print $elem->nodeValue; else print "<".$NN.">_".$elem->nodeValue. " "; } } } print '

<xForms>'; elemez($model); print '

';

Az egész model részt egy saját "xForms" elemmel fogom meg - ez azért szükséges, hogy több példány esetén is legyen egy közés gyökérelem amib®l leszármazhatnak. A függvényünket a model elemre hívjuk meg el®ször, ezen fog a rekurzió végrehajtódni. Els® lépésben a szulo változóba tesszük a vizsgált csomópont gyerek elemeit, majd egy foreach ciklussal végignézzük egyesével. Érdemes arra is gyelni, hogy a kiírt modell-t a HTML ne kezdje el értelmezni, mint saját részt - ezért azt szükséges, hogy a < és > 21

3.2. XForms view elemek HTML-re alakítása

jeleket HTML kódra alakítva írjuk ki: < és >. Most jöhet a JavaScript, ami a PHP által generált dokumentumba megkeresi eme részfát. A dokumentum készítése során gondoskodtam arról, hogy a DIV elemet, melyben a modell szerefel egy azonosítóval lássak el: id="xFormsModell". Ahhoz, hogy a modell elemzése csak a dokumentum készen állása után hajtódjon végre, a jQuery $(document).ready utasítását használjuk fel - ez teszi lehet®vé hogy a kód csak akkor fusson le ha az oldal betölt®dött. $(document).ready(function(){ text=document.getElementById("xFormsModell").innerHTML; text=text.replace(//g,'>'); text=text.replace(/[a-zA-Z]+:/gm,''); text=text.replace(/(><)([a-zA-Z])/g,'> <$2');

}

parser=new DOMParser(); xmlDoc=parser.parseFromString(text,"text/xml");

A xFormsModell tartalmának lekérése után számos átalakítani való akad: el®szöris a HTML kódokat vissza kell alakítanunk normális karakterekre - hisz a javascript az oldal tartalmát olvassa ki, és nem azt amit lát, így tehát az < és > újra < és > lesz! Ezután, mivel a JavaScript már nem boldogul a prexekkel (és erre semmi szükségünk sincs a továbbiakban), ezeket egy reguláris kifejezéssel töröljük. A harmadik átalakítás nem feltétlen szükséges: azt biztosítja, hogy minden elemnek legyen egy szöveg csomópontja a könnyebb értelmezés végett. Ha már a text változónk készen áll, kezd®dhet az átalakítás! Ehhez a JavaScript DOMParser metódusát használjuk fel. A DOMParser egy konvertálót inicializál, jelen esetünkbe a parser változónak. Ennek a medódusnak egyik parancsa, hogy képes szöveget egy XML alapú DOM fára alakítani. Erre a parseFromScript() függvény ad lehet®séget, paraméterében megadjuk hogy mit konvertálunk, és hogy milyen típusra. Ezzel az xmlDoc változónkba sikeresen átkerül az XForms dokumentum modell-be, melyet kés®bbiekben a DOM API segítségével könnyen módosíthatunk. 3.2. XForms view elemek HTML-re alakítása

Az XForms az összes, HTML-ben is elérhet® kontrollereket meg tudja valósítani. Fordítva ez már nem mondható el: több olyan egyedi kontroller is elérhet®, melyet nem lehet egyszer¶en a HTML adta kontroller típussal leírni. A f® különbség azonban az, hogy míg a HTML azt mondja meg, hogy hogyan nézzen ki, addig az XForms azt írja le, hogy hogyan dolgozzon. Így például a HTML azt írja le, hogy <select>, vagy épp , addig az XForms a <select> és <select1> parancsot használja, mely megmondja számára hogy egy vagy több kijelölést teszünk lehet®vé - így a kinézet hely és platform szerint változó megjelenítést eredményhet. Természetesen lehet®ség van ezeket saját stíluslappal felülbírálni, hogy mit javaslunk a használatra. Példaként vegyük az elemet, mely HTML-ben a következ®: Adjon meg egy szöveget:

22

3.2. XForms view elemek HTML-re alakítása

Ezt XForms-ba elég csupán az alábbi módon leírni: Adjon meg egy szöveget:

Mint látható, nem mondtuk meg, hogy az adott input elem milyen típusú, mivel az XForms-ba alapból minden text (azaz String) típusú. A továbbiakban a többi kontrollert tárgyalom, valamint a programkódot, ha azt megvalósítottam a szakdolgozatom programjában is. 3.2.1. Az átalakítás motorja

A kódgenerálás VIEW részéhez PHP-t használtam. El®z®, Modell részben már betöltöttem a konvertálni kívánt dokumentumot egy dom változóba. Most ezt a fát kell elemezni, a body elemt®l kezdve. Olyan elemeket kell keresnünk, amelyek XForms elemek, tehát a HTML elemnél deniált névtérbe tartoznak. Ehhez el®ször meg kell határozni mi az aktuális prex: function prefix_meghat($dok){ $vizsga=$dok->getElementsByTagName('html')->item(0); return $vizsga->lookupPrefix('http://www.w3.org/2002/xforms'); } $pref=prefix_meghat($dom); if ($pref=="") exit("Nem XForms dokumentum.");

Függvényünk a html elemet kéri le, és ezután a lookupPrefix segítségével keresi meg a prexet. Jelenleg a 2002-es szabvány a legújabb és egyetlen teljes érték¶ W3 szabvány. A pref globális változónkba tároltam le ezt, hogy kés®bbiekben is elérhet® legyen. Ezután megvizsgálhatjuk, talált e valamit, mert ha nem, akkor az a generálóm számára nem XForms dokumentum, így ki is lép egy hibaüzenettel. Továbbiakban a body elemen belüli részfát kell elemezni, melyre szintén csináltam egy függvényt, rekurzív meghívás lehet®sége miatt. elemez_view($dom->getElementsByTagName('body')->item(0),$pref); function elemez_view($lista,$pref){ $szulo = $lista->childNodes; $prefix=$pref.":"; foreach ($szulo as $elem){ if (strpos(strtolower($elem->nodeName), strtolower($prefix))!==false){ switch ($elem->nodeName){ case (...): ... break; case (...): ... break; default: echo 'Hopsz, ismeretlen xForms elem: '.$elem->nodeName."!
\r\n"; } } else { if ($elem->hasChildNodes()) { if($elem->hasAttributes()){

23

3.2. XForms view elemek HTML-re alakítása

}

}

}

$attributes = $elem->attributes; echo "<".$elem->nodeName; foreach ($attributes as $attributes2) echo $attributes2.'="'.$attributes2->value.'" '; echo ">"; } else echo "<".$elem->nodeName.">"; elemez_view($elem,$pref); echo "nodeName.">"; } else { if ($elem->nodeType!=XML_TEXT_NODE) { if($elem->hasAttributes()){ $attributes = $elem->attributes; echo "<".$elem->nodeName; foreach ($attributes as $attributes2) echo $attributes2.'="'.$attributes2->value.'" '; echo "/>\r\n"; } else echo "<".$elem->nodeName."/>\r\n"; } else print $elem->nodeValue; }

M¶ködése hasonló a JavaScript-ben bemutatott model elemz® függvénynek, csak itt a pontok helyett nyilakat kell használni a DOM API utasítások eléréséhez. Lekérjük a kapott csomópont gyerek elemeit, és ezeken az elemeket megyünk végig a foreach segítségével. Azzal kezdjük, hogy megvizsgáljuk az elem XForms beli beviteli mez®-e? Ehhez azt kell megkeresnünk, hogy az elem (nagybet¶ssé tett) nevében szerepel-e az el®z®leg meghatározott prexünk. Ha igen, akkor másképp kell eljárnunk, mint egy HTML elemnél, hiszem ezeket konvertáljuk. Az elem nevét ekkor egy switch-case ággal választjuk majd külön, attól függ®en mit lát a program. Mivel rengeteg elem található meg az XForms-ban, ezért célszer¶ egy default elemet is csinálni, mely kiírja, hogy az adott elemet nem képes átalakítani. Ha az adott elem nem tartalmazza a meghatározott prexet, akkor a standard famélyítést használjuk: ha gyerek elemmel rendelkezik, kiírjuk az elemet (attribútumaival együtt), és tovább mélyítjuk a keresést - végül pedig lezárjuk az element-et. Sajnos a PHP nem tudja az elemet kiírni attribútumaival együtt, ezért erre külön foreach ciklust kellett írnom. El®fordulhat, hogy az aktuálisan vizsgált csomópontnak nincs gyereke, mégis element típusról van szó - esetleg egy szöveg került ide. Err®l gondoskodik az utolsó rész: megvizsgálja szövegr®l van e szó, és kiírja azt - ha pedig nem, akkor a gyerek elem kiírásakor is használt módszerrel kiírja az elemet az attribútumaival együtt. Ezzel a módszerrel a teljes fa bejárható, és megtalálhatóak a keresett XForms elemek - valamint kiírja a HTML elemeket is ha van. Továbbiakban az egyes speciális elemek vizsgálása és generálása lesz.

24

3.2. XForms view elemek HTML-re alakítása

3.2.2. Input

Els® szemügyre vett megjelenít® az input - egy soros szöveges adat bekérésére szolgál, a legalapvet®bb és legelterjedtebb ¶rlapmegjelenít® elem. XForms-os és HTML-es alakja nem különbözik sokban, megjelenítését tekintve pedig egyforma. Gyerem eleme lehet a label, mely megjelenítve a beviteli mez® el®tt szerepel szöveg formájában, valamint pl. egy hint, mely megjegyzésre szolgál, meg nem jelenik. A konvertálásra megírt kód a következ®: case ($prefix."input"): /*echo "Ez egy input mez®";*/ $label=$elem->childNodes; $label3=""; foreach ($label as $label2){ if ($label2->nodeName == $prefix."label") $label3=$label2->nodeValue; } echo $label3." "; $id=$elem->getAttribute("ref"); echo ''; break;

A legtöbb elem észlelésének els® lépése az, hogy a hozzá tartozó label-t megkeressük, ugyanis ezt kell kiírni el®ször. Ehhez végignézzük a közvetlen gyerekeit, és ha találunk egyet, eltároljuk a label3 változóba, majd kiírjuk annak tartalmát. Mivel XForms megjelenít® elemr®l van szó, kötelez® szer¶en kell tartalmaznia a ref attribútumot, mely a modell fára való mutatást jelzi. Ezt az attibútumot a gyors keresés miatt ID-re alakítom át, így kés®bbiekben a JavaScript segítségével a DOM API getElementById("") parancsával gyorsan lekérhetem. A HTML legtöbb bevitelre szolgáló eleme input-al kezd®dik, ennek vannak különböz® fajtái, így tehát extra-ként oda kell írni, hogy szöveges bekérésr®l beszélünk: type=text.

3.1. ábra. Az sima input elem

3.2.3. Secret

Jelszavak beírásához használt megjelenít® elem a secret, mely közel teljesen azonos az input elemmel. Ami a modell-t illeti, semmiféle rejt®zdökést nem jelent - ugyanúgy látható string konstansként van jelen. HTML-ben is megtalálható ez a kontroller, szintén az részeként, csak a típusa "password". case ($prefix."secret"): $label=$elem->childNodes; $label3=" "; foreach ($label as $label2){

25

3.2. XForms view elemek HTML-re alakítása

if ($label2->nodeName == $prefix."label") $label3=$label2->nodeValue;

} echo $label3; $azon = $elem->getAttribute("ref"); print ''; break;

Az átalakítás menete teljes mértékben megegyezik az XForms input elemével.

3.2. ábra. Secret elem 3.2.4. Select1

Ezen ¶rlapmegjelenít®t az XForms már nem mindig egy féle képp jelenít meg. Megvizsgálja az, hogy milyen platformon vagyunk, mekkora annak a képerny®je, mekkora hely áll rendelkezésre, és ennek alapján változik. Arra szoltál, hogy egy el®re megadott listából kiválasszunk egyetlen elemet! Erre HTML-ben 3 féle lehet®ségünk is akad, melynek megjelenítését ki is kényszeríthetjünk az XForms kontrollerbe, méghozzá az appearance attribútum beállításával. Az attribútum megadása nem kötelel® jelleg¶, íme a 3 lehetséges megjelenítési forma: 1. Egy választógombos (radio) megoldás, ahol felsorolva látjuk az összes elemet, és ebb®l egyetlen egyet választhatunk ki mindig. Az, hogy ezek a gombok stílusra egymás mellett, vagy alatt van, az XForms maga automatikusan szabályozza (én mindig egymás mellé helyezem majd ®ket). Megjelenítés: instance="full" 2. Legördül® lista, melyb®l aktuálisan mindig csak egy elemet látunk és választhatunk ki. Ez a leghelytakarékosabb megoldás, ezért is jelöli az XForms minimalként: instance="minimal". 3. A köztes megoldásra egy olyan legördül® lista szolgál, melybe egyszerre több emel is megjelenít®dik, de csak egy választható ki. Az egyszerre látható ikonok állíthatóak, és szükség szerint - ha több elem van mint amekkora a lista - görgethet®ek is. Megjelenítés: instance="compact"

3.3. ábra. Select1 el®fordulásai: radio gombos, legördül® és multi-listás

26

3.2. XForms view elemek HTML-re alakítása

case ($prefix."select1"): if ($elem->hasAttribute("appearance")) { $TIPUS=$elem->getAttribute("appearance"); $TIPUS=strtoupper($TIPUS); } else $TIPUS="MINIMAL"; $radioname=$elem->getAttribute("ref"); $label=$elem->childNodes; $label3=""; //label (f®cím) keresése foreach ($label as $label2){ if ($label2->nodeName == $prefix."label") $label3=$label2->nodeValue;} if ($label3!="") echo $label3." "; $gombok=$elem->childNodes; if ($TIPUS=="COMPACT"){ echo '<select id="'.$radioname.'" size="4">';} if ($TIPUS=="MINIMAL"){ echo '<select id="'.$radioname.'">';} foreach($gombok as $gomb){ if ($gomb->nodeName == $prefix."item"){ $opts=$gomb->childNodes; foreach ($opts as $opt){ if ($opt->nodeName == $prefix."label") $nev=$opt->nodeValue; else if ($opt->nodeName == $prefix."value") $ertek=$opt->nodeValue; } if ($TIPUS=="FULL") echo ''.$nev."\r\n"; else echo ''.$nev.''."\r\n"; } } if ($TIPUS!="FULL") echo ""; break;

Legel®ször az appearance attribútum értékét keressük meg, hogy tudjuk milyen lesz a kinézet a HTML-ben. Mivel ez nem közelez®, ezért ha nem talál, default értékként a minimal-t állítja be. Minden select1 kötelez® része a model-re való mutatás a ref, melyet szokásos módon lekérünk. Lehetséges közvetlen gyerek elem a label, melyet szintén megkeresünk és kiírjuk a beviteli mez® elé. Ezt követ®en vizsgáljuk meg az egyes választási lehet®ségeket, melyet az XForms az item, prex-el ellátott elemmel ad meg. Még miel®tt elkezdenénk ezeket kilistázni, fontos hogy HTML-ben jelenjen meg a compact és minimal esetén szükséges közös szül®: a select. Compact esetén ennek size értékét mindig 4-re állítjuk be, azaz egyszerre 4 elemet tud felsorolni, a többet görgetéssel lehet majd elérni. Full megjelenítés esetén ilyenre nincs szükségünk, a megjelenít® elem name attribútuma fogja megmondani mely csoportba tartozik. Mikor a szükséges el®készületek megtörténtek, elkezdhetjük keresni az item element27

3.2. XForms view elemek HTML-re alakítása

eket. Egy item-nek is lehet több gyerek eleme, melyek az aktuális választás nevét és értékét mutatják meg. A neve a label elemmel van megadva, és megjelenítend® szövegként szolgál; az érték pedig a value elemmel, mely a model-be írandó értéket mutatja. Ennek a két elemnek a nevét el®bb letároljuk egy-egy változóba, hiszen megjelenítése függ a kinézett®l. Full típusú megjelenítés esetén szükséges az elem megadása, melynek neve az XForms-ban megadott ref attribútum, és értéke pedig a value-b®l kinyert érték. A megjelenítend® nevet ( label) pedig az elem után írjuk ki. K®nnyebb a helyzet, ha nem full megjelenítésr®l van szó: ekkor minden esetben egy elem szükséges az elemek felsorolásához. Ekkor a value attribútumába adjuk azt az értéket, melyet a modell-be szánunk, és az elem text gyerekeként pedig a megjelenítend® nevet. Végül, ha a típus nem full volt, akkor a beviteli mez®t le is kell zárnunk. 3.2.5. Textarea

Hosszabb szövegek bevitelére alkalmas ez a nézet-vezérl®, melyet több sorban, egy nagyobb blokk keretében látunk. Szintén szükség van az elengedhetetlen ref attribútumra, valamint lehet egy label gyereke, melyet a kontroller elé szokott kiírni. HTMLben ez az ¶rlapmegjelenít® szintén a elemmel érhet® el. case ($prefix."textarea"): $label=$elem->childNodes; $label3=" "; foreach ($label as $label2){ if ($label2->nodeName == $prefix."label") $label3=$label2->nodeValue; } echo $label3; $azon = $elem->getAttribute("ref"); print '<textarea id="'.$azon.'">'; break;

A konvertálásban semmi egyedi nincs: a label megkeresése után (ha van) lekérjük a

ref attribútumot, és id-ként adjuk azt vissza.

3.4. ábra. Textarea 3.2.6. Egyéb view megjelenít®k, továbbfejlesztési lehet®ségek

Csupán töredéke az, amit ismer a konverálóm az XForms nyújtotta milliónyi elemb®l. Ezek között vannak meg sem jeleníthet®k, valamint a megkötésekr®l eddig szó sem esett: a különböz® kontrollerek különböz® típusokat jelenthetnek, melyeket el®re meghatározott formában képes letárolni és használni. Elkövetkezend®kben egy továbbfejlesztési terv olvasható, hogy lehetne ezeket is beépíteni. 28

3.2. XForms view elemek HTML-re alakítása

Bind-ek

Az XForms modell részében igaz, hogy csak szöveges objektum állhat, de ezekre adhatunk különböz® típus-megszorítást. Erre szolgál a elem: ezt a modell deklarációban kell megadnunk, a példányosításon kívül - tehát követlen gyerekelemként kell beírni. Attribútumai közt szerepel a nodeset, mely a modell egy elemét jelöli ki; valamint a type, mely megmondja milyen típusú lehet. A megszorítás a VIEW-re lesz kihatással az XForms-ban: általában elég csupán egy input elemet írni, mely teljesen más kinézet¶ lesz egy típusdeklaráció után. A HTML-ben is népszer¶ checkbox-ok az XForms világba is elérhet®ek, ám ezek boolean operátorként m¶ködnek ott. Az említett input elemmel egyezik meg teljes egészében: egy lista elemhez egy input elem tartozik, de minden elemnek más-más a ref attribútuma van. Az input attól lesz checkbox, hogy a elemmel boolean típust rendelünk hozzá. A modellbeli érték a pipától függ®en "true", vagy "false" érték¶ lesz. A konvertálás lehetséges: minden egyes input mez® vizsgálatakor meg kéne nézni, szerepel e a bind-ek között erre vonatkozó típusdeklaráció, és ha igen, akkor azt checkbox-á kell konvertálni. XForms-ban tehát az alábbi módon fest: <xf:model>... <xf:bind nodeset="bool1" type="xs:boolean" /> <xf:bind nodeset="bool2" type="xs:boolean" /> <xf:input ref="bool1"><xf:label>Bool 1: <xf:input ref="bool1"><xf:label>Bool 1:

3.5. ábra. Checkbox boolean megvalósítással A bind egy nagyon egyedi típusa a dátum típus. Az XML-ben ez YYYY-MMDD formában fog megjelenni, melyet különböz® parancsokkal szintén formálhatunk. A bind típusát date-re kell állítani, de ehhez egy külön névtér is kell, méghozzá az XMLSchema névtere. A legtöbb XForms-ba beépítve szerepel egy naptár, mely az input elemet naptár formájába képes megjeleníteni. Ezt átkonvertálni nagyon nehezen lehet: egy bonyolult, JavaScriptben írt naptár szükséges hozzá. A naptár XForms-ba: <xf:model> <xf:instance xmlns="">

29

3.2. XForms view elemek HTML-re alakítása

<MyDate/> <xf:bind nodeset="MyDate" type="xs:date" /> <xf:input ref="MyDate"> <xf:label>Adj meg egy dátumot:

3.6. ábra. Dátum típusú bekérés: naptár Egész számok megadására is van lehet®ség integer vagy decimal formájában. Ezek bekéréséhez már nem az input elem szükséges, hanem egy külön csúszka, mely numerikus érték bevitelére szolgál billenty¶zet használata nélkül. Négy attribútummal rendelkezik a range: • start: A bekérend® szám alsó határa • end: A bekérend® szám fels® határa • step: Meghatározza, hogy egy lépés mennyi egész számú ugrást eredményezzen • incremental: A mindenhol jelen lev®, modellre vonatkozó attribútum, mely le-

het®vé teszi hogy a változás pillanatában azonnal módosítsa a modell fát. A range-hez egy olyan elemnek kell tartoznia, mely egész szám értér¶re van megadva. Egy példa rá XForms-ba: <xf:model> ... <xf:bind nodeset="egesz" type="xs:decimal" /> <xf:range ref="egesz" start="1" end="5" step="1" incremental="true"> <xf:label>Válassz egy számot:

30

3.2. XForms view elemek HTML-re alakítása

3.7. ábra. Range csúszka: csak XForms-ban valósítható meg Event-ek

Az event attribútummal olyan eseményeket válthatunk ki, melyek csak bizonyos esemény bekövetkeztekor jelenik meg. Leginkább a JavaScript felugró ablakaira, és eseményeire hasonlít a funkciója. Ahhoz hogy használhassuk, egy külön névteret kell megadnunk hozzá: xmlns:ev="http://www.w3.org/2001/xml-events" . Ezek után érhet®ek el a funkciói, így például a "DOMFocusIn" akkor hajtódik végre, ha az adott beviteli mez® fókuszt kap, míg a "DOMActivate" akkor, ha rákattintunk (gomb esetén) vagy leenterezzük (szöveg mez® esetén). A JavaScript segítségével sokkal több lehet®ségünk nyílik a felhasználó gyelmeztetésére. Az XForms-al három féle lehet®ségünk van szöveget kiíratni a felhasználónak, a JavaScript alert(); függvényéhez hasonlóan. Minden szintnek megvan a maga "eltüntetési" nehézsége. 1. ephemeral: Ez az üzenet magától jelenik meg, és magától t¶nik el pár másodperc elteltével. Egy tooltip szer¶ üzenet, pl. egy gomb felé helyezve az egeret kapjuk meg. 2. modeless: Olyan üzenet, melyet a modell fában adunk meg. Megjelenése egyenérték¶ a JavaScript alert();-el 3. modal: Szintén egy alert();-en egyenérték¶ üzenet, melyet helyben adunk meg Az, hogy ezek az üzenetek mikor jelenjenek meg, arra szolgál az ev:event attribútum. Konvertálása során sok mindenre ooda kell gyelni, rengeteg feltétellel, és legtöbb esetben nem is valósítható meg teljesen egyenértém¶ módon. Az alábbi példában egy tooltip jelenik meg, mikor belekattintunk a beviteli mez®be. (Focus-t kap). Ilyen lehet®ségünk a HTML-ben nincs. <xf:input><xf:label>Ephemeral: <xf:message level="ephemeral" ev:event="DOMFocusIn"> Ez egy ephemeral típusú üzenet.

3.8. ábra. Felbukkanó üzenet: egy tooltip csak az XForms-ban A "DOMActivate" esemény és a modeless prezentálására egy beviteli mez®t hozok létre. Amikor lenyomjuk rá az entert, megjelenik a modell-ben látható szöveg. 31

3.3. Mintarendszer követelmények

<xf:model> <xf:instance> Ez egy modeless típusú üzenet, a modell fába van tárolva. ... <xf:input> <xf:label>Modeless felugró üzenet: <xf:message level="modeless" ref="uzenet" ev:event="DOMActivate"/> 3.3. Mintarendszer követelmények

A program PHP és JavaScriptet használ, így egy olyan környezet és böngész® szükséges az elindításához, mely képes lefuttatni. Ehhez használhatjuk az ingyenes XAMPP programot, mely egy virtuális Apache szervert hoz létre számítógépünkön, így képes lefordítani a PHP fájlt egy böngész®n. Megjegyezend®, hogy a PHP 5.1.0-ás verziója használandó! Egy egyszer¶sített konvertálóról lévén szó, rengeteg megszorítást kellett alkalmaznom, melyet be kell tartani a helyes m¶ködés végbemeneteléhez. El®szöris fontos, hogy az elemzett dokumentum legyen helyes, azaz feleljen meg minden XML szintaxis szabálynak. Például, egy elem rendelkezzen nyitó taggel és záró taggel is. Az a dokumentum, ami nem helyesen formázott, nem is tekinthet® XML-nek, az elemz®nek meg kell tagadnia a feldolgozását. Az XForms lehet bármilyen kiterjesztés¶, ennek útvonalát a PHP programon belül kell megadni, a $dom -> load('peldaxForms_1.xml'); résznél. Szakdolgozatom mellékleteként két ilyen xml kiterjesztés¶ XForms áll rendelkezésre, amihez két különböz® PHP konvertáló is társul (konvertalo_1.php és konvertalo_2.php) - egyéb megnyitandó dokumentumhoz a fájl módosítására lesz szükség. A konvertáló használatához a böngész®k közül a Firefox javaslott, ez alatt lett fejlesztve, de az Opera és Chrome böngész®kön is tökéletesen m¶ködik. Egyedül az Internet Explorer jelent problémát, ami alatt nem indul el az ActiveX objetumok nem támogatottsága miatt. Prexek: Az XForms elemek leírásához mindenképp szükséges egy névtér deniálása. A mintarendszer ezt csak akkor látja, ha a html elem részeként van megadva. A névtérnek, URL szerinti http://www.w3.org/2002/xforms -nek a w3.org 2002-es szabványát kell hogy tartalmazza. Ez azért is szükséges, mert ha a prexek deniálására a elemmel hivatkozunk, akkor gyelni kellene az XHTML vagy HTML prexeit is - ahhoz pedig rengeteg szabvány van elterjedve, rengeteg variáció léphet fel. Group elem ett®l függetlenül lehet a dokumentumban, akár az XForms prexxel ellátva is ekkor a keresést tovább mélyíti, de a benne deniált névtereket gyelmen kívül hagyja. XForms modellje: A modellnek a fájlban kell szerepelnie valahol. Az XForms szabvány alapján ezt a head részben kell deniálni. A modellnek mindenképp kell tartalmaznia legalább egy példányt - ez is szabvány szer¶en kötelez®. A példányosításon kívül lehetnek más, pl. bind elemek, de ezeket a generáló gyelmen kívül hagyja. Egy valós dokumentumban meg lehet adni több modell-t is, melyhez több form tartozik egy la-

32

3.4. Mintarendszer fejleszt®i környezet

pon, valamint a modelleket küls® er®forrásként megadni - ezek sincsenek megvalósítva, így tehát csak egy modell szerepelhet, melyre a dokumentumban szerepl® megjelenít® elemek mindegyikére illeszkednie kell. Egy olyan nézet-vezérl® elem, melynek ref attribútuma nem létez® modell elemre hivatkozik az szabálytalan, és nem elfogadott. A modell elem példányainak kinézetére nincs megkötés. Lehet üres elem, s®t hibásan beírt elem is. Például egy listából ha A,B,C választási lehet®ségünk van, meg lehet adni D-t is. Ez ugyan szabálytalan, de erre vonatkozólag hibat¶r®. Lehet®leg ügyeljünk arra is, hogy minden egyes elem tartalmazzon valamit, ugyanis üres elemek használata során hiba léphet fel (újra betöltés esetén). Nézet-vezérl® elemek: Ezeknek mind a részben kell szerepelniük. Az újabb böngész®k a helytelenül elembe beírt adatokat át is helyezia elem gyerekei közé. Mivel a group elem nem megengedett, hogy ideiglenesen felüldeniáljuk a névtereket, ezért minden olyan elemhez, amire az XForms vonatkozik, prex-el kell hogy ellátva legyen! Az ilyen elemeknek rendelkezniük kell továbbá a ref attribútummal is, mely a modell elemére mutat. Ez a ref szabvány szerint egy XPath kifejezés lehet, viszont az egyszer¶sítés végett csak egy elem nevet fogad el - ami lehet mélyebb szinten a fába. Ha ez az elem a modell-ben többször is szerepel, akkor a legels® találatra fog hivatkozni mindig. Minden XForms ¶rlapmegjelenít® elemnek megadható egy instance attribútum is, mely azt befolyásolja, hogy mikor történjen módosítás a modell-ben. Ez a mintarendszerben nem jelent változást, mivel az

elem által kiírt szöveg nem megvalósítható, helyette a modell fa exportálása van, ami akkor történik mikor a felhasználó arra rákattint. Stílus deníciót illet®en a style és egyéb formázások gyelmen kívül hagyódnak, ugyanis a részb®l csupán a <xf:model> <xf:instance xmlns=""> <szoveg>Daniel <pass>Daniel <mini>2 harom F Hosszu szoveg <xf:input incremental="true" ref="szoveg"><xf:label>Input mezo:
<xf:secret ref="pass"><xf:label>Jelszo:
<xf:select1 class="select1" appearance="minimal" ref="mini"> <xf:label>Mini valaszto <xf:item><xf:label>Egy<xf:value>1 <xf:item><xf:label>Ketto<xf:value>2
<xf:select1 ref="komp" appearance="compact"> <xf:label>Kompakt valaszto: <xf:item><xf:label>Egy<xf:value>egy <xf:item><xf:label>Ketto<xf:value>ketto <xf:item><xf:label>Harom<xf:value>harom <xf:item><xf:label>Negy<xf:value>negy
<xf:select1 class="select1" appearance="full" ref="full"> <xf:label>Valasszon <xf:item> <xf:label>Ferfi<xf:value>F <xf:item> <xf:label>No<xf:value>N


49

3.6. Tesztelés

<xf:textarea ref="Tszoveg"><xf:label>Tobb soros szoveg:


A dokumentumot az XForms-al való megnyitás után a 3.16. ábra mutatja.

3.16. ábra. Az XForms fájl kinézete eredetileg Most töltsük be a fájlt a konvertálóba, vagy írjuk át a PHP-ben a load függvényt. A kapott eredmény a következ®: <script src="jquery.min.js"> <script src="MVC.js"> <script type="text/javascript"> var IMPDATA="";

<xForms> <xf:instance> <szoveg>Daniel <pass>Daniel <mini>2 harom F Hosszu szoveg

    Példány:

0

/

0

Input mezo:
Jelszo:
Mini valaszto <select id="mini">Egy

50

3.6. Tesztelés

Ketto
Kompakt valaszto: <select id="komp" size="4">Egy Ketto Harom Negy
Valasszon Ferfi No
Tobb soros szoveg:



Importálandó file:

Helyenként sortörést és üres sor törlést hajtottam végre a jobb láthatóség miatt, valamint hogy kieférjen az oldalra. A generált kód kinézetét a 3.17. ábra mutatja.

3.17. ábra. Az XForms-ból generált HTML oldal Az adatokat sikeresen bemásolta, helyesen. Példányok közötti váltogatáshoz el®z®leg egy új példányt kell létrehozni: a gombra kattintás utána a navigátor "Példány: 2/2" -re váltott, és egy üres ¶rlapot kaptunk. A válsztólistákból az els® elem választódott ki, mint alapértelmezett elem. Azt hogy a modell-ben is megtörtént-e a változás, az Exportálásra kattintva tudhatjuk meg. A rákattintás után kiírta, hogy "Az exportálás sikeres, elérhet® az alábbi helyen: Exportált XML le . A linkre kattintva megjelenik a modell, a második példányát nézve üresen: <szoveg/><pass/><mini>1egyF

51

3.6. Tesztelés

A második példányt feltöltöm új adatokkal. A törlés teszteléséhez az eredetileg látható els® példányt törlöm. Egy rákérdezés után a törlés valóban végrehajtódott, a példány navigátor 1/1-et mutat. Létrehozok még egy példányt, feltöltöm, majd az így kapott modellt exportálom, és elmentem. A kapott modell: <xforms> <szoveg>ElsoUj <pass>nincs <mini>2 ketto N Ez egy tobb soros szoveg teszt <szoveg>MasikUj <pass>Nincs <mini>1 negy F Szoveg_2

Látható, hogy sikeres hozzáadódott az XML PI utasítás is, aminek eredményül struktúrált megjelenítést kaptunk a megnyitása során. Használjuk fel ezt ezt a le-t! Nyissuk meg újra a konvertálót, az eredeti egy példányos konverzióval, és akkor tallózzuk be ezt az XML le-t! A tallózásra kijelölt input mez®n a JavaScript sikeresen kivételt alkalmazott, nem próbálta a modellbe letárolni. Kattintsunk az importál gombra! Az oldal újratölt®dik, és az XML le adatai bekerülnek az oldalunkra! A navigátor helyesen 2 példányt jelez, és mind a kett®ben lév® adatok megegyeznek az XML-ben letároltakkal.

52

4. fejezet Összefoglalás

Szakdolgozatomban a kódgenerálást három összetev® alapján hajtom végre, mely a legtöbb mai programozás alapeleme. Ez a hármas a modell, a nézet, és a vezérl® - rövidítve MNV (vagy az ismertebb angol megfelel®jeként MVC). Ez a hármasság f®ként az internetes ¶rlapoknál található meg, ahol a nézet a megjelenített beviteli mez®k, a modell az amit a háttérben letárol az egyes értékekr®l, a vezérl® pedig az adatok elküldésér®l gondoskodik. Ez a hármasság nagyon jól szemléltethet® az évezred elején fejlesztett XForms-al, mely egy XML alapú ¶rlapleíró. Bonyolultsága és lassúsága miatt viszont nem terjedt el, de a programom megpróbálja ezen dokumentumokat alapul véve a ma is használatos HTML nyelvre alakítani. Az er®források növekedésével várhatóan az XForms is megjelenik egy új formában. Az átalakítást a két leggyakrabban használt webes nyelvvel, a PHP-vel és a JavaScripttel végzem el. Az XForms modell része nem csupán egy fogalom, hanem a fej részében le is van írva maga a modell kinézete XML formátumba, ami a hozzájuk kapcsolódó beviteli mez® megváltoztatásakor módosul is. Ezt a modellt kell átvenni, és olyan könyezetet biztosítani a HTML-ben, hogy képes legyen módosítani, valamint mivel egyszerre több példány is társulhat egy-egy modellhez, szükséges a navigáció megoldása is közötte: a példányok közötti váltogatás, törlés és új példány létrehozása. Ezen funkciók a generált kódban mindig elérhet®ek lesznek, igényes megjelenítés formájában. A nézet részben a beviteli elemek legtöbbje megtalálhatóak a HTML nyelvben is, csupán a megadására szolgáló elem neve más. A kódgenerálás során ezen elem neveket átírom a HTML-ben használatos megfelel®jére, attribútumaival együtt. Az XFormsban minden elemnek van egy ref nev¶ attribútuma, mely arra szolgál, hogy az adott nézet-vezérl® elemhez egy modell beli elemet társítson. Az utána álló kifejezés XPath formátumú lehet. A vezérlés az XFormsban egyrészt az adatok küldésével kivitelezhet®, másrészr®l egy speciális

elemmel is, mely összetett feldolgozásra is képes, eredménye a modell fán alapszik, és a nézet részben írja le. A kódgenerálás során egy új funkciót hozok létre a vezérlés megvalósítására, mely lehet®séget ad a munkamenetünk elmentésére, és visszatöltésére. Ez az export/import funkció nem más, mint a módosított modell fa kiírása, és betöltése.

53

4.0.1. English Summary

In my thesis, I introduce the tree component of the code generation, which the basic elements of the current programming. These tree are the model, the view, and the controller - abbreviated MVC. This trad can be nded mainly in Internet forms, where the view is the displayed input elds, the modell is in the background that stored by each eld, and the controller provide data sending. These tree can be illustrate very well with the XForms, what developed in the beginning of the millenium. That is an XML based form describer. Because of complexity and slow, it did not spread out, but my program try to convert to HTML language, which is mainly used language nowdays. With growing resources, the XForms may appear soon with a new shape. The converter made by the two commonly used programming language: PHP and JavaScript. Modell in XForms not only a concept, it is part of the description, and you can nd it the the head section. That modell will be changed every time when you modify an input eld in the document. That model must take, and provide and evironment in HTML, that can modify it, and because there can be more than one instance, a technique to change or delete a currently viewed instance, or create a new one. These methods will be available in every generated HTML code with well-designed visualization. In the view section, the input elds can be found in HTML language too, only the element's name is dierent. When generating a code, I transform these names to HTML based language with their attributes. In XForms, every element has a ref attribute, which serve to point a model element to this input elds. Its expression van be an XPath format. Controller in the XForms can be feasible with data sendig, that need <submission> element, and with a special

element too, which able to process a complex expression. That is based on the model tree, and the output wil lbe displayed in the view. With code generation, I made new functions to archive a controller section instead of these two options. It makes possibility to save and load your session. That export/inport function is a write and read of the modied model tree. My thesis can be read in Hungarian language, started with a theoretical explanation about XForms and MVC, after a documentation about the program works with gures and system plan. Finally, there is a reference, which mainly English pages.

54

Irodalomjegyzék

[1] Maximum PC online cikk - Surng Since 1991: The Evolution of Web Browsers http://www.maximumpc.com/article/features/web_browsers

[2] W3C - Document Object Model (DOM) http://www.w3.org/DOM/

[3] Fogas János - Grakus fejleszt®i felületek készítése

http://ganymedes.lib.unideb.hu:8080/dea/ bitstream/2437/4716/1/fogas_janos_szakdolgozat_2008.pdf

[4] IBM - Develop forms using the Visual XForms Designer

https://www.ibm.com/developerworks/library/x-xfrmdesigner/

[5] Hetei György - Webes ¶rlapok és az XForms ajánlás http://ganymedes.lib.unideb.hu:8080/dea/ bitstream/2437/96421/1/szakdolgozat.pdf

[6] O'Reilly xml.com - What Are XForms

http://www.xml.com/pub/a/2001/09/05/xforms.html

[7] Wikipédia

http://hu.wikipedia.org/wiki/Modell-nézet-vezérl® http://en.wikipedia.org/wiki/Model-view-controller

[8] MVC (csak a kép)

http://heim.ifi.uio.no/ ∼ trygver/themes/mvc/mvc-index.html

[9] Angol wikipédia

http://en.wikibooks.org/wiki/XForms

[10] W3C - XForms for HTML Authors

http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html

[11] Web Programming Step by Step (Lecture 16 - The DOM Tree) http://www.webstepbook.com/supplements/slides/

[12] W3C School - XML DOM cloneNode() Method

http://www.w3schools.com/dom/met_element_clonenode.asp

[13] W3C School - jQuery post() Method és hivatalos referencia http://www.w3schools.com/jquery/ajax_post.asp http://api.jquery.com/jQuery.post/

55

Adathordozó használati útmutató

A mellékelt adathordozó egy darab DVD, melyen megtalálható a szakdolgozat, a programkód, példa XForms oldalak, valamint a futtatási környezetet biztosító XAMPP program is. Szakdolgozat nev¶ mappában található a szakdolgozatom PDF-es és LATEX-es változata. A PDF fájl elérési útvonala szakdolgozat\szakdolgozat.pdf. A megnyi-

tásához egy PDF nézeget®re lesz szükségünk, a mint például a mellékleten található Foxit Reader. Ezt a programot a programok\PDF\FoxitReader5.exe helyen lehet elérni. A szakdolgozat LATEX szerkeszthet® fájl megnyitásához két programra lesz szükség: a MIKTEX-re (programok\PDF\basic-miktex-2.9.4521-x64.exe ) és a WINEDT-re (programok\PDF\winedt60.exe). Ezen programok legfrissebb változatához javasolt az internetet használva letölteni. A megnyitandó TEX le-t a szakdolgozat\ szakdolgozat.tex fájl tartalmazza. A szakdolgozatban felhasznált képanyagok a szakdolgozat \kepek\ mappában találhatóak, ESP formátumban.

A konvertáló futtatásához egy PHP-t értelmez® környezet szükségeltetik, valamint egy JavaScript képes böngész®. A PHP fájlt feltölthetünk egy szerverre is, mint pl. az Egyetemi szerver, vagy használhatjuk a mellékelt XAMPP programot, mely egy virtuális Apache szervert hoz létre számítógépünkon. Ennek a programnak a htdocs mappájába másolva a PHP le elérhet® lesz alapértelmezetten a 127.0.0.1 oldalon. A program itt található meg: programok\xampp-win32-1.8.1-VC9-installer.exe . Három példafájl található a mellékleten a programok\mintaprogram mappába. A PHP fájlok a konvertálók, és hozzá tartozik az azonos nev¶, de XHTML kiterjesztés¶ XForms le. Továbbá található két JS fájl, ami szükséges a környezetbe másoláshoz. • jquery.min.js: A JavaScript kiegészít® könyvjára • MVC.js: A konvertáló által használ JavaScript függvények • exportalo.php: Ez a lap ívódiik meg az exportálás folyamata során, és állítja

el® az exported.xml fájlt

• Fokonvertor.php, Fokonvertor_2.php : két példakonveráló, mely meghívja az

ugyanezen nev¶ XHTML kiterjesztés¶ forrás-fájlokat

• Fokonvertor_Minta.php : a szakdolgozat tesztelés részében használt konveráló (Fokonvertor_Minta.xhtml a forrás XForms)

56

A konvertáló teljesen m¶köd®képes változta jelenleg megtalálható a http://users.iit.uni-miskolc.hu/ ∼burunkai/full/ weboldalon. Az XForms fájlok megnyitásához régebbi rendszer és böngész® szükségeltetik kiegészít®vel. Egy WindowsXP, Firefox 3.5-el, és XForms kiegészít®vel ellátva helyes megjelenítést kapunk. Ezek megnyitásához a VMware által kívánt virtuális számítógép létrehozását választottam, melyre telepítettem a Firefox ezen változtát és a plug-int. A DVD mellékletnek sem a Windows XP rendszer, sem pedig a VMware program nem része, de a Firefox 3.5-ös változata és a hozzá tartozó XPI kiegészít® igen. • programok\Firefox Setup 17.0.1.exe : A Firefox jelenlegi legújabb változata,

mellyen megjeleníthet® a PDF fájl

• programok\firefox-3.5.19.exe: A Firefox 3.5-ös változata, melyhez található

XForms plugis, én megjeleníthet® vele az XForms duokumentum

• programok\xforms-0.8.7pre-ff3.5.xpi : A Firefox 3.5-ös változatához szüksé-

ges kiegészít®. Indítsuk el a böngész®höz társítva!

57