Sokszor meglepi az ügyfeleinket, hogy egy-egy egyszerűnek tűnő változtatás vagy funkció megvalósítása milyen sok munkaórát igényel. A kedvükért lapozás után nemcsak erre a kérdésre válaszolok hétköznapi, közérthető nyelven, hanem arra is, hogy miből készül, hogyan és mivel?

A számítógép böngészője (legyen az Internet Explorer, Firefox, Safari, Opera stb.) olyan, mint az egyszerű férj: kap egy szöveges listát a bevásárlásról, és legjobb képességei szerint követve a lista utasításait, a szokásait és a felesége vélt szándékát, hazaállít mondjuk 6 zacskónyi áruval. A zacskó tartalma tekinthető mindenféle fizikai tulajdonságokkal rendelkező tárgynak – általában a feleségek így is nézik – valamint tekinthető egy írott utasítássorozat (hősi, önfeláldozó, ahogy a férjek nézik) végrehajtásaként. Ha nem tetszik a zöld mosópor, csak úgy lehet lecserélni, hogy átírjuk a listát és újra végrehajtjuk. Persze bevásárlásnál kevesen vállalják az ilyen korrekciókat, idő- és benzinigényes, ráadásul a csere se túl könnyű, úgyhogy a példa itt nagyjából használhatatlanná válik.

Ám az a szöveges-képes látvány, ami a böngészőben megjelenik, hasonló szöveges lista alapján készül: a böngésző legjobb tudása, és természetesen szabványok és szokások szerint végrehajtja a (távoli számítógépről letöltött) szöveges utasítást.

Csakhogy ez a szöveges utasítás még nem feltétlenül honlap, ez csak egyetlen oldal a böngészőben. Éppúgy, ahogy egyetlen bevásárlólista is csak egyetlen bevásárlásra ad utasítást és egy héttel később már haszontalan fecni lenne. Sok nagyképű programozó éppen ezért nem is tekinti programnyelvnek. Egy bevásárlólistára például rá lehetne írni, hogy “ha esik az eső, vegyél egy esernyőt”, sőt, akár azt is, “hogy ha 1. esik az eső, vegyél egy esernyőt, ha 2. hétágra süt a nap, vegyél egy napernyőt”, egy html nyelvű utasítássorral (így nevezik azt a nyelvet, amit a böngészők megértenek) ilyesmit nem lehet megtenni. Íme, így néz ki ennek a bejegyzésnek a html nyelvben írt kódja:

Itt mindjárt ki is használnám a példát egy szintén inkább csak szakmai körökben ismert jelenség bemutatására, arra, hogy egy-egy html nyelvű utasítássorozat gyakran más és más módon jelenik a böngészőkben. Nem érdemes mélyebben belemenni az okokba, de nyilvánvaló, hogy ha ugyanazt a listát kapná meg öt férj, más-és-más termékekkel térne haza. Igaz, a html nyelvű oldalak feldolgozását szabályozták, de ezeket a szabályokat nem minden böngésző értelmezi ugyanúgy (és persze az is előfordul, hogy hanyagságból, esetleg szándékosan másként érti, ahogy ez az emberekkel is elő szokott fordulni). Mára egyébként a helyzet egyre jobb, csak az Internet Explorer 7-nél korábbi verziói működnek szabálytalanul (emiatt vagy olyan megoldásokat kell alkalmazni, amit mindegyik egyformán ért, vagy mindenféle trükköket bevetni, hogy egy-egy szabványos megoldás az Internet Explorerben is az elvárt eredménnyel legyen végrehajtva).

