A webprogramozás alapjai
A webprogramozás alapjai jegyzet
Dr. Medzihradszky Dénes azonos címő fıiskolai jegyzetének felhasználásával és kiegészítésével készítette Dr. Kopácsi Sándor
1
A webprogramozás alapjai Tartalomjegyzék: 1
Bevezetés ...................................................................................................................... 3
2
1.1 A tantárgy célkitőzése ............................................................................................ 3 1.2 Követelmények...................................................................................................... 4 1.3 Az Internet és a web kialakulása, története.............................................................. 4 1.4 Nyílt forráskódú szoftverek, szabad szoftverek ....................................................... 6 1.5 A World Wide Web Konzorcium (W3C)................................................................ 7 1.6 W3C javaslatok...................................................................................................... 8 1.7 Ellenırzı kérdések/feladatok................................................................................ 10 Web szerverek mőködése, a szerver oldal ................................................................. 11
3
2.1 Virtual hosting..................................................................................................... 11 2.2 Az Apache projekt ............................................................................................... 13 2.3 Erıforrások azonosítása, URL, URI ..................................................................... 14 2.4 Szerver oldali programnyelvek ............................................................................. 18 2.5 Ellenırzı kérdések............................................................................................... 19 Kommunikáció a kliens és a szerver között............................................................... 20
4
3.1 Az OSI modell és rétegei...................................................................................... 20 3.2 Az OSI modell megvalósulása TCP/IP esetén....................................................... 22 3.3 TCP/IP ................................................................................................................ 23 3.4 HTTP .................................................................................................................. 25 3.5 Ellenırzı kérdések............................................................................................... 27 Web alkalmazások tervezése, megvalósítása ............................................................. 28
5
4.1 Honlapok, webhelyek, portálok ............................................................................ 28 4.2 Dizájn és áttekinthetıség...................................................................................... 29 4.3 Navigálás............................................................................................................. 29 4.4 Ellenırzı kérdések............................................................................................... 30 Leíró nyelvek.............................................................................................................. 31
6
5.1 HTML ................................................................................................................. 33 5.2 XHTML .............................................................................................................. 35 5.3 XML ................................................................................................................... 83 5.4 Ellenırzı kérdések............................................................................................... 86 A JavaScript nyelv alapjai ......................................................................................... 87
7
6.1 A nyelv szerepe ................................................................................................... 88 6.2 JavaScript a weboldalon....................................................................................... 89 6.3 Dokumentáció...................................................................................................... 91 6.4 Nyelvi elemek...................................................................................................... 92 6.5 Őrlapok és JavaScript......................................................................................... 103 6.6 Ellenırzı kérdések............................................................................................. 105 Stílusok, stíluslapok ................................................................................................. 106
8
7.1 A stíluslapok szintjei.......................................................................................... 108 7.2 Stíluslapok hierarchiája ...................................................................................... 110 7.3 Stíluslap formátumok......................................................................................... 111 7.4 CSS szelektorok................................................................................................. 113 7.5 CSS deklaráció .................................................................................................. 119 7.6 Ellenırzı kérdések............................................................................................. 136 Irodalomjegyzék, referencia táblázatok, szabványok ............................................. 137
2
A webprogramozás alapjai
1 Bevezetés
1.1 A tantárgy célkitőzése A tantárgy célja, hogy a különbözı informatikai háttérrel rendelkezı hallgatóknak elméleti áttekintést adjon a webes információ-továbbítás technikáiról és a webes információ prezentálás korszerő módszereirıl, a dinamikus webes alkalmazásokról és azok fejlesztési kérdéseirıl. Az elméleti ismeretek mellett a tantárgy nagy súlyt fektet a gyakorlati készségek elsajátítására, az alkalmazástervezésre és felépítésére, a számításban vehetı eszközökre és azok megfelelı alkalmazására. A tantárgy oktatása során az elıadások keretében feldolgozott alapvetı webes ismeretek kiterjednek a web szerverek mőködésétıl kezdve a webes technológiák során használatos leírónyelvek és a legfontosabb kliens oldali programnyelv megismerésére is, valamint a ma egyre népszerőbb stíluslapok használatára Az alkalmazástervezés, fejlesztés után érdeklıdı hallgatóknak az alapismeretek elsajátításán túl lehetıséget kívánunk biztosítani a több számítógépen futó alkalmazások, rendszerek alapjainak megismerésére, a gyakrabban alkalmazott módszerek ismeretére. Gyakorlati példákon keresztül tipikus technológiákat mutatunk be, kliens oldalon elsısorban a JavaScript nyelv nyújtotta lehetıségek körébıl. A dokumentumokat formailag leíró nyelveken túl tárgyalásra kerülnek olyan alapismeretek is, mint például az XML nyelv és technológia. Ennek központi szerepe van a korszerő informatikai megoldásokban, legyenek azok elektronikus ügyviteli portálok vagy egyszerő szabványos dokumentumok. A szerver oldalon alkalmazható technológiákat a tantárgy keretében csak ismereti szinten sajátítják el a hallgatók, azok készség szintő megértése és alkalmazása további specializált tantárgyak keretében történik.
3
A webprogramozás alapjai
1.2 Követelmények A tananyag elsajátításához elengedhetetlenek a következık: Számítástechnikai alapismeretek, a számítógépes hálózatok mőködésének alapjai, valamint dokumentumkezelési alapok és készségek. A tantárgy során programozási feladatok megoldására kerül sor, ezért elıny a C-típusú programnyelvekben (C, C++, C#, Java ) szerzett programozási jártasság, az objektum fogalmának ismerete és az objektumok kezelése, alkalmazása. Sok esetben hivatkozunk az Interneten fellelhetı részletes dokumentációkra, forrásokra, például a leírónyelvek, a webes technológiák szabványaira, az ezekkel kapcsolatos ajánlásokra. A hivatkozott weboldalakon való tájékozódáshoz elengedhetetlenül szükséges az angol nyelv minimum olvasásimegértési szintő ismerete. Ismertnek tételezzük fel a Programozási alapok és a Vizuális programozás tantárgyakat, az ismétlések elkerülésére gyakran történik hivatkozás a tantárgy tankönyveiben fellelhetı ismeretekre.
1.3 Az Internet és a web kialakulása, története Az Internet nem más, mint az Amerikai Védelmi Minisztérium kutatóintézetében (Advanced Research Project Agency, ARPA) a hatvanas években kifejlesztett távolsági számítógép-hálózat, amely 1969 decemberétıl állt az egyetemek és a kutatóintézetek rendelkezésére. Az Internet azóta óriási változáson ment keresztül, legalábbis ami kiterjedtségét, gyorsaságát, illetve tartalmát illeti. Kiterjedtségének drasztikus növekedése hátterében – ami az elmúlt 10 évet öleli fel – a számítógép-hálózatok fejlıdése áll, hiszen az Internet tulajdonképpen számítógépek hálózata, az internetes tartalom pedig az ezeken a számítógépeken tárolt információk összessége. A World Wide Web (WWW) egy független projektnek indult az 1990-es évek elején az Európai Nukleáris Kutatási Szervezetnél (CERN), Genfben, ahol akkor Tim BernersLee dolgozott és az ı agyában született meg az ötlet egy olyan világmérető információs bankról, amely az akkor már létezı Internet, mint szuperhálózatot hardverként használva lehetıvé tenné praktikusan végtelen mennyiségő információ elhelyezését és elérését. Az Internet hálózatába kötött számítógépek kommunikációja az IP-cím alapján – ami az egyes számítógépeket egyértelmően azonosítja –, és a http protokoll segítségével – ami a számítógépek közötti kommunikációs szabvány – történik. 4
A webprogramozás alapjai Internet cím, IP-cím: a számítógépekhez rendelt azonosítót IP-címnek (IP address) nevezzük. Az IP-cím egy 32 bites szám, amelyet a leggyakrabban az úgynevezett pontozott tízes formában (dotted decimal form) írunk le, azaz négy darab 0 és 255 közötti decimális számmal. Például: 62.213.7.84. Ez alapján egyértelmően azonosítható egy számítógép az interneten. Mivel az IP-címek emberi fogyasztásra teljesen alkalmatlanok (legalábbis nehezen memorizálhatóak), ezért szükség volt valami olyan azonosító megalkotására, amely az IP-címre épülve, tulajdonképpen ehhez kapcsolódóan névvel látja el az interneten elérhetı, információkat tároló számítógépeket. Kialakították tehát a domén-neveket, amelyek általában értelmesebb rövidítések (például: gdf.hu). A domén-nevek felépítésénél ugyanúgy szükség volt az egyértelmő azonosíthatóságra, mint az IP-címek esetében. Ezért országjelzéssel és az adott szervezet megjelölésével is ellátták, a kettıt pedig egy pont választja el egymástól. A gépek IP-címeinek domén-névhez rendelését úgynevezett névszerverek végzik. Domén (domain): részterület vagy címterület, önálló, betőkkel jelölt részterület az interneten. Ennek a könnyebben olvasható és értelmezhetı névrendszernek hátterében a gépek számára érthetı IP-címrendszer áll. Az ilyen címterületek ismertetı jele a címben olvasható .hu, .de, .ch országkódok, vagy az .edu, .gov, .com stb. szakterületi rövidítés. A 90-es évek elejére tehetı az internet olyan mértékő elterjedése, ami már lehetıséget adott kereskedelmi célok megvalósítására. Innen ered az Egyesült Államok-béli domén nevekben a .com végzıdés, ami a commercial (kereskedelem) szóból származik. Az amerikai kormányzat például .gov (government = kormányzat), a felsıoktatás pedig .edu (education = oktatás) végzıdéső domén-neveket használ. A legelterjedtebbek mellett ma már lehetıség nyílik arra is, hogy magánszemélyek is bejegyeztethessék saját domén neveiket, végzıdésre való korlátozás nélkül. A domén név bejegyzéseket központilag tartják nyilván, egy világmérető „domén bankban”. Ha például holnaptól saját domén név alatt szeretnénk publikálni az Interneten, választhatjuk a következı nevet: „kattints.ide”, vagy „kovacs.hajnalka.hu” – feltéve, hogy a domén név még nem foglalt, vagyis még nem regisztrálta elıttünk más. A regisztráció körül kialakult problémákból adódóan évekkel ezelıtt elindult a domén nevekkel való kereskedés, ami egyesek számára gyümölcsözı üzletággá nıtte ki magát. Például ha valaki a britneyspears.com domén nevet mondjuk 10 évvel ezelıtt bejegyeztette volna, mára dollármilliókat kérhetne érte. 5
A webprogramozás alapjai A példaként leírt címben a már ismert domén néven kívül megtalálható a „WWW” rövidítés, amely az Internet legsokoldalúbb szolgáltatása, a World Wide Web rövidítése. A „WWW” rendszerben minden dokumentumot vagy más objektumot az URL, vagyis az univerzális forrásazonosító jelöl. A „http” (HyperText Transfer Protocol) a World Wide Web szolgáltatók egymáshoz és a felhasználókhoz való kapcsolásához használt rendszer, kommunikációs szabvány. A http szabvány segítségével tudunk az Interneten böngészve számítógépünkre dokumentumokat, weboldalakat letölteni, majd ezeket a böngészınk automatikusan – külön utasítás nélkül – meg is jeleníti.
1.4 Nyílt forráskódú szoftverek, szabad szoftverek Az Internet – érthetı módon – elıször az amúgy is számítógéppel foglakozók körében vált népszerővé. A kezdetekben nem álltak még rendelkezésre a grafikus felülető böngészık, így az egyszerő http kliensek mőködtetése némi szakértelmet igényelt, a számítógép felhasználók pedig sokszor a saját igényeiknek megfelelıen alakították a netet. Így nem meglepı, hogy az elsı kommunikációk tárgya maga a számítógép, a szoftverek voltak és az elsı információcserék szinte kivétel nélkül a szigorúan vett felhasználók érdeklıdésének megfelelı volt. Egymás segítése sokszor vezetett szoftvercserékhez, amit egy-egy lelkes programozó megszerkesztett a saját használatára, hamarosan a terülten dolgozók köztulajdona lett. Mivel az Internet elsı felhasználói egyetemek, kutatóintézetek voltak, a többi tudományágban megszokott nyíltsággal cserélték ki az információkat, az eszközöket. Így keletkeztek a nyílt forráskódú, publikus szoftverek, ahol a szerzık pont azzal a céllal publikálták a forrást is, hogy az majd valaki tovább építheti, bıvítheti és így az eredeti szerzı is egy jobb változathoz juthat az idık során. Hasonló elveken alapultak az Internetet mőködtetı elemek, a kliensek, a web szerverek, így végül nem csoda, hogy az olyan alapvetı eszközök, mint például az Apache web szerver nyílt forráskódban terjedtek. Az sem volt egy utolsó szempont, hogy mivel a forráskód lefordítása és a mőködı szoftver elıállítása azon a gépen történt, amelyen a futtatására sor került, lehetıség nyílt a géphez a lehetı legjobban illeszkedı futtatható változatot elıállítani. Ezzel szinte minden gépen egyedi szoftver született, amely maximálisan ki tudta használni az adott gép hardver lehetıségeit.
6
A webprogramozás alapjai Ennek jelentısége ma már erısen csökkent, a nagysebességő processzorok, a bıven és olcsón rendelkezésre álló memória miatt, de a szabadon felhasználható, nyílt forráskódú szoftverek – amelyek ma már szinte kivétel nélkül elérhetık úgynevezett bináris disztribúcióban – megmaradtak és jelentıségük a Linux terjedésével szintén növekszik.
1.5 A World Wide Web Konzorcium (W3C) A W3C megalapítására 1994 októberében került sor Tim Berners-Lee vezetésével, azzal a céllal, hogy a web ki tudja használni az összes lehetıségét közös protokollok és nyelvek kifejlesztésével. Az alapítók együttmőködést hoztak létre a Massachusetts Institute of Technology (MIT) és a European Organization for Nuclear Research (CERN) között, amely együttmőködést nagymértékben támogatta az U.S. Defense Advanced Research Project Agency (DARPA) és az Európai Közösség is. Ehhez késıbb számtalan új tag csatlakozott, ma a tagok száma több százra tehetı1. A közös protokollok és nyelvek biztosítják a web töretlen fejlıdését és a kifejlesztett standardok teszik lehetıvé az általános használatát, a különbözı böngészık és web szerverek együttmőködését. A W3C egy úgynevezett tagi szervezet, a tagok hozták létre és mőködtetik. Ez a szervezeti mód biztosítja, hogy egyetlen szervezet se nyerjen teljes kontrollt a web fölött, annak fontosságára való tekintettel. Tag nagyjából bármely szervezet lehet, egyetemek, kutatóintézetek, gazdasági szervezetek. A fı tevékenységi terület a web standardizálása, bár fontos megjegyezni, hogy itt nem kötelezı standardokról van szó, hanem inkább ajánlásokról. Egész pontosan nem is standardokról, hanem ajánlásokról (recommendations) beszélünk. Ennek betartása nem kötelezı, de mivel az összes számottevı szoftverfejlesztı cég is tagja a W3C szervezetének, az általuk közösen megfogalmazott ajánlások betartása számukra is célszerő, ha a web lehetıségeit maximálisan kihasználni tudó alkalmazásokat kívánnak kifejleszteni. A W3C céljai között szerepel, hogy a web minden felhasználó számára hozzáférhetı legyen, tekintet nélkül a kulturális, képzettségi, képességi és erıforrás különbségekre. A célok között az is szerepel, hogy a web egyaránt használható legyen olyan személyek
1
http://www.w3.org/Consortium/Member/List
7
A webprogramozás alapjai számára, akik különbözı fizikai korlátokkal rendelkeznek, mint például csökkent látóképesség. Munkája során a W3C több más standardokkal foglakozó szervezettel is kapcsolatot épített ki, mint például az Internet Engineering Task Force, befogadta és terjeszti a Wireless Application Protocols (WAP) Forum javaslatait és együttmőködik az Unicode Consortiummal is. A W3C szervezetének jelenleg három intézmény ad otthont, ezek a következık: −
Massachusetts Institute of Technology az Egyesült Államokban.
−
A Francia Nemzeti Kutatóintézet Európában
−
Keio Egyetem Japánban
1.6 W3C javaslatok A W3C által végzett legfontosabb munka a webspecifikációk (úgynevezett Recommendations, magyarul javaslatok) kidolgozása, ezek az alkalmazott nyelveket vagy a megfelelı protokollokat is jelenthetik. Általában idetartozik minden építıelem, amit a webfejlesztés során felhasználhatunk. Ezeknek kifejlesztése egy jól bevált eljárás keretében történik, amelynek lépései a következık: − a W3C-hoz benyújtásra kerül egy javaslat, ami többnyire egy jól megalapozott ötlet valamely területen; − a W3C egy Feljegyzést publikál, amely alapján a tagok áttanulmányozzák a javaslatot − a W3C létrehoz egy Munkacsoportot, amely tagokból és meghívott szakértıkbıl áll. A munkacsoport meghallgatja különbözı társaságok és társszervezetek véleményét, megvitatja az így beérkezett javaslatokat és létrehoz egy Munkapéldányt; − a W3C publikálja a Munkapéldányt; − amennyiben jelentıs új javaslatok nem érkeznek be, a W3C egy Javaslat jelöltet állít elı és közzéteszi; − ebbıl a W3C egy Javaslat tervezetet állít össze és benyújtja a tagságnak és az igazgatónak jóváhagyásra; − a tagság és az igazgató formális jóváhagyásával a W3C publikálja az új Javaslatot.
8
A webprogramozás alapjai Így végül, amíg a W3C publikál egy új web standardot (javaslatot) látható, hogy a specifikáció az egyszerő ötlettıl kiindulva egy nagyon alapos kidolgozáson és jóváhagyáson ment keresztül. A kidolgozók többnyire azok a szoftverfejlesztık és weborientált cégek, egyetemek, kutatóintézetek, amelyek számára létkérdés az új webstandard elfogadása és betartása. Nem csak ilyen nagyléptékő ajánlásokat tesz a W3C, ajánlásai sokszor tipp jellegőek és szórólapokon is megjelennek. Az egyik ilyen ajánlás az úgynevezett Web Accessibility Initiative, azaz Web Hozzáférhetıségi Kezdeményezés, amelynek célja, hogy weboldalunkat mindenki számára tegyük elérhetıvé. Ennek rövid összefoglalója a következı2: Képek és animációk: Használjuk az alt attribútumot a képi információk szöveges leírására. Képrégiók kezelése: Használjunk kliens-oldali régiómegadást (a map teg segítségével) a kiemelendı képrészletekhez és társítsunk ezekhez szöveges leírást. Multimédia: Tegyük elérhetıvé az audio anyag szöveges változatát (feliratos formában és külön állományként is), a videó anyagokról pedig készítsünk leírást. Hivatkozások: A hivatkozás szövegezése legyen olyan, hogy a szövegkörnyezetbıl kikerülve is utaljon a hivatkozás céljára. Kerüljük például a kattints ide típusú linkeket. Oldalszerkezet: Használjunk fejlécet, listákat, és következetes struktúrát. Amennyiben lehetséges, használjunk CSS-t a szerkezet és a stílus leírásához. Grafikonok és diagramok: Készítsünk kivonatot, vagy használjuk a longdesc attribútumot. Szkriptek, appletek és plug-inek: Nyújtsunk alternatívát arra az esetre, ha az aktív elemeket a böngészı nem támogatja. Keretrendszer: Használjuk a noframes elemet és a tartalomra utaló keretneveket. Táblázatok: Készítsünk olyan megjegyzéseket, amelyek a sorról-sorra olvasáskor a megértést segítik, valamint készítsünk összegzést a táblázatok tartalmáról.
2
Az egyes fogalmakat majd a teljes anyag elsajátítása során tisztázzuk, itt inkább az ajánlások átfogó
jellege a figyelemre méltó. A teljes kezdeményezés megtalálható a www.w3.org/WAI/ oldalon.
9
A webprogramozás alapjai Ellenırizzük le a munkánkat. Használjunk ellenırzı eszközöket, kérdıíveket és a részletes útmutatókat.
1.7 Ellenırzı kérdések/feladatok Mi a W3C szerepe az Internet fejlıdése szempontjából? Mit jelent egy W3C Javaslat? Keressen a W3C weboldalán javaslatokat a HTML, XHTML és a CSS témában! Mit tartalmaz a Web Hozzáférhetıségi Kezdeményezés?
10
A webprogramozás alapjai
2 Web szerverek mőködése, a szerver oldal Az Internetes weboldalak esetében a kliens számítógép (ezen fut a böngészınk) egy-egy fájlt kér le, annak az egész Internetes hálózaton egyedi azonosítója alapján. Ezt a fájlt, pontosabban annak HTML nyelven kódolt forrását a megfelelı web szervert üzemeltetı számítógép fogja elküldeni. Bár egyszerő szöveges fájlról van szó, ez azonban számunkra szinte érthetetlen. A kliens gépünkön futó böngészıprogram viszont értelmezni tudja a kódokat és a készítıje szándéka szerint megjeleníti az oldalt. Vannak olyan esetek is, ahol nincs kódolás, ilyenkor a böngészı, a kliens intelligenciáján múlik, hogy meghívja a megfelelı olvasóprogramot (például Word vagy más hasonló dokumentumszerkesztı) és megjelenítse a kért dokumentumot. Minden más esetben, ha ez az intelligencia nem került beépítésre, a böngészı automatikusan letöltésre kapcsol és az URL alapján azonosított fájl letöltését kínálja fel a kliensgépre. Innét már a felhasználó egyéni döntése, hogy mi történik a következıkben a letöltött állománnyal, milyen alkalmazást, szoftvert használ az állomány megjelenítésére, megtekintésére.
2.1 Virtual hosting A HTTP protokoll magába foglalja a virtuális gép fogalmát, ahol egyetlen HTTP szerver több gazdagépet is képviselhet ugyanazon IP címen. Egy DNS szerver számos különbözı gazdagép nevet (domén nevet) rendelhet hozzá ugyanazon IP címhez. Amikor egy HTTP kliens adott gazdagépnek kérést küld, a DNS szervert használja fel arra, hogy a domén névnek megfelelı IP címet megtalálja és a kérést erre az IP címre küldi. A HTTP/1.0 protokollban a domén név nem került bele a HTTP üzenetbe, ez elveszett, miután az IP címet feloldotta a DNS szerver és ezt megküldte a kliens gépnek. Ez tehát azt jelentette, hogy ha egynél több erıforrás helyezkedett el az IP cím által azonosított szerveren, a szerver nehézségekbe ütközött volna, hogy beazonosítsa, melyik erıforrás készlet melyik domén névhez tartozik. 11
A webprogramozás alapjai Azonban a HTTP/1.1 kérések továbbítják a domén nevet is a kérésben (általában ez egy Host fejlécben történik). Így a domén név jelenléte az üzenetben képessé teszi a HTTP szervert arra, hogy a különbözı gazdagép/domén neveket tartalmazó kéréseket a megfelelı erıforráshoz irányítsa minden egyes gazdagép/domén esetében. A HTTP ezen képességét nevezzük virtuális gazdagépnek.
Web szerver felépítése A fentebb vázolt felállás egy speciális kliens-szerver rendszer, ahol a rendszer két összetevıjének tevékenységi köre - bár kliensbıl akárhány lehet, ezek mind ugyanazt képesek elvégezni - szigorúan meghatározott. Az ábrán jól látható az is, hogy a web szerver, - amennyiben nem egyszerő oldal lekérésrıl van szó – a megfelelı üzleti logika alkalmazásával dinamikusan reagálni is képes az egyes kérésekre, az elküldött adatok, vagy más külsı tényezı figyelembe vételével. Az egyik, leggyakrabban használt web szerver jelenleg az Apache web szerver, ismerkedjünk meg ennek rendkívül érdekes hátterével is.
12
A webprogramozás alapjai
2.2 Az Apache projekt Az Internet kialakulásakor a hálózat szervereit futtató gépek szinte kizárólag úgynevezett nagygépek voltak, mainframe komputerek, amelyek az egyéb feladatok mellett felvállalták a levelezés és a webhelyek tárolásának feladatait is. Ezek UNIX, majd késıbb Linux alapon dolgoztak és logikus volt, hogy az elsı webszervereket ezekre az operációs rendszerekre készítették el. Maga a honlap (home page) neve is abból származott, hogy ezek az intézményi szintő nagygépek egy-egy, több lapból álló, de mégis egyetlen webhelyet tartottak fent, amelynek indítólapja volt az angol tartalomjegyzék szóból származó nevő index.html fájl. A UNIX, majd Linux filozófiának fontos eleme volt a szabad hozzáférhetıség és általában nyitott a szabad szoftverek világa felé. Ennek következtében számos fejlesztés végeztek (szoftverek, osztályok és csomagok) különbözı nyitott projektek keretében. Ezek talán legismertebbje az Apache projekt. Kezdetben volt az Apache web szerver3, a web szerverek ısatyja és még ma is életképes leszármazottja. Ennek elterjedésével elıször modulok, eszközök készültek hozzá, szintén a szabad szoftverek leveinek megfelelıen (GNU licenc) majd a fejlesztıcsapat nagyobb lélegzető vállalkozásba fogott és létrehozta a web szerver nevével fémjelzett projektet. Ez ma már hatalmasra nıtt, jelenleg közel 30 Apache projekt létezik az Apache Software Foundation keretén belül (www.apache.org). Egyes projektek a fejlıdés során kikerülnek a rendszerbıl és saját útra térnek, ilyen például az XML feldolgozáshoz szükséges Javás eszközöket kifejlesztı Xerces projekt is. Az Apache Software Alapítvány (ASF) szervezeti, jogi és pénzügyi támogatást biztosít nyílt szoftver projektek széles körének. Az Alapítvány jól megalapozott keretet biztosít a szellemi tulajdonhoz és a pénzügyi támogatásokhoz, amelyek egyidejőleg csökkentik a résztvevık potenciális jogi szerepét. Együttmőködı fejlesztési folyamatban az Apache projektek kereskedelmi szintő, szabadon hozzáférhetı szoftver termékeket hoznak létre, amelyek a felhasználók nagy közösségét vonzzák. A pragmatikus Apache licenc az
3
Nevének több magyarázata létezik. Az egyik szellemes magyarázat szerint semmi köze sincs a híres
indián törzshöz, hanem az "a patchy server" szavakból lett összevonva és kissé átalakítva. Azaz olyan szoftvert jelöl, amely modulokból, "foltokból" áll.
13
A webprogramozás alapjai összes, gazdasági és egyéni felhasználónak egyszerővé teszi az Apache termékek telepítését. Korábban ezt a szervezetet mint az Apache Csoportot ismerték, de az Alapítvány tagsági alapon szervezıdött, non-profit társaságként lett regisztrálva annak érdekében, hogy az Apache projektek az egyénileg vállalkozó önkéntesek közremőködési lehetıségein túl is mőködıképesek legyenek. Azok az egyének, akik kimutatták elkötelezettségüket az együttmőködés keretében végzett nyílt forráskódú szoftverfejlesztésre az alapítványi projektekben, tagságot nyerhetnek az ASF-ben. Az egyén akkor kaphatja meg a tagságot, ha a már meglévı tagok többsége jelöli ıt és jóváhagyja a kinevezését. Így az ASF-t az a közösség irányítja, amelyet közvetlenül szolgál – a projektjein belül együttmőködı személyek.
2.3 Erıforrások azonosítása, URL, URI Az egyik legfontosabb kérdés az erıforrások egyedi azonosítása a hálózatos rendszerekben, így például az Interneten. Általánosságban ez az URI (Universal Resource Identifier) alapján történik, amely alatt bármely olyan karakterláncot értünk, amely egy erıforrás azonosít. Ennek speciális megvalósítása az URL (Uniform Resource Locator), amely létezı erıforrást azonosít a hálózaton annak elhelyezkedése (címe) alapján. Belátható, hogy a hétköznapi gyakorlatban a kettı egymástól nem független és ezért bárhogy nevezhetnénk, de szakmai szempontból megkülönböztetjük az erıforrás azonosítót és annak helyét, hiszen az esetek jelentıs részében nem annak helye, hanem az erıforrás maga a lényeges. A hely pedig bármikor megváltozhat, de nagy gondot okozna, ha emiatt nem találnánk meg az erıforrást. Az URI és az URL koncepcióját az Internet Társaság és az IETF (Internet Engineering Task Force) RFC 2396 azonosítószámú dokumentuma rögzíti, ezen belül az Uniform Resource Identifiers (URI) általános szintaxisát Internethez méltó módon a következı URI azonosítja: http://www.ietf.org/rfc/rfc2396.txt. Egy URL a HTTP (vagy HTTPS) esetében általában három vagy négy elembıl áll: Protokoll (schema): A protokoll azonosítja azt a szabályrendszert, amelyet az erıforrás eléréshez használni kell az Interneten. Ez leggyakrabban a http protokoll, amely SSL nélkül nem biztonságos, vagy a HTTPS protokoll, amely már magába foglalja az SSL-t is. A legtöbb banki rendszer csak biztonságos, HTTPS kapcsolaton át érhetı el. 14
A webprogramozás alapjai Gazdanév vagy domén név (host): Ez azonosítja azt a gazdát (host), amely az erıforrást tárolja. Ilyen lehet például a www.weblabor.hu. A gazda nevében egy szerver biztosítja a szolgáltatásokat, de a gazda és a szerver között nem szükségszerő az egy-azegyben való megfeleltetés. Adott szervergépen, amelyet az IP cím alapján találunk meg a neten, több gazda, azaz domén is elhelyezkedhet. Erre kiváló példa a webhely üzemeltetés, amikor bárki elhelyezheti saját tárhelyét egy szolgáltató szerverén a megfelelı díjazás ellenében, de nem minden doménhez tartozik egyedi szervergép. A medzi.hu, az sdp-city.hu, a pepint.hu, a stylo.hu, a brusszelimagyarok.com és még sok másik domén például fizikailag mind a 82.79.96.173 IP címmel azonosított számítógépen található. A http kéréseket a gazdagép a 80-as porton, vagy kapun fogadja. Ezt a böngészı alapértelmezettnek kezeli, azaz a http kéréshez automatikusan hozzáteszi a megfelelı portszámot. Amennyiben más kaput rendeltünk a web szerverhez, vagy más szolgáltatást akarunk használni, a portszámot meg kell adni az URI/URL-ben. Egy Java alapú web szerver, az Apache Tomcat a kéréseket például a 8080-as porton fogadja, a nagyon népszerő MySQL adatbázis kezelı pedig a 3306-os kapun fogadja a kéréseket. Elérési út (path): A domén név vagy gazdanév egy adott könyvtárat, a gyökérkönyvtárat azonosítja a szerver számítógépen. Ettıl a könyvtártól kiindulva az elérési út azonosítja azt a specifikus erıforrást – például weboldalt – amit el akarunk érni. Ennek megadása teljes mértékben megegyezik a számítógépek elérési útjainak megadásával, így mindenki számára ismertnek tételezhetı fel. Lekérdezési karakterlánc (query string): Valójában nem is lekérdezésrıl van szó, hanem a http kéréshez tartozó adatok helye. A HTTP protokoll a lekért erıforrások mellett adatok átvitelére is képes, ezeket az adatokat a megcímzett erıforrás kapja meg és szerveroldalon feldolgozhatók. Az egyszerő protokoll csak karaktersorozat formájában tudja szállítani az adatokat, egészen pontosan név-érték párok formájában. Az ezekbıl összefőzött, továbbításra kész karakterlánc a lekérdezési karakterlánc, amely az URI-hoz kapcsolva látható a böngészı lokátor sorában (címsorában) is. Szerkezete szigorúan rögzített, az erıforrás azonosítótól a kérdıjel karakter választja el, és az egyes név-érték párokat az angol "and" karakter, a & választja el. Így az URI/URL könnyen feldolgozható, a ? mentén szétszedhetı adatokra és erıforrás azonosítóra, majd az adatokat képviselı karakterlánc szétszedhetı név, érték párokra és átadható a kért erıforrásnak. Ilyen adattovábbítás mőködik például egy Google keresésénél, figyeljük 15
A webprogramozás alapjai meg, hogyan alakul ki a lekérdezés egy egyszerőbb részletes keresésnél. Az alábbi URL egy adatokkal kiegészített kérés, három adat kerül továbbításra, egy webhely azonosító, egy keresés azonosító és egy "from" nevő adat, amely azt tartalmazza, honnét érkezett az illetı az oldalra: http://www.designers.hu/request.php?SiteID=11&SearchID=26&from=google A szabályos teljes URI/URL tehát a következı elemekbıl épül fel: protokoll: http:// protokoll + domén név: http://akarhol.hu protokoll + domén név + portszám: http://akarhol.hu:8080 protokoll + domén név + portszám + elérési út: http://akarhol.hu:8080/fomappa/almappa/fooldal.html protokoll + domén név + portszám + elérési út + lekérdezési karaktersorozat: http://akarhol.hu:8080/fomappa/almappa/fooldal.html?nev=Hugó&allatfaj=viziló Hosszabb weboldalak a jobb tájékozódás érdekében szegmentálhatók. Ebben az esetben az egyes részek egyedileg is azonosíthatóak úgynevezett horgonyok (anchor) segítségével és ez az URL-ben is jelölhetı a kettıs kereszt használatával az alábbi módon: http://budapestzoo.hu/allatok/fooldal.html#vizilo Ebben az esetben a fenti weboldalra jutó látogató nem az oldal tetejét látja a böngészıben, hanem a böngészı rögtön a hosszú weboldal aljára, a vízilovakhoz ugrik. Nem csak a HTTP protokollt használhatjuk azonban, és más protokollok esetében lehetnek eltérések, vagy nem értelmezett elemek az URL-ben. Így például FTP (File Transfer Protocol, fájlátviteli protokoll) esetében nincs értelme az adattovábbításnak sem a szegmentálásnak és csak fájlok nevei adhatók meg, mint erıforrás azonosítók. 2.3.1 Azonosítás, üzenetfogadás Az URL - Uniform Resource Locator4 - vagy az újabban használt URI - Uniform Resource Identifier5 - tökéletesen egyedi mutatót biztosít a teljes Interneten egy
4
http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/Demo/url-primer.html
16
A webprogramozás alapjai meghatározott erıforráshoz (resource). Ez az erıforrás lehet egyszerő, mint például egy fájl vagy egy mappa, de hivatkozhat egy bonyolultabb objektumra is, mint például egy adatbázis lekérés vagy egy keresımotor. Ennek elérésére a számítógép IP címe szolgál, ami a névszerverekben tárolt információk alapján egyértelmően megfeleltethetı az egyes domén neveknek, továbbá a doménon belül - ez általában egy könyvtárnak felel meg az azonosított számítógépen - az egyes almappák és végül a fájlok egyedi nevébıl képezzük az URI-t. A névszerver vagy domain névszerver (DNS) feladata, hogy az adott hálózati szegmensen összekapcsolja a nevekkel jellemzett doméneket és a számítógépet azonosító IP címet. Kérésre - ismét egy szerver! - megmondja, hogy a keresett nevő domén melyik gépen, annak melyik könyvtárától kiindulva található meg. Országonként hierarchikus felépítésben helyezkednek el a névszerverek, ugyanakkor bárki telepíthet névszervert a saját gépére. Természetesen az Internetes forgalom címfeloldását végzı névszerverek ismerik egymást és a hálózaton egymással kommunikálva képesek végül a fizikai címet megadni. Egy számítógép több szervert is futtathat, bizonyos határok között akárhány szervert, amelyeket egymástól a port (azaz kapu) különböztet meg. A port azonosító biztosítja, hogy az üzenet a megfelelı szerverhez jusson el a számítógépen. A számítógépes szaknyelvben démonnak nevezik azokat az alkalmazásokat, amelyek egy-egy porton figyelve fogadják a beérkezı kéréseket, üzeneteket. Ezért az egyes szerveroldali alkalmazások kapcsolattartó részét is démonnak nevezzük. Ha beletekintünk valamely alkalmazás bin vagy lib könyvtárába és ott d-re végzıdı programfájlt találunk, akkor nagy valószínőséggel megtaláltuk a kapcsolattartásért felelıs elemet (például mysqld a MySQL adatbázis-kezelı kapcsolattartó démonja és httpd a http kéréseket fogadó web szerver (Apache) démonja. Amint ezt feltételezhetıen már tapasztalatból tudja, az IP cím tetszés szerint beállítható. A számítógépek megkülönböztethetıségét a fizikai szinten a hálózati kártyának a gyártók által garantált egyedi azonosítószáma (hardware address vagy rövidítve HW Address) biztosítja. Így például a 00:0C:76:94:A9:0E hexadecimális számmal azonosított hálózati kártya az Interneten a 82.79.96.167 IP címmel rendelkezı
5
http://www.ietf.org/rfc/rfc2396.txt
17
A webprogramozás alapjai számítógépben található a jegyzet írásának idıpontjában. Ebbıl az állításból az is következik persze, hogy a hálózati kártya gyártók sehol ezen a Földön nem gyárthatnak két azonos HW Address értékkel rendelkezı alkatrészt és persze folyamatosan kommunikálniuk kell, megegyezve egymás között a felhasználandó azonosítószámok tartományairól. Bıven van tartalék, mert a hexadecimális elrendezés miatt 2566 darab, azaz kereken 280000 milliárd egyedi hálózati kártya gyártható le. Vessük össze ezt a Föld jelenlegi lakosságával, ami ma 6 milliárd ember! Az IP cím persze csak akkor tölti be feladatát, ha valóban egyedi és ki tudjuk szőrni az emberi tévedést, tehát lehetıleg ne a számítógép kezelıje állítgassa. A cél az, hogy egyegy szolgáltatói alhálózaton belül gépi megoldással biztosítsuk az egyediséget. Ezt a szerepet töltik be a DHCP alapú rendszerek, ahol a kiosztást a DHCP szerver végzi és tartja nyilván, ez a szoftvereszköz tartja nyilván a már kiosztott címeket és ezek fizikai azonosításához feljegyzi a kérdéses gép hardvercímét is a saját adatbázisában.
2.4 Szerver oldali programnyelvek Ahhoz, hogy dinamikusan frissüljenek a weblapok - például az adatok változásának megfelelıen - elengedhetetlen, hogy a web szerver ne egyszerően a tárolt lapokat küldje le a böngészınek, hanem ezeket a lapokat dinamikusan állítsa elı. Ez gyakorlatilag annyit jelent, hogy a HTML/XHTML forráskódot kell elıállítani, vagy esetleg csak egy sablonhoz képest módosítani az adatoknak megfelelıen. Fájlokat bármely programnyelv elı tud állítani, tehát nem tőnik lehetetlennek a kérés. A korai próbálkozások idején ezeket a HTML fájlokat teljes egészében szerver oldali programok segítségével írták, de a grafikus tartalmak megnövekedésével és a bonyolultság növekedésével már az a helyzet alakult ki, hogy néhány százaléknyi dinamikus tartalomért az egész oldalt újra és újra elı kellett állítani a HTTP kérés befutása esetén. Több próbálkozás történt, hogyan lehetne összeépíteni a dinamikus tartalmat és a statikust és a megoldást olyan programnyelvek jelentették, amelyek egyrészt, mint szkript nyelvek lehetıvé tették a vizuális szerkesztést a statikus tartalom mellett, másrészt az ezeket a programnyelveket értelmezı interpreter képes volt csak a dinamikus tartalomnak megfelelı részek értelmezésére és a leküldésre kerülı fájlban az összeillesztésére.
18
A webprogramozás alapjai Jelenleg a szerver oldal talán legnépszerőbb nyelve egyszerősége miatt a PHP, de igen jelentıs a szerepe az ASP-nek és a Java nyelvnek is, ez utóbbi esetében a JSP technológiát lehet ezen a szinten említeni. Ez a két utóbbi nyelv számos szerver oldali objektumot tud kezelni és így az alkalmazásukkal gyorsabban lehet megoldani a feladatokat – természetesen ehhez megfelelı képzettséggel kell rendelkezni. Mindezen nyelvek esetében közös, hogy az erre felkészített web szerver a lekért fájlról elsı lépésben eldönti, hogy csak statikus tartalmat hordoz, vagy dinamikus elemek, részletek is vannak benne. Ha a tartalom csak statikus, akkor kiszolgálja, ha dinamikus részt is tartalmaz, akkor a fájlt elıször átadja a megfelelı feldolgozó programnak, konténernek, ahol a dinamikus tartalmaz reprezentáló kódrészletek kerülnek feldolgozásra. Amennyiben a dinamikus tartalom HTML/XHTML kimenetet generál, ez bekerül a fájlba és ezzel kiegészítve kerül le a klienshez. Az is elıfordulhat persze, hogy a dinamikus tartalom valamilyen kimenet nélküli üzleti logikát tartalmaz, vagy például adatfelvitel végez. Ebben az esetben maximum egy értesítés kerül leküldésre, a felhasználó tájékoztatására.
2.5 Ellenırzı kérdések
19
A webprogramozás alapjai
3 Kommunikáció a kliens és a szerver között Az architektúrák tárgyalása során kiderült, hogy az elosztott rendszerek csak igen ritka esetekben használnak közös memóriát, így az adatok memórián keresztül történı átadása nem lehetséges. Ezért a kommunikáció az üzenetátadás szintjére szorul vissza, azonban ez sem egyszerő, mert az üzenetküldı és az üzenetfogadó meg kell, egyezzen az üzenet pontos szerkezetében is egymás között. A leggyakrabban persze nem kétoldalú egyezkedésrıl van szó, hanem olyan általános és szabványosított rendszerrıl (üzenetszerkezetrıl), amit a kommunikáció bármely résztvevıje megért és magára nézve kötelezıként ismer el. A tananyagnak nem célja, hogy átfogó hálózati ismereteket adjon, hiszen ezt más tantárgyak már megtették. Mégis érdemes néhány gondolat erejéig átismételni, és egykét speciális területen elmélyíteni ezeket az ismereteket, hogy könnyen elsajátíthatók legyenek a tananyag hálózatos ismeretekre támaszkodó részei. Kezdjük tehát az összes hálózati kommunikáció alapjait képezı OSI modell felidézésével és a hálózati protokollokkal.
3.1 Az OSI modell és rétegei Az Open Systems Interconnection Reference Model, azaz az OSI modell teljes mértékben lefedi a kommunikáció szintjeit. Szerzıi abból indultak ki, hogy a kommunikáció egyes szintjeit elvi alapon elkülönítették, így hét szintet jelöltek ki, és minden szintnek jól körülhatárolható felelısségeket adtak meg. A szintek között a kommunikáció (vertikális kommunikáció) szabványosított felületeken át (interfész) történik és a közvetlen kapcsolatért felelıs legalsó, úgynevezett fizikai réteg az egyetlen, amely közvetlen horizontális kommunikációt is végre tud hajtani.
7
Réteg elnevezése
A kapcsolatot létesítı protokoll
alkalmazási
alkalmazási protokoll 20
A webprogramozás alapjai 6
megjelenítési
megjelenítési protokoll
5
viszony
viszonyprotokoll
4
szállítási
szállítási protokoll
3
hálózati
hálózati protokoll
2
adatkapcsolati
adatkapcsolati protokoll
1
fizikai
fizikai protokoll A fizikai hálózat (hardver)
Az OSI modell rétegei Egy alkalmazás szintő üzenet elküldése ebben a rendszerben úgy történik, hogy az adott folyamat összeállítja az üzenetet, azt átadja az alkalmazási rétegnek, és ez a szoftver hozzátesz egy fejlécet, amely saját magára utal és több-kevesebb "használati utasítást" tartalmaz, majd átadja a lentebb elhelyezkedı rétegnek. Ott ugyanez történik, míg a réteg specifikus fejlécekkel ellátott üzenet elérkezik a fizikai réteghez, ahol megtörténik az üzenet elektromos jelek formájában történı elküldése. A fogadó oldalon ugyanennek az üzenet becsomagolásnak a fordítottja zajlik, az egyes rétegek a nekik szánt fejlécek alapján járnak el és továbbadják az így feldolgozott üzenet a felettük álló rétegnek, míg ismét eljutunk az alkalmazás szintig. Itt a kapcsolódó folyamat (például szerver vagy kliens) szoftver szinten feldolgozza az üzenetet, és ha válaszol rá, azt ugyanezen az úton elindítja visszafelé. Az alsó három réteg szerepe markánsan szétválik. A fizikai réteg felel a jelszintő kommunikációért, a hardver elemek szabványaiért. A felette elhelyezkedı adatkapcsolati réteg definiálja az adatkereteket, a hibák felfedéséért és sok esetben a javításáért is. A hálózati réteg szerepe a hálózati kommunikáció meghatározása, ezért mőködése jelentısen eltér helyi hálózaton vagy például az Interneten. Míg a helyi hálózatnál a broadcast módszer tökéletesen megfelelı (kiküldjük az üzenetet minden gépre és az illetékes elkapja) a nagytávolságú hálózat esetén már szükség van útvonalválasztásra is, ami ennek a rétegnek az egyik szolgáltatása. Az üzenetküldés protokolljai közül a jól ismert IP protokoll tartozik ehhez a réteghez. A szállítási réteg elsıdleges szerepe a kommunikáció megbízhatóságának megteremtése, ezért jellegében másként, mintegy interfészként mőködik a felsıbb rétegek és az alsó három között. Az alkalmazásfejlesztık számára ez a réteg biztosítja azt a "csıpostát" (pipeline) amelybe töltött üzenetek a fogadó végen sértetlenül 21
A webprogramozás alapjai megérkeznek. Ennek megvalósítása történik ebben a rétegben, amelynek legismertebb és a hálózati kommunikációban leggyakrabban használt protokollja a TCP (Transmission Control Protocol, átvitelvezérlı protokoll). A gyakorlatban szinte mindenütt TCP/IP protokollról beszélünk, érdemes megjegyezni, hogy a név két szorosan összedolgozó, ám függetlenül is mőködıképes rétegprotokollt jelez. Az UDP, az Universal Datagram Protocol lényegében egy kismértékben módosított IP Protocol. Fontosságának megfelelıen a TCP protokollt is fejlesztik, újabb változata a tranzakciós TCP, amely a kapcsolat felépítésétıl kezdve a válasz fogadásán keresztül a kapcsolat lezárásáig mindent együtt kezel. A felsıbb rétegek határai nem minden esetben élesek, azaz különbözı rendszerekben az egyes feladatok összecsúszhatnak, vagy a réteghatárok eltolódhatnak. Így a viszony és a megjelenítési réteg protokolljai gyakran összeolvadnak és az elosztott alkalmazások esetében ezt a köztesréteg protokoll helyettesíti. Ezek a protokollok testesítik meg a köztesréteg szolgáltatásokat és ezek az általános célú protokollok, amelyeket különbözı alkalmazások egyaránt használnak. Így alakult ki a köztesréteg szerepe az elosztott alkalmazásokban, mint magas szintő kommunikációs szolgáltatásokat nyújtó réteg. Ezekbıl négyet emelünk ki, a távoli eljáráshívást, a távoli objektumhívást, az üzenetorientált kommunikációt és az adatfolyam orientált kommunikációt.
3.2 Az OSI modell megvalósulása TCP/IP esetén Ahhoz, hogy két pont közötti kommunikáció létrejöhessen, és a két végponton elhelyezkedı alkalmazás vagy eszköz megértse egymást, standard protokollokra van szükség, amit mindkét kommunikáló oldal értelmezni tud. Az internetes (webes) alkalmazások esetében a hálózati kommunikációt többnyire a TCP/IP protokoll biztosítja, de bizonyos esetekben az erre ráépülı HTTP protokoll biztosítja az adatforgalmat. Ez utóbbi nagy elınye, hogy mivel karakterek átvitelére képes, kötött formátumban, alkalmazható egyes tőzfallal védett rendszerek esetében is. Fontosságuk miatt ismerkedjünk meg ezekkel kicsit részletesebben, de elıtte áttekintésképpen álljon itt az említett protokollok elhelyezkedése az OSI modellben.
réteg sorszáma
réteg elnevezése
protokoll
22
A webprogramozás alapjai 7
alkalmazási
HTTP
6
megjelenítési
5
viszony
4
szállítási
TCP
3
hálózati
IP
2
adatkapcsolati
1
fizikai
A webes alkalmazásokban gyakrabban használt protokollok elhelyezkedése az OSI modell szerint.
3.3 TCP/IP A TCP/IP protokoll az Internet, a böngészı-szerver kapcsolat, a HTTP kérések általános kommunikációs protokollja, de más alkalmazások - például a levelezés - is használja ezt a protokollt. A TCP/IP protokoll jelenleg a legelterjedtebb standard. Gyakran beszélünk a TCP/IP protokollcsaládról, amelyen belül számos specializált protokoll található: −
TCP
(Transmission
Control
Protocol)
alkalmazások
közötti
kommunikációt biztosító protokoll, amely állandó kapcsolatot igényel a két alkalmazás között. Felépítéséhez a kommunikációt kezdeményezı alkalmazás kapcsolatkérést küld egy pontos címmel rendelkezı számítógép (alkalmazás) felé, majd "kézfogás" (handshaking) után a full duplex módon üzemelı kommunikáció az egyik fél kapcsolat bontásáig marad fenn. −
UDP (User Datagram Protocol) kisebb adatcsomagok átvitelét biztosító protokoll. Egyszerőbb a TCP-nél, nincs állandó kapcsolat a küldı és a fogadó között. Egyszerő adattovábbításkor használják, például mérıberendezés jelének az elküldésekor.
−
IP (Internet Protocol) adatcsomagok továbbításán alapuló, kapcsolat nélküli protokoll. Feladatai közé tartozik a csomagok útválasztása is (routing). Az OSI modell kapcsolati rétegének megfelelı szintő protokoll. 23
A webprogramozás alapjai −
DHCP (Dynamic Host Configuration Protocol) dinamikus IP cím kiosztást biztosító protokoll. Feladata az alhálózaton található számítógépek ellátása IP címekkel a TCP/IP alapú kommunikáció céljára. Bár a címkiosztás dinamikus, azaz az IP cím hozzárendelés esetleges, beállítható úgy is, hogy adott hálózati kártyához (hardvercím, azaz HW Address) az alhálózatban mindig azonos IP cím tartozzon. Így akár szerver is üzemeltethetı DHCP címkiosztás mellett. Egyre több Internet szolgáltató használja ezt a rendszert, mert így a hálózatban mőködı gépek egyértelmően azonosíthatóak.
−
ICMP (Internet Control and Message Protocol) az esetleges hibaüzeneteket és statisztikai adatokat szolgáltató protokoll.
−
HTTP (HyperText Transfer Protocol) végzi a web böngészı és a web szerver közötti kommunikációt, amelynek során alkalmazás szinten fejléccel ellátott üzenetek (fájlok) kerülnek átvitelre. A fejlécben tárolt információ írja le a HTTP kérésre leküldött fájl feldolgozásának/értelmezésének módját, de ez nem azonos a head elemben kódolt információval.
−
HTTPS (secure HTTP) a fentivel megegyezı feladatokat lát el, de a kommunikációt biztonságos csatornán végzi, ezért alkalmas a HTTP protokollhoz kapcsolódó bizalmas adatok továbbítására. Ezt a protokollt használják például elektronikus banki rendszerekben vagy hitelkártya tranzakcióknál, de a MS Outlook webes hozzáférése is ezzel a protokollal megy.
−
SSL
(Secure
Sockets
Layer)
protokollt
használunk
adatok
titkosításánál és azok biztonságos átvitelénél. −
SMTP (Simple Mail Transfer Protocol) az egyik leggyakrabban alkalmazott levelezési protokoll. Csak szöveges átvitelt biztosít, ezért bináris adatok/tartalom átvitelénél a MIME protokollra támaszkodik. Leggyakrabban az elektronikus levelek elküldésénél alkalmazzuk, amikor a szolgáltatónk SMTP szerverére juttatjuk el elıször a leveleinket az megíráshoz használt kliensprogramból és a továbbítást már a szerver végzi. Letöltéshez általában a POP vagy IMAP protokollokat használjuk.
−
MIME (Multi-purpose Internet Mail Extensions) feladata a bináris adatok (kép, hang vagy video fájlok, objektumok) szöveges információba történı átkódolása, hogy az SMTP protokoll már kezelni tudja.
24
A webprogramozás alapjai −
IMAP (Internet Message Access Protocol) protokollt alkalmazunk az e-mail üzeneteink letöltésére abban az esetben, ha lehetıséget akarunk biztosítani a felhasználónak az üzenetek szerver oldali tárolására és/vagy megtekintésére. Ezzel a protokollal már a szerveren törölhetjük a nem kívánt email üzeneteket, azaz kiváló eszköz a levélszemét kiszelektálására.
−
POP (Post Office Protocol) egyszerő e-mail letöltı protokoll. Amikor a postafiókunkat biztosító szerverhez POP protokollal csatlakozunk, az összes levelünket letölti a kliens gépen futó levelezıprogram megfelelı mappáiba. Szerver oldali szelektáláshoz az IMAP protokoll ajánlott.
−
FTP (File Transfer Protocol) - régebben az egyik legnépszerőbb protokoll volt, de még ma is sokan használják fájl letöltésekhez. Szerver oldalon azonban nem túl biztonságos, ezért vagy dedikált szerveren helyezik el, vagy helyette biztonságos letöltéseket nyújtó SCP protokollt támogató és/vagy SSH-t (Secure Shell) használó programokat alkalmaznak (WinSCP), amelyek már biztonságos csatornán kommunikálnak a szerverrel. Ezekkel, mint SFTP (Secure File Transfer Protocol) is találkozhatunk.
−
LDAP
(Lightweight
Directory
Access
Protocol)
protokollt
alkalmazunk, amikor az Interneten a felhasználókról - e-mail postafiók tulajdonosokról - és az e-mail címükrıl keresünk információkat. Ez fontos lehet egy olyan alkalmazás esetén, amikor adatbevitelnél le akarjuk ellenırizni a beírt e-mail cím hitelességét.
3.4 HTTP A HTTP alkalmazás szintő protokoll, amely a TCP/IP protokollt használva egyszerő szöveges információ átvitelére alkalmas. A HTML vagy az XML leírónyelveket alkalmazva ez szöveges információ azonban biztosítani képes az adatok és a böngészıben az egyes grafikus elemek megjelenítését, valamint a strukturált adatok (akár teljes adatbázisok) átvitelét is. A jelenleg általánosan használt verziója a HTTP/1.16, amely több funkcionalitást biztosít, mint a korábbi és esetenként még
6
HTTP/1.1 szabvány leírása: RFC 2616, HyperText Transfer Protocol - HTTP/1.1,
megtalálható a következı helyen: http://www.ietf.org/rfc/rfc2616.txt 25
A webprogramozás alapjai elıbukkanó HTTP/1.07. A számunkra talán legfontosabb különbség, hogy az újabb verzió a fejlécben átviszi a megcímzett domén (host) nevét is, ami lehetıséget biztosít egy IP cím alatt több webhely üzemeltetésére (virtual host, késıbb részletesebben tárgyaljuk). Értelemszerően a kliens és a szerver azonos HTTP verziót kell, hogy használjon és ez a kérés vagy a válasz elsı sorában meg is kell adniuk. A HTTP kérést a kliens indítja a névvel ellátott domén felé, amely egy szerveren helyezkedik el. Ennek célja erıforrásokhoz való hozzájutás a szerveren. A kérés megvalósításához a kliens az URI alapján állítja össze az információt, ami az erıforrás eléréséhez kell. Egy megfelelıen összeállított HTTP kérés a következı elemeket tartalmazza: 1. Kérés sora 2. HTTP fejlécek sorozata, vagy más néven fejléc mezık 3. Amennyiben szükséges, az üzenet törzse. Mindegyik HTTP fejléc után egy soremelés következik, az utolsó fejléc után egy további soremelésnek kell következnie, hogy üres sor maradjon. Az üzenet törzse csak ezután kezdıdhet. A kérés sora legalább három elembıl áll. Elıször meg kell határozni a kérés módját, ami egyszavas parancs a szerver felé, hogy mit csináljon az erıforrással. Másodszor meg kell adni az URI-ból az elérési utat, ami az erıforrást határozza meg a szerveren. Harmadszor meg kell adni a HTTP verziószámát, amit a kliens alkalmazott az üzenet összeállítása során. Erre egy példa a következı kérés sor: GET /konyvtar/archivum/index.html HTTP/1.1 A kérés sor tartalmazhat még adatokat az ismert név-érték párok formájában és az URI egyéb komponenseit is, amennyiben ez egy abszolút elérési út. Ha a protokoll verziója
7
HTTP/1.0 szabvány leírása: RFC 1945, HyperText Transfer Protocol - HTTP/1.0,
megtalálható a következı helyen: http://www.ietf.org/rfc/rfc1945.txt
26
A webprogramozás alapjai 1.1, akkor vagy itt, az URI-ben vagy egy külön Host fejlécben kell a domén információt hordoznia. A HTTP fejlécek a fogadó oldalt látják el információval a küldırıl, a kommunikáció módjáról, nyelvi megkötésekrıl, frissítési információkról. Az alábbi fejlécek például megkötik, hogy csak német vagy francia nyelvő lehet az erıforrás és csak akkor kéri a kliens, ha azt tavaly december 6. óta módosították. Accept-Language: fr, de If-Modified-Since: Fri, 10 Dec 2006 11:22:13 GMT
Hálózat, IP cím, alhálózat, alhálózati maszk, router (útválasztó) - ezek a kifejezések gyakran elıfordulnak hálózati alkalmazások esetén. Tekintsük át röviden, mi mit jelent ebben a rendszerben. A hálózat egyaránt jelent LAN-t és Internetet, ez utóbbi, mint a hálózatok hálózata a legnagyobb részben helyi hálózatokból épül fel. A LAN és a világ többi része közötti kapcsolatot a router biztosítja, amely az alhálózati maszk segítségével különbséget tud tenni a helyi hálózat és az ezen kívül elhelyezkedı gépek között. Az alhálózati maszk egy, az IP címmel azonos felépítéső cím, amelyben az egyes mezıkben beállított értékek - összevetve a címzésben megadott IP címmel - adják meg a számítógép hovatartozását és így az útválasztás irányát is. Egy példán szemléltetve, a 192.168.1.25 IP cím és a 255.255.255.0 alhálózati maszk együtt egy olyan számítógépet határoz meg, amely a 192.168.1 doménen belül helyezkedik el - azaz az Internet kikerülésével a LAN hálózaton keresztül közvetlenül elérhetı - és a helyi hálózat 25-ös azonosítószámú gépe. Ezzel szemben a 192.168.2 kezdető IP címrıl a router rögtön tudja - az alhálózati maszkkal összevetve, - hogy nem található a LAN hálózaton belül, azaz az ide irányuló kérést a belsı hálózaton kívülre kell továbbítani.
3.5 Ellenırzı kérdések
27
A webprogramozás alapjai
4 Web alkalmazások tervezése, megvalósítása Mind minden mérnöki munkánál, itt is a tervezéssel kell kezdeni. Még egyszerőbb webhelyek esetében sem árt végiggondolni a teljes alkalmazást, mielıtt nekivágunk. Az elsı a pontos specifikáció meghatározása. Mit akarunk elérni, kinek akarjuk a webhelyet prezentálni? A webes alkalmazások esetében különös jelentısége van a felhasználó barátságnak, mert nem nagyon van lehetıség részletes kézikönyvek áttanulmányozására az alkalmazás futtatása közben. Publikus webhelyek esetében semmi befolyásunk nincs a látogatókra, nem taníthatjuk be a felhasználókat, mindenkinek magának kell eligazodnia a weboldalakon. Ezért a szoftver ergonómia jelentısége rendkívül megnı.
4.1 Honlapok, webhelyek, portálok Ez a három kifejezés erısen összemosódik és nehéz határokat hőzni közöttük. Aki készíti az alkalmazást, az szereti felturbózni a munkáját, tehát a honlapot webhelynek és a webhelyet portálnak fogja nevezni, de ezen nem kell meglepıdni. A szakirodalomban azonban a portál fogalmat fenntartják azon bonyolultabb webhelyekre, amelyeket az egyes felhasználók a saját elképzelésük szerint alakíthatnak, testre szabhatnak. Ilyen portál az ILIAS rendszer, de a PHPNuke, a Drupal és még sok más hasonló rendszer is ide számítható. Webhelyként hivatkozunk a weblapok azon összességére, amelyek mögött dinamikus rendszer van, lehetıleg adatbázisban tároljuk az információt és mind a feltöltés, mind a megjelenítés dinamikus rendszereken át megy. 4.1.1 Architektúrák, rétegek és komponensek Egy ismert felosztás szerint egyrétegő, kétrétegő és háromrétegő alkalmazásokat különböztetünk meg. Rétegnek akkor nevezhetünk egy komponenst, ha feladatában önálló és bizonyos határok között cserélhetı, a rendszer egészét egy-egy rétegének megváltoztatása nem befolyásolja. Amennyiben az egyes rétegek különbözı számítógépeken helyezkednek el, már elosztott rendszerekrıl kell beszélnünk. Ilyen 28
A webprogramozás alapjai rendszer lehet egy alkalmazás és a távoli adatbázis szerver közötti kapcsolat, vagy egy kliens-szerver rendszer is. Többrétegő alkalmazások esetén az elosztott rendszer több egyedi számítógépet is magába foglalhat, ennek tipikus példája egy olyan webes alkalmazás, ahol a böngészıt futtató kliens gép kéréseivel távoli web szerverhez fordul, az viszont a kérés teljesítése során, a hivatkozott szerver oldali program végrehajtása közben (dinamikus weboldal) egy harmadik gépen tárolt, az alkalmazás futtatásához szükséges adatbázist igyekszik elérni. Elvben ugyan több réteg is bevezethetı, de a gyakorlatban csak az egyes fenti rétegek bizonyos fokú megosztása kerül megvalósításra, így ezek több rétegbe sorolása felesleges. Egy kivétel azonban lehet, és ez a nagyfokú mesterséges intelligencia alkalmazása. Az itt szükségessé váló fokozott számításigény megkövetelhet különálló, erre specializált komponenst, amely így külön réteget alkothat.
4.2 Dizájn és áttekinthetıség Mint mővészi alkotás, ennek is divathullámai vannak és gyorsan változnak az elvek, hogy mikor milyen alkalmazást illik készíteni. Alapvetı viszont, hogy néhány olyan alkalmazás mellett, ahol a mővészi teljesítmény az egyetlen követelmény, az áttekinthetıség a legfontosabb szempont – feltéve, hogy a weblapunkat azzal a céllal készítettük, hogy sokan megtekintsék. Nem ajánlatos, hogy a grafika elnyomja az információtartalmat és persze az eltérı ízlésvilág miatt nem lehet olyan webhelyet alkotni, amely mindenki számára egyformán vonzó. Így érdemes a mővészi teljesítményt a háttérbe szorítani és az információközlésre koncentrálni – ha fontos a mővészet, akkor ezt képgalériákban lehet legjobban publikálni.
4.3 Navigálás Talán ezzel lehet a legjobban megdobni egy webhelyet, ha alaposan átgondoljuk a navigálás lépéseit, a várható látogatóközönség igényét. Nem csak a logikus oldalróloldalra navigálás a lényeges, hanem a közvetlen eljutás is a legfontosabb lapokra. Sohase arra gondoljunk, hogy mi, akik ismerjük az oldal szerkezetét, mennyire igazodunk el rajta, hanem győjtsük be olyanok véleményét, akik nem gyakorlott internetezık. A gombok, linkek és kép linkek egyaránt jók, de minden ilyen elemnek megvan a maga helye, nem érdemes összekeverni. Gombokkal érdemes megoldani a 29
A webprogramozás alapjai navigációt a hivatalos tartalmaknál és ne feledjük el, hogy a linkek a maguk adatátviteli lehetıségeivel egyszerő és elegáns megoldásokat biztosítanak.
4.4 Ellenırzı kérdések
30
A webprogramozás alapjai
5 Leíró nyelvek Természetesen a HTML, mint leírónyelv sem egyszerre jött létre, hosszú idıbe telt, míg a kezdetektıl eljutottunk a mai szabványos HTML 4.01 verzióig vagy az XHTML nyelvig. Az egész egy betőszóval az SGML rövidítéssel kezdıdött. Ezek a betők az angol Standard Generalized Markup Language kifejezés - azaz szabványos általános leírónyelv - kezdıbetői és a HTML ısének tekinthetı leírónyelvet azonosítják 1986-ból. Érdemes megfigyelni, hogy ez az ıs sem igazán régi, bár húsz év az informatika világában egy korszakot jelent. Bár jól dokumentált volt és a nagyközönségnek is rendelkezésére bocsátották, továbbá precízen képes volt leírni a dokumentum tartalmát - itt még a hangsúly nem a formázáson volt! - továbbá rendelkezett azzal a behozhatatlan elınnyel, hogy független volt az eszköztıl, nehézkessége miatt nem terjedt el kellıen és méltán utálták a kor informatikusai. 1989-ben megérkezett az elsı HTML, az 1.0 változat Tim Berners-Lee szerkesztésében, amit jókora viták követtek, de 1993 márciusára már sikerült megállapodni mindenben és a szabványos HTML nyelv megszületett. Ez a "szülés" olyannyira sikeres volt, hogy a HTML nyelvet már értelmezni képes elsı böngészı, a Mosaic már az 1993. év ıszére el is készült, és azóta útja, ha nem is töretlen, de mindenképpen sikeres. Lehet, hogy Tim Berners-Lee neve ismerısen cseng - de ez nem meglepı! İ javasolta az Internet WWW szolgáltatásának létrehozását és ı írta az elsı programokat ennek mőködtetésére. Érdemeiért 2004-ben lovaggá ütötték és az esemény kapcsán sokat cikkeztek az Internetrıl, www-rıl. Ma kicsit sablonosan fogalmazva ıt tekintjük az Világháló feltalálójának. Közben létrejött a W3 Konzorcium (persze e mögött is Tim Berners-Lee volt) és ez vezette a fejlesztéseket, a szabványosítást. Igyekeztek bıvíteni a nyelv lehetıségeit és
31
A webprogramozás alapjai így áttörték az 1.0 változatban még szigorúan vett korlátot, hogy csak a tartalom leírására összpontosítanak. A HTML 2.0 változatát az Internet Engineering Task Force HTML Munkacsoport fejlesztette ki 1996-ban, de ez a változat már annyira elavult, hogy a böngészık már nem is kezelik. A HTML 3.2 változat már, mint W3C Javaslat került kibocsátásra 1997 januárjában. Az elızıkhöz képest ez már jelentıs elırelépést jelentett, hozzávettek olyan, széles körben elterjedt Netscape elemeket, mint a fontok, táblázatok, appletek és még több mást is. Az egyik igen jelentıs, ám késıbb sok zavart okozó elem a font teg volt, amely felrúgta az addig többé-kevésbé betartott szabályt, nevezetesen a tartalom és a prezentáció (stílus) szétválasztást. A formázást biztosító elemek bekerülésével már nem csak a tartalom, hanem a külalak is leírhatóvá vált. Ez a verzió túlélte a nagy böngészıháborút is, amikor a Netscape és a Microsoft egymással nem kompatibilis elemeket szerkesztett bele - ezért van az még ma is, hogy figyelni kell, melyik böngészıre fejlesztünk, illetve a böngészı-függetlenséget csak különbözı trükkökkel és sok extra munkával lehet biztosítani. A felmerülı problémák megoldására a HTML 4.0 változatot a W3C 1997 decemberében adta ki, amit néhány apróbb korrekció követett 1998 áprilisában. A legfontosabb eleme ennek a változatnak a stíluslapok hozzáadása volt, amellyel helyre kívánták állítani a tartalom és a külsı megjelenés szétválasztását. Ez annyira sikeres volt, hogy a jelenleg is használt változat, a 4.01 csak apróbb javításokat tartalmazott és így 1999-re kialakult a végleges, ma is használatos változat. Így amit a következı oldalakon tanulni fog, az mind erre a változatra, pontosabban az ebbıl kifejlesztett XHTML nyelvre lesz igaz elsısorban - persze az elemek jó része a korábbi böngészıkkel is értelmezhetı lesz. Ahhoz képest, hogy ennyi változatot élt át a HTML nyelv és milyen gyorsan változott, felmerülhet a kérdés, hogy mi a helyzet jelenleg. Nos, a HTML nyelv fejlesztése leállt és a W3C ettıl kezdve nem fejleszti tovább. Helyette azonban az XML elterjedésével párhuzamosan fellépett az igény egy szigorúbb követelményő, jobban értelmezhetı leírónyelvre. Így tehát a fejlıdés újabban más irányba megy már. Bevezették a kötöttebb szintaktikájú XHTML 1.0 nyelvet, amely sokkal szigorúbb elvárásokat testesít meg a kódszerkesztıtıl, nem olyan "laza", mint a korábbi szabványok. Ez 32
A webprogramozás alapjai lényegében újraformálja a HTML nyelvet XML alapokon, és a jelenleg is érvényes változatra a W3C javaslat 2000 januárjában jelent meg. A szigorú szintaktika miatt alkalmas a mobilkommunikációban is, ahol a szőkös memória és képernyı lehetıségeket kell optimálisan kihasználni. A másik fejlıdési irány az XML, amely viszont csak formájában hasonlít a HTML-re - ebbıl is látszik, hogy milyen zseniális ötlet volt a karakteres, olvasható tartalmi megjelenítés bevezetése - ám a technika nem az adat (dokumentum, szöveg) tartalmi, formai megjelenítését hivatott leírni, hanem tetszés szerint bıvíthetı tegjeivel az adatok összefüggéseit írja le, az adatokat jellemzi. Például megmondja, hogy az adatként szereplı "hallgató" alatt diákot, rádióhallgatót vagy éppen az eszközt (fülhallgatót) értjük. Használatával az adatokhoz nem kell külön dokumentumot készíteni, amely ezt rögzíti, hanem az adatok továbbítására, tárolására szolgáló fájl is tartalmazza az információt. A fejlıdés azonban nem állt meg a fentebb említett nyelveknél. Ma már a leírónyelvek egész családjáról beszélünk, amelyek azonos elveken, de egészen más dolgokat is "közölni" tudnak. Így például rendelkezésre áll a SMIL leírónyelv, amely segítségével multimédiás prezentációkat tudunk létrehozni, vagy a SVG (skálázható vektorgrafika, Scalable Vector Graphics), amely lényegében XML nyelv, de adottak a tegek és így az erre felkészített böngészıben grafikai elemeket lehet megjeleníteni a segítségével.
5.1 HTML A HTML nyelv alapeleme a címke, vagy angol nyelven a tag (ejtsd teg)8. Ezek nyitó (<) és záró (>) kacsacsır, vagy "kisebb, mint" illetve "nagyobb, mint" jelek közé zárt egyszavas angol nyelvő dokumentum-elemnevek, vagy azok rövidítései (például teg jelzi, hogy a dokumentum törzse kezdıdik. Minden, a dokumentumot alkotó szövegelem esetében meghatározzuk annak típusát (bekezdés, táblázat része, stb.) és megadjuk a dokumentumon belüli elhelyezkedését. A legutolsó HTML nyelvi változatban megadhatjuk a szövegelem külsı megjelenését is, azaz betőtípusát,
8
A magyar terminológiában mind a címke, mind a tag elnevezés elfogadott, ráadásul tag szót, magyar
kiejtéssel tagnak is mondják, és az „a” hanggal ragozzák (pl. többes számban tagok). A legújabb ajánlások szerint a teg formát a legcélszerőbb használni, ugyanis a magyar tag homonima használata félrevezetı, a tag idegen szóként ragozva (pl. tag-ek) pedig zavaró. Ugyanakkor címke vagy elem fordítás is túl általános ill. túl konkrét.
33
A webprogramozás alapjai karakterét, színét, nagyságát is. A leírónyelvek jellegébıl következik, hogy olyan módon kell a dokumentumon belül az egyes szövegrészek megjelenítését megadni, amely minden böngészı által egységesen értelmezhetı. Ez a megadási mód a kérdéses szövegrész tegek közé zárása, egy nyitó és az ennek megfelelı záró teg között. A nyitó teg belsejében különbözı attribútumok helyezhetık el, ezek módosítják a megjelenítést, vagy az elem azonosítására szolgálnak. A nyitó és záró teg együttesen közrefog valamilyen tartalmat, amire a teg vonatkozik. A tegeket és tartalmukat együtt HTMLelemnek nevezzük. Példaként álljon itt egy HTML dokumentum részlete:
Ez a szövegrészlet Ariel betőtípussal, piros színnel, a böngészı által biztosított 1-6 skálán közepes mérető betőkkel és félkövér (bold) betővel fog megjelenni. A szövegelem egy bekezdést (paragrafus) alkot, azaz új sorban kezdıdik és az utána következı szöveg is új sorban lesz, kis helyköz kihagyással a sorok között
A tegek segítségével a táblázat, vagy a HTML őrlapok egyes elemeinek leírásától az egyszerő bekezdésekig sokféle elemet találunk, ezek közül a gyakrabban elıfordulókat készség szintjén is ajánlatos ismerni, de gyakorlati célokra érdemes egy-egy bıséges referenciát kéznél tartani. Ez utóbbi lehet nyomtatott könyv, de a téma jellegének megfelelıen az fájlban vagy az Interneten elérhetı anyag a leginkább célravezetı. Mivel a HTML nyelv értelmezése a böngészı feladata, nagy szerepe van a böngészıbe épített intelligenciának az esetleges nem szabályos leírás értelmezésében. Vannak továbbá olyan elemek is, amelyekre nem igaz a nyitó - záró teg pár és csak nyitótegeje van. Ilyen a gyakrabban használtak közül a vízszintes vonal
, vagy a sortörés utasítás a
, illetve a képek megadására szolgáló
![]()
elem. Ennek belsejében nagymennyiségő információt közölhetünk a kép megjelenítésével kapcsolatban, annak értelmezéséhez. Kötelezıen meg kell adni a hivatkozott képfájl relatív elérési útját és nevét, de megadható a kép mérete, a képhez megjelenı szöveg, ami leggyakrabban a képet leíró szöveg és a látássérültek által használt böngészıprogramok ennek a leírásnak alapján tudják "felolvasni" a weboldalt. Ezzel azonban még messze vagyunk a HTML leírónyelv elsajátításától és bizonyos okoknál fogva nem is foglalkozunk vele többet. Az ok valójában egyszerő. Bár a HTML nyelv ma rendkívül népszerő, gyakran használt leírónyelv, a webes tartalmak leírásán kívül is, napjainkban már elavult. Szerencsére van helyette más és arról a másról a külsı szemlélı nem is tudja eldönteni, hogy ez valóban egy másik leírónyelv! 34
A webprogramozás alapjai
5.2 XHTML Mi a HTML nyelv legfontosabb szerepe? Formázott megjelenítést biztosítani a dokumentumoknak úgy, hogy a formázást leíró kód standardizált legyen, azaz a különbözı olvasó/értelmezı programok egységes megjelenítést adjanak. Egyszerő feltétel, de nem könnyő megvalósítani. A HTML nyelv az Internet gyerekkorának nyelve és hasonlóan a gyerekekhez, sok mindent elnéztünk neki. Ehhez viszont szükséges volt az intelligens értelmezésre és mivel itt idınkét ki kellett találni a szerkesztı elképzelését, az nem mindig sikerült teljes mértékben. Bevezetésre került tehát az XHTML nyelv, amely ezeket a félreértelmezéseket hivatott visszaszorítani. A betőszó az EXtensible HyperText Markup Language szavakból készült, és célja a HTML helyettesítése, nyugodtan mondhatjuk, hogy kiszorítása. Ugyanakkor nem csak a neve csaknem azonos, hanem a nyelv is. Nyilvánvaló, hogy úgy a legegyszerőbb egy népszerő dolog helyettesítése, ha azt mondhatjuk, az új gyakorlatilag ugyanaz, csak másképp hívjuk… Kijelenthetjük tehát, hogy az XHTML a HTML szigorúbb és tisztább változata, amelyben a HTML elemeket az XML (lásd késıbb) eszközeivel írjuk le. Bár nevében szerepel az extended (kiterjesztett) szó, semmi kiterjesztés nincs a nyelvben a HTML nyelvvel összehasonlítva. A szigorúság annyit jelent, hogy minden teget egyformán kezelünk, azaz nem alkalmazunk záró elem nélküli teget. Amennyiben a teg tipikusan egysoros, itt is gondoskodunk a lezárás jelzésérıl. Nem fedhetnek át a tegek, de (majdnem) tetszés szerint egymásba ágyazhatóak. Erre késıbb majd a tegek tárgyalásánál láthatunk példákat. Nem tőnik túl lényegesnek, de az XHTML kódban minden teg név kisbetővel írandó és nem keverhetı nagybetős írásmóddal. Ennek oka egyszerően az, hogy a leírásra használt XML nyelv kisbető/nagybető érzékeny több programozási nyelvhez hasonló módon és így az egységes írásmód ebbıl logikusan következik. Természetesen a böngészı egyaránt fel kell, hogy ismerje a nagybetővel írt elemeket is, a régi HTML szabványok alkalmazhatósága miatt, de mi próbáljuk meg egységesen kisbetővel szerkeszteni XHTML dokumentumainkat. Egy validálás azonnal jelezni fogja a keveredéseket! Néhány példa a tegekre és azok lezárására az XHTML nyelvben attribútumok nélküli többsoros teg, további tegeket tartalmazhat
35
A webprogramozás alapjai attribútumokat is tartalmazó többsoros teg, további tegeket, szöveget tartalmazhat
attribútumokat is tartalmazó egysoros teg
attribútumok nélküli egysoros teg Természetesen az XHTML leírása is egy W3C Javaslat, annak elsı, 1.0 változata 2000ben került publikálásra és jelenleg már a 2.0 változat van kidolgozás alatt. Nézzük meg tehát, hogyan épül fel egy XHTML dokumentum, melyek a gyakrabban használt tegek és hogyan használjuk ezeket. Alább látható egy XHTML oldal kódja. Ha ezt a kódot beillesztjük egy szöveges fájlba és azt akarmi.html néven elmentjük, majd egy böngészıben megnyitjuk, csak annyit látunk belıle, hogy Feldolgozott XHTML kód. Bármely böngészıben azonban lehetıség van arra, hogy megtekintsük az oldal forrását, azaz az alábbi kód ismét megjelenik. Ez böngészıtıl függı módon vagy a Jegyzettömb eszközzel jelenik meg (Internet Explorer), vagy specifikus, szintaktikailag kiemelt módon (Firefox).
XHTML kódolás <meta http-equiv="Content-Type" content="text/html; charset=iso8859-2">
Feldolgozott XHTML kód
Mi történik tulajdonképpen? A böngészı a megjelenítés elıtt végigolvassa a szöveges kódot és végrehajtja az abban megadott utasításokat. Az elsı sor - több más között jelzi, hogy XHTML típusú dokumentumról van szó és ez a World Wide Web konzorcium által kiadott 1.0 XHTML verzió szerinti "Document Type Declaration, DTD", azaz dokumentum típus deklaráció szerint készült. Ebbıl a böngészı sokat 36
A webprogramozás alapjai megtud, például azt, hogyan kell kezelnie a dokumentumot, milyen régebbi verziókat és szabványokat vegyen figyelembe. A tényleges kód ez után jön és a html teg jelzi a dokumentum kezdetét, ami általában egy fejrésszel indul (head teg). A fejrészben ismét fontos információk találhatók a böngészı számára, de ezekbıl csupán a title teg által azonosított (a tegek felépítésérıl majd késıbb bıségesen lesz szó) szövegrész kerül megjelenítésre, ez a cím, ami a böngészıben az ablak legfelsı keretében megjelenik. A meta teg sorából a böngészı megtudja, hogy milyen a tartalom - jelen esetben ez szöveges/html és egy nagyon fontos utasítás következik a böngészınek: milyen karakterkészletet használjon a megjelenítéshez. A karakterkészlet fontossága nem hangsúlyozható eléggé! Az iso-8859-2 teszi például lehetıvé a normál "ő" és "ı" betők megjelenítését, más karakterkészletben a "kalapos" ő, ı jelenik meg. Fontos, hogy a helyes karakterkészlet legyen beállítva!9 A megjelenítendı információ és annak leíró kódja a body teg után következik, azaz itt a böngészı elolvassa a kódot és az utasításoknak megfelelı betőtípussal, nagysággal és színnel, illetve kiemeléssel jeleníti meg. Ez az, amit látunk is majd a böngészı felületén. Amennyiben új oldalra megyünk tovább - akár egy linket követve, akár új URL megadásával - a böngészı az aktuális ablakban az új oldalt értelmezi, azt jeleníti meg. Ne felejtsük el, hogy a megjelenítés mindig két dimenzióban történik, új oldalt - kivéve, ha új ablakot nyitunk - csak a régi helyére tölthet be a böngészı! Ahogy ez elvárható az XHTML nyelv esetében, a body részt lezárjuk () majd lezárjuk a dokumentumot magát is (