A Népkert által készített honlapok ráadásul nem is ilyen “buta”, html nyelvű listák, hanem olyan programok, amik elkészítik ezeket a html oldalakat. Ha a vásárlós példával akarnám megmagyarázni, akkor azt mondanám, hogy a dinamikus oldal olyan lista, amit a feleség használ ahhoz, hogy összeállítsa a listát. Persze ilyen nincs, legalábbis nincs leírva, de le lehetne, valahogy így: “nézd meg, van-e liszt? A liszt fehér színű por, papírcsomagban. A szekrényben nézd. Ha nincs, írd fel a listába a szokásos mennyiséget (1 kg) – de ha ünnep előtt vagyunk, a szokásos mennyiség kétszeresét” (legalábbis így képzeli egy férj). Az úgynevezett szerveroldali nyelvek ilyesmik – html-oldalakat állítanak elő, éspedig úgy, hogy figyelembe veszik a környezet változását, képesek szorozni stb.

De minek? Miért nem jó, ha csak sima html-oldalak vannak?

A válasz egyszerű: akkor minden változtatás esetén ezeket az oldalakat kellene szerkeszteni. Például ha a szinte minden honlapon előforduló “kezdőlap” nevű menüpontot inkább “start”-ra szeretné átnevezni, az összes olyan oldalban, ahol szerepel ez a menüpont (és általában mindegyiken ott van, a könnyű tájékozódás kedvéért) át kellene írni a html szövegét. De ennél is abszurdabb lenne, ha minden felhasználónak, akinek eltérő jogosultságai vannak, eltérő oldalt kellene kézzel írni. A vásárlási lista is ilyen: ha minden héten ugyanazt a listát használnánk, előbb-utóbb valamiből sokkal több lenne mindig, mint amennyire szükség van, más dolgokból pedig állandó hiány.

A html oldalakat előállító alkalmazás általában php, python, ruby nyelven íródók. Ezek nagyjából hasonló tudású programnyelvek, körülbelül olyan különbség van köztük, mint három természetes nyelv között: van amit az egyikkel könnyebb elmondani, van amit a másikkal, de valójában mindegyikkel elmondható minden. Ezek a programnyelvek ugyanúgy, ahogy a html, szövegeket állítanak elő, amelyekben parancsok vannak, de ezeket a parancsokat nem a böngésző hajtja végre, hanem egy külön erre készített program. A böngészőhöz már csak a sima html nyelvű oldalak jutnak el.

Kitérő: és akkor mi az a Drupal?

A Drupal egy php-ban készült weboldal, amit eleve úgy írtak meg, hogy könnyű legyen átalakítani speciális igényekre: könnyen lehet vele szöveges-képes tartalmakat készíteni, úgy, hogy se php nyelvet, se html nyelvet nem kell használni, csak egy böngészőt. A példával élve: egy olyan listakészítő program, amivel bárki csinálhat aktuális bevásárló listákat. Sőt, bonyolítva: olyan listakészítő, ami olyan listákat állít elő, amikkel (akár) bevásárló listát (is) lehet készíteni. A Drupal által előállított html-oldalak egy része ugyanis arra is képes, hogy “magát a Drupalt” változtassuk meg velük.

A Drupalhoz bárki telepíthet viszonylag kevés tudással előre megírt kiegészítőket, amikkel mindenféle funkciók megvalósíthatók – de az élet persze mindig ki tud fogni ezeken a forgatókönyveken, és a tapasztalat az, hogy a klienseink nagy része olyasmit is kér, amit php-ban kell megírni, mert a Drupal van nem úgy tudja, ahogy szeretné, vagy egyáltalán nem tudja. Ez pedig a lehető legdrágább megvalósítási módja egy-egy funkciónak.

Emiatt mindig minden megoldás esetén jelezni szoktuk, hogy van olcsóbb, de talán kompromisszumosabb, és drágább, specifikus megoldása. A programozással elkészített megoldás mindig nehezebben és drágábban módosítható később, míg az általánosabb, előre készített megoldások könnyebben.

Akkor a holnap: puszta szöveg?

Kilencven százalékban: igen. A weboldal, a honlap és a többi mind-mind több egyszerű szöveges fájlból áll.

Persze ezek a végrehajtandó utasításokat tartalmazó fájlok nem tárolnak adatokat, hanem valamilyen egyszerű adatbázist használnak hosszú távú adattárolásra. Ebbe az adatbázisba mentik a felhasználói azonosítókat, a felhasználók által készített tartalmakat, például aloldalakat vagy hozzászólásokat, és rendszerint az oldal beállításainak a nagy részét is.

A maradék pedig leginkább kép. Jelenleg a szabványosított html-lel például nem lehet vetett árnyékokat létrehozni, ha egy elemnek árnyéka van, akkor minden bizonnyal az adott elem kép (fénykép), amit a böngésző egy adott html elem háttereként jelenít meg (vagy képként, mert a böngésző azt is tudja). Azaz a kép nemcsak a grafikai elemet tartalmazza, hanem a háttérre vetett árnyékát is.

Ezért a honlapkészítésnél általában szövegszerkesztőt használnak (nem olyat, mint a Word, inkább olyat, mint a Notepad) vagy képszerkesztőt (ha egy képi elemet több darabra kell vágni vagy át kell színezni).

Miből állapítható meg, hogy egy-egy változtatás mennyi munkát igényel?

Sajnos – csak a fentiek ismeretében – valószínűleg sehogy. A böngészőben megjelenő egyetlen szavacska mögött többféle technika rejtőzködhet: lehet, hogy böngészőből is megváltoztatható (feltéve, hogy Drupalról van szó, és felhasználó által felvitt tartalomról), de ha a szó mellett mondjuk egy mértékegység van, könnyen lehet, hogy az már csak programozói munkával változtatható meg (mert automatikusan mellé teszi a rendszer), de lehet, hogy készítettek a megváltoztatására adminisztrációs felületet, akkor pedig szintén böngészőből, “kattintgatással” módosítható. Ez kívülről csak honlapkészítői gyakorlattal dönthető el, gyakran még úgy se (általában nincsenek kizárólagos megoldások).

Tehát: kérdezni kell, lehetőleg minden alternatívára rákérdezni, mert ahány megoldás, annyiféle kompromisszum, annyi szükséges óra és annyiféle ár. Egyvalami biztos: minél olcsóbb valami, annál specifikusabb. A legolcsóbb megoldás esetében viszont egy-egy kisebb változtatás akár annyiba is kerülhet, mint maga az eredeti megvalósítása, míg a drágább, rugalmasabb megoldások később sokkal olcsóbban – akár ingyen – módosíthatók.

Éppen ezért a honlapkészítés bizalmi szolgáltatás, ahol a megrendelő rá van utalva a melósra, aki általában hőbörög amiatt, hogy magyarázkodnia kell, amellett, hogy csinálja (ráadásul nem egyszer, hanem mindig). Ez mindkét oldalról nagy adag türelmet és bizalmat igényel. De mi nem?

Tehát: mi a honlap?

Egy csomó szöveges fájl, jónéhány kép, és egy adatbázis egy internetre kötött számítógépen. A szöveges fájlok programok, utasításlisták amik – részben az adatbázisban tárolt adatok felhasználásával – olyan szöveges fájlokat (szintén utasításlistákat) állítanak elő, amit a böngésző képes értelmezni és megjeleníteni.

Figyelem! A fentiek leegyszerűsítőek voltak

Hozzátartozik az is, hogy az érthetőség kedvéért jó néhány dolgot elhallgattam: például azt, hogy manapság már lehet a böngészőnek is programot írni, ami szinte mindent tud, amit más programnyelvek (kivéve a legfontosabbat: adatot tárolni). Ezt a nyelvet javascript-nek nevezik. A html pedig kiegészül egy másik nyelvben írt programmal, ami képes külön beállítani egy-egy html által előírt elem megjelenését – bizonyos korlátok között persze (ezt CSS-nek nevezik). A javascript pedig nem tud ugyan adatot tárolni, de képes arra, hogy egy meghatározott szervernek elküldje őket, vagy lekérdezze őket attól. Ezt hívják AJAX-os technikának. Ilyenkor a szerver nem html-oldalt állít elő, csak az adatokat küldi vissza előre definiált szabványos formában a böngészőben futó javascriptnek. Ezek mind olyan nyelvek és technikák, amiket nem lehet a vásárlós példába beszuszakolni.