2009. 01. 16.

Arra gondoltam, hogy leírom a honlap építés során szerzett tapasztalataimat, hátha hasznát vehetik azok, akik hozzám hasonlóan lelkes amatőrként saját honlap létrehozásába kezdenek, és a véletlen, vagy egy indexelőrobot szeszélye folytán rábukkannak erre az oldalra
Nem mintha mostanára már profivá avanzsáltam volna, hanem éppen azért, mert bizonyára ugyanazokat a hibákat követtem és követem el, mint ők.
Másrészt ennek a weboldalnak a szerkezete (És így a forráskódja is) eléggé egyszerű ahoz, hogy például (Véletlenül sem mintául) szolgálhasson egy kezdő számára. Ha már túljutottak a kezdeteken, akkor pedig átlényegülhetnek elrettentő példává. A forráskódokat minden böngésző képes megjeleníteni, többnyire a jobb kattintásra megjelenő felbukkanó menüből.

Amikor nővérem példáján felbuzdulva saját honlap létrehozásába akartam kezdeni, a neten néztem utána, hogyan is működik az ilyesmi. Gyorsan kiderült, hogy mindenekelőtt a HTML jelölőnyelv megismerésére van szükség. A neten számtalan a nyelvet leíró, vagy használatát oktató oldalat találhattam. Néhány ezek közül:

• W3C HTML 4.01 Specification (4.01 verzió teljes leírása angolul)
• HTML code tutorial (angolul)
• HTML alapok (Oktató anyag)
• HTML Dokumentumok Írása (Oktató anyag)
• Bevezetés a HTML-be (Oktató anyag)

Megvásároltam a World Wide Web programozása című könyvet is (szerző: Robert W. Sebesta), amely nem részletes HTML oktatóanyagot tartalmaz, hanem áttekintést a HTML-ről és webprogramozásban használatos programozási nyelvekről (Javascript, Java, PHP, Perl).

A HTML nyelv igen érthetőnek egyszerűnek tűnt, tehát jöhetett a következő kérdés: Hogyan tárhatom a mélyen tisztelt, és már türelmetlen publikum elé munkálkodásom gyümölcsét?
Nos, ehez keresnünk kell egy webtárhely szolgáltatót, és regisztrálnunk kell nála. Ha kellő színvonalon bírjuk az angol nyelvet az oldal üzemeltetőjével szükséges kommunikációhoz, akkor a lehetőségek száma elépesztően nagy, magyar nyelvű szolgáltató viszont nics túl sok, de az alábbi felsorolás korántsem teljes:

• Tár.hu
• Ultraweb.hu
• Freeweb.hu
• Gportal.hu

Nagyreményű honlap­om számára én az Extra.hu-t választottam. Mivel nincs tapasztalatom más szolgáltatóval kapcsolatban, nem tudom minősíteni a szolgáltatást. A dolog működik.


Később, a honlap bütykölgetése során egyre zavaróbbá vált, hogy az éles teszteléshez mindig fel kellett tölteni FTP -n keresztül a megváltozott fájlokat az Extra szerverére, és ez eléggé lelassította a munkát. Telepítettem tehát a gépemre egy Apache webszervert, és a szükséges körítéseket az XAMPP webszerver csomag felhasználásával, és máris a saját gépemen tesztelhettem.
Egy másik gépemen a WAMP webszerver telepítő csomagot használtam. Az is bevált.

Miután már van mit, van hol, a következő kérdés: Mivel?
HTML szerkesztéshez elméletileg tökéletesen megfelel a legprimitívebb szövegszerkesztő is. Kedvenc editorom a CONTEXT még szintaktikai kiemelésre is képes (különböző színekkel, betűtípusokkal jeleníti meg a kód eltérő szerepű részleteit), tehát jól áttekinthető a HTML kód szerkesztés közben.
Azonban kezdők számára nagy segítséget jelenthet egy úgynevezett WYSWYG típusú HTML szerkesztő program, amely meg is tudja mutatni a szerkesztett kódból előállított oldalt, és több kevesebb támogatást nyújt HTML tagek létrehozásához, és azok tulajdonságainak beállításához. Kipróbáltam az alábbi három ilyen programot:

• Amaya
• Putra Writer
• Nvu

Végül is a Putra Writer 1.9 maradt meg a gépemen. Jól használhatónak bizonyult mindaddig, amíg olyan szinten meg nem ismerkedtem a HTML és CSS használatával, hogy már inkább akadályozott, mint segített. Akkor áttértem előbb a Context majd a Notepad++ editor használatára.

Mivel manapság nem képzelhető el egy honlap beágyazott képek nélkül, szükség van azok létrehozására, manipulálására alkalmas programokra is. Ha csak kivágásra, átméretezésre formátum konverzióra van szükség, akkor a kompakt és könnyen kezelhető IrfanView a kedvencem, új képek létrehozásához, vagy meglévők tartalmi módosításához pedig a sokoldalú GIMP -et szoktam használni.

Ezek után már belevethettem magam a weboldal egyes lapjainak létrehozásába. A lapokon megjelenítendő objektumok elrendezésére a HTML táblázatok használata (<TABLE>) tűnt a legkézenfekvőbb megoldásnak. Létrehoztam tehát egy minta HTML-t, amelyben egymásba ágyazott táblázatokkal konstruáltam meg a lap vázát. Ezt felhasználva hamarosan mintegy 30 lapból állt a honlap­om, és roppant elégedetten szemlélgettem az internet böngészőmben az eredményt.
Kevésbé voltam viszont elégedett olyankor, amikor az oldalak elrendezését érintő legkisebb módosítás miatt is mind a harminc fájlt megkellett nyitnom, és a <TABLE>, <TR>, <TD> tagek dzsumbujában eligazodva (Gyakran inkább tévelyegve) lehettett csak átvezetni a módosítást. Ekkorra már hallottam valamit harangozni a stilusok ( CSS ) használatáról, és gyakran használtam is azokat, de nem érzékeltem egy-egy menübillentyű típus, vagy egyéb egyedi objektum megjelenésének módosításán messze túlmutató jelentőségüket a lapok alapvető szerkezetének kialakításában. Utánanéztem tehát a dolognak a neten, például a következő weboldalakon:

• W3C - CSS 2.1 Specification (2.1 verzió teljes leírása angolul)
• HTMLinfo - CSS 1 referencia magyarul
• weblabor.hu - CSS oktatóanyag
• cssbank.com - CSS minták
• css.lap.hu - CSS link gyűjtemény

Megvásároltam a STÍLUSLAPOK A WEBEN című könyvet is. (szerző: Sikos László).
Ezután nekiveselkedtem, és külső stíluslapban definiált tulajdonságokkal rendelkező, abszolút módon pozícionált <DIV> tagek használatára alakítottam át a HTML fájlok vázát, és az ezekbe a <DIV> tagekbe beágyazott objektumok viszonylag széles körének tulajdonságait is ugyanígy adtam meg. Bár a honlap­om a mai napig sem használja igazán konzekvensen a CSS által nyújtott lehetőségeket, de már sokkal egyszerűbbé vált a módosítások végrehajtása, hiszen az esetek nagy részében ez csak a külső stíluslapot tartalmazó fájl módosítását jelenti.
Hangsúlyozottan ajánlom tehát minden sorstársnak, hogy csak akkor fogjon hozzá egy honlap tényleges megépítéséhez, amikor már a stílusok használatában is elegendő ismeretet szerzett.

Lényegesen egyszerűbbé tette a stílusok alkalmazása a honlap­nak az egérkurzot érzékelve vizuálisan megváltozó menüinek és egyéb, más lapokra, oldalakra való átlépésre szolgáló elemneinek kódolását is. Eredetileg egy javascript függvénnyel oldottam meg a változtatást, stílusok használata esetén erre nincs szükség.

Menübillentyűk megvalósítása CSS-el:

A külső stiluslapban:

A HTML-ben:

A kód egyszerűsödésének mellékhatásaként jótékony hatással volt a stílusok szélesebb körű alkalmazása a HTML fájlok méretére is.

Mint az előbbiekből is kitűnik, a honlap építés során előbb-utóbb belebotlunk abba a problémába, hogy a HTML nyelv nem programozási, hanem jelölőnyelv. Azt a néhány funkcióját pedig amellyel némi interaktivitást lehetne szimulálni a lapokon, a legelterjedtebben használt Internet Explorer böngésző nem, vagy csak korlátozottan támogatja. Ilyenkor szokás elővenni a web kliensoldali programozására széles körben alkalmazott javascript programnyelvet.

• Veblabor javascript leírás
• TUTORIAL.HU javascript forráskódok
• MEGAPORT - Javascript - forráskódok
• javascript.lap.hu

A mai napig nem tudom eldönteni, hogyan viszonyuljak a javascripthez. Egyrészt úgy tűnik, hogy a profik különösebb aggályok nélkül alkalmazzák (Persze lehet, hogy nekik nincs is okuk aggodalomra), másrészt az internet biztonságával foglalkozó dokumentumokban igen gyakran ajánlják, hogy ne engedélyezzük böngészőnkben a javascriptek futtatását.
A honlapom látogatói statisztikái szerint a látogatók közel tíz százalékánál a böngészőnben nincs engedélyezve a javascript támogatása.
Jónéhány olyan weboldallal találkoztam már, amelynek alapvető funkciói sem működtek letiltott javascript esetén

Jelenleg ott tartok, hogy ahogyan időm engedi igyekszem kigyomlálni a honlap­omból a javascriptet amennyire az lehetséges. Az mindenképpen helyes hozzáállásnak tűnik, hogy csak akkor alkalmazzam, amikor nincs egyenértékű HTML vagy CSS megoldás.
Később azután, ha szükségét látom, alaposabban körüljárom ezt a témát.



Amikor a Fénykép-tár megvalósításába belefogtam, már volt némi fogalmam arról, hogy az ilyen jellegű feladatokat, mint nagyszámú azonos jellegű objektum (Aktuálisan képek) megjelenítése egy lapon, a PHP nyelv alkalmazásával célszerű megoldani. Utána néztem tehát a PHP -nak többek között a következő oldalakon:

• PHP kézikönyv (Angolul. A magyar egyszerűen eltűnt!)
• php-script.hu
• php.lap.hu

Belekukkantottam néhány hasonló célú PHP forráskódba is. Úgy döntöttem, hogy azoktól teljesen függetlenül oldom meg a feladatot. "Olyan is lett!" mondhatná, a nyájas olvasó, de szerintem a célnak megfelel, és ha nagyon felszaporodnak a képek, vagy nagyon unatkozom, majd továbbfejlesztem. Ez már csak azért is hamarosan meg fog történni, mert ez a lap még mindig táblázatokkal, stílusok nélkül van formázva, és ez irritál engem.


2009. 01. 21.

Megszületett a Fénykép-tár lap táblázatmentes verziója.


2009. 01. 25.

Egy ilyen egyszerű fényképalbum jó példa lehet a PHP használatára. leírom hát hogyan működik.

A megoldás lényeges eleme a fotók tárolására kialakított könyvtár szerkezet:


Az egymástól elkülönítetten tárolt teljes méretű és index képek közötti kapcsolatot vagy teljesen azonos fájlnévvel, vagy a fájlnév elején szereplő egyedi azonosítóval célszerű biztosítani. Legegyértelműbbnek a fájlnevek elején számjegy karakterekkel megadott fix hosszúságú egyedi azonosítók (001, 002, 003, ... 999) használata tűnik.

Mivel a fotók és indexképeik fájlnevében nem célszerű ékezetes karaktereket és szóközt használni, a témakör könyvtárakban elhelyezett comments.txt fájlokban lehet megadni az indexképek alt és title attribútumaiban megjelenítendő szövegeket (kép címek). A fotókkal való egyértelmű összerendelést az így megadott képneveknél is az elejükhöz fűzött, a hozzájuk tartozó képek nevében alkalmazottal azonos sorszámmal célszerű megoldani.

A képtár menedzselése a következőképpen történhet:

Ha egy témakörben új képeket akarok beilleszteni, akkor a nagy képeket a fentebb leírt módon képzett fájlnevekkel elhelyezem a témakör photo alkönyvtárában, a nagy képekből átméretezéssel készített indexképeket ugyanazon elnevezési szisztéma szerint elnevezve pedig a témakör index alkönyvtárában. A képekhez megjelenítendő neveket beírom a téma könyvtárában tárolt comments.txt fájl következő soraiba.
Ezek után a téma könyvtár legközelebbi megjelenítésekor már az új képek is megjelennek.

Ha új témakört akorok létrehozni, akkor a photos könyvtárban létrehozok egy új alkönyvtárat a témakörre utaló névvel, abban létrehozok egy photo és egy index alkönyvtárat, és azokban helyezem el a fentiekben leírt módon a nagy és indexképeket, és a címeiket tartalmazó comments.txt fájlt.
A fotóalbum megjelenítését végző Fenykep-tar-0.php fájl <BODY> tagjében elhelyezem a témakör indexképeinek megjelenítését kezdeményező utasítást, (Lásd lentebb.) és a fotóalbum újabb megnyitásakor már az új téma képei is megjelennek.

Az indexképeket úgy célszerű előállítani, hogy szélességük és magasságuk közül a nagyobbik mindig azonos értékű legyen. A példaként tárgyalt esetben ezt az értéket 100 képernyőpixelnek választottam meg. Az indexképek létrehozására az IrfanView prorgamot használtam. Annak Kép->Átméretezés menüpontjában az Oldalarány megtartása kapcsolót bekapcsoltam, és az Új méret címkéjű dobozban a Szélesség és Magasság tulajdonságok közül a nagyobbikat 100 -ra állítottam, majd OK -t nyomtam, és az átméretezett képet elmentettem.

Az indexképeket a Fenykep-tar-0.php fájlból egy fix szélességű <DIV> tagben jelenítjük meg a következő utasításokkal:


Tehát meghívjuk a Fenykep-tar-0.php fájl fejlécében definiált fotokeszlet PHP függvényt a megjelenítendő témát tartalmazó témakör könyvtár elérési útjával.
Mivel a függvény 'tudja', hogy a téma könyvtárakon belül a photo alkönyvtárakban mindig a nagy képeket, az index könyvtárakban az indexképeket, a comments.txt fájlokban pedig a képekhez rendelt neveket találhatja meg, és PHP utasításokkal ki tudja nyerni az alkönyvtárakban tárolt fájlok neveit, és a comments.txt -ben tárolt szövegeket, képes arra, hogy automatikusan megjelenítse a témakörhöz tartozó indexképeket, és mindegyikükhöz hozzárendelje a hozzá tartozó nagy képet.

A fotokeszlet eljárás az első paraméterében megkapott könyvtárban található fotókat jeleníti meg következőképpen:


A fotomutat eljárás:


A fotomutat eljárásban használt "kep" stílusosztály definíciója:


A nagykep.php -ben a következőképpen jelenítjük meg a nagyméretű képeket, ha a felhasználó az indexképre kattint:





2009. 01. 26.

Jó ötletnek tűnt a PHP használata a Letölthető AutoLisp rutinok című lap változó tartalmának előállításában is.
Először egy <IFRAME> tag használatával oldottam meg azt, hogy a felhasználó által kiválasztott funkció részletes leírása megjelenjen a választómenü alatt. Ez viszont nem tetszett, mert nem találtam elfogadható (scriptmentes) megoldást arra, hogy sohasem jelenjen meg az IFRAME gördítősávja, hanem a magassága mindig alkalmazkodjék a benne megjelenítendő tartalom mennyiségéhez.
Végül is azt a megoldást eszeltem ki, hogy a funkcióleírások PHP bővítményű fájlokba kerültek, amelyeknek elejéhez egy bennük első utasításként elhelyezett PHP utasítás hozzáfűzi az AutoLisp-Letoltes-eleje.php fájlban megadott fejléc sávot, menü és banner oszlopokat, a végükhöz pedig egy utasítás hozzáfűzi a lap végén megjelenítendő, az AutoLisp-Letoltes-vege.php fájlban megadott objektumokat. Így ugyan mindig a teljes oldal újratöltődik, de ez nem tűnik zavarónak.


2009. 01. 29.

A közelmúltban nővérkém megkért, hogy hozzak össze számára egy legördülő menüt. Szétnéztem a neten, hogyan is működek ezek, és szép számmal találtam ezzel kapcsolatos dokumentumokat. Nekem a javascripttel szemben fentebb részletezett fenntartásaim miatt a CSS -el megoldottak a szimpatikusak. Átböngésztem, kipróbáltam néhányat. Ezek általában rendezetlen listák (<UL> tag) felhasználásával oldják meg a menüt, hogy a menük egymásba ágyazása is lehetséges legyen. Ehez kellőképpen hosszú és összetett CSS -kód tartozik, általában minimális magyarázattal a lelkes amatőrök számára.

Létrehoztam hát a megítélésem szerint legprimitívebb CSS legördülő menü szisztémát, amely ugyan nem alkalmas beágyazott menük létrehozására, cserében azonban a hozzám hasonló kezdők számára is könnyen megérthető a működése, és módosítható a megjelenése.
Ezen a lapon kipróbálható a menü legegyszerűbb verziója, ezen a másikon pedig különböző megjelenésű variációit nézhetjük meg.

Természetesen az Internet Explorert kicsit rugdosni kell, hogy működtessen egy ilyen szerkentyűt. Ehez van szükség a csshover3.htc fájlra, amelynek szerzője Peter Nederlof - Allah növessze hosszúra a szakállát -.


2009. 01. 31.

Az Üzenő - füzet oldalon, az új üzenet hozzáadása funkcióban, a smiley beillesztést átalakítottam az előző fejezetben leírt szisztémára.


2009. 04. 02.

Valószínűleg az oldalak elrendezésének a CSS használata által biztosított szabadsága is közrejátszott abban, hogy a honlap alacsonyabb szintű (más oldalakról egy vagy több lépésben elérhető) oldalait az indexelő robotok meglepő gyorsasággal beindexelték, miután az oldalak releváns tartalma a HTML fájlok elejére kerülhetett. Mintegy tíz hónapig csak elvétve méltatták figyelemre a keresőrobotok a második és harmadik szint oldalait, a CSS -el megoldott átszervezés után viszont ehez képest rohamos gyorsasággal beindexelték a teljes honlap­ot.


2009. 08. 21.

Honlap­ok forráskódjában böngészve bukkantam rá arra a lehetőségre, hogy a GOOGLE térkép szolgáltatás beágyazható egy tetszőleges weblapba. Azonnal lecsaptam a dologra, és a Fénykép-tár oldalon elhelyezett, munka közben készült fotóknál lehetőséget teremtettem azok készítési helyének térképi megjelenítésére.
Ehez elsőként le kellett tárolnom a fényképek földrajzi koordinátáit. Ezeket a GOOGLE Earth -ben kérdeztem le úgy, hogy az Add placemark funkcióval a fotók helyének megjelölését kezdeményeztem, és a megjelenő dialógusablakból copy-paste eljárással kimásoltam a koordinátákat a fotók téma könyvtárában elhelyezett coords.txt fájlba, amelynek rekordjai (sorai) foto-sorszám, földrajzi-szélesség, földrajzi-hosszúság formában tartalmazzák a fotók helyét (pld.: 032 47.894756, 20.489445).
A nagyított képek megjelenítésére szolgáló 'nagykep.php' innét olvassa ki a megjelenítendő fotó koordinátáit, és ha a felhasználó a térkép megjelenítését kéri, paraméterként átadja azokat a térkép megjelenítését végrehajtó 'terkep.php' -nak.

A GOOGLE térkép használatához a Sign Up for the Google Maps API oldalon weblapunk számára hozzáférési kódot kell szereznünk, és a kapott hozzáférési kódot be kell illesztenünk a honlap­unk fejlécébe.


A megvalósitáshoz segítséget például a következő oldalakon kaphatunk:

• Google Maps Javascript API
• Google Maps JavaScript API v3 Examples
• GOOGLE MAPS ALKALMAZÁSINTEGRÁCIÓ Mashup...

Vagy a funkciót használó weboldalak forráskódjait tanulmányozhatjuk:

• Papp Ferenc földmérő honlapja

2009. 11. 15.

Amikor hozzákezdtem a honlap létrehozásához, még nem igazán voltam tisztában a karakterkódolás valódi jelentésével és jelentőségével sem. Kipuskáztam valahonnét és a <HEAD> szekcióban elhelyeztem a <meta http-equiv="content-type" content="text/html; charset=ISO-8859-2"> sort, azután mivel az ékezetes karakterek megjelenitése a böngészőkben enyhén szólva kifogásolható volt, az ékezetes karaktereket entitáskódjaikkal helyettesítettem. Ebben nagy segítséget jelenttett a Putra-Writer program, amely alkalmas arra, hogy a behelyettesítéseket elvégezze, vagy visszaállítsa az olvasható formát. Kivéve a hosszú ö és ü karaktereket. Azokat manuálisan kellett buherálni. Persze még így is eléggé nehézkes volt a fájlok módosítása, és ha egy böngészőben kértem a forráskód megjelenítését, akkor az elég gusztustalanul nézett ki, és olvashatatlan volt.
Egy netes fórumon felvetett másik problémám megtárgyalásakor vetette fel egy hozzáértő webbuherátor, hogy használjak UTF-8 kódolást, és ajánlotta ehez többek között a Notepad++ nevű editort, amely nemcsak UTF-8 kódolású szövegek létrehozásában jelent nagy segítséget, hanem számos olyan, más eddig általam használt editorokban nem ismert trükköt tud, ami jelentősen megkönnyíti a weblap szerkesztést is. Rendkívül megkedveltem, és azóta ezt használom a html fájlok szerkesztésére. Csak ajánlani tudom minden html szerkesztésel foglalkozó sorstársnak.



2009. 11. 16.

Néhány nappal ezelőtt a honlapom netes "népszerűségét", elérhetőségét vizsgálgattam, és a keresési találatok között felbukkant a http://mokusweb.com/ webcím. Utánanéztem a dolognak, és szemem-szám elállt a csodálkozástól. Megtaláltam ott a teljes honlapomat lemásolva, és valami oda nem tartozó szöveg részleteivel kellőképpen összezagyválva. Alaposabban körüljárva a webcímet kiderült, hogy komplett honlapok, és egyedi webes dokumentumok százait koppintotta le valami szorgos mókus, és az eredményt többnyire elrontott megjelenéssel elérhetővé tette a weben. Hogy ennek számára mi haszna van azt nem igazán értem, mint ahogy azt sem, hogy ez hogyan nem szúrt szemet eddig a többi ellopott honlap gazdáinak sem.

Mivel nem sok elképzelésem volt mit tehetnék, a Google webmester fórumon kérdeztem rá, ki mit ajánlana. Útmutatásuk szerint a weboldalon megadott e-mail cimre, és a szerverfelügyelő címére küldtem felháborodott hangvételű e-mailokat de csak a Mailer Daemon-ból tudtam egy-egy hibaüzenetet kicsalni, mert egyik cím sem elérhető. Úgy tűnik tehát, hogy nem egy kleptomániás felhasználó lopkodott össze ennyi dokumentumot, hanem az egész mokusweb.com egy kalózvállalkozás.

Hogy legalább a legkiterjedtebben használt kereső találataiból kikerüljön az elvetemült rágcsáló, jeleztem a problémát a Google jogi problémák jelentése célra fentartott oldalon. Két nappal a jelzés után a Google webmester fórumon jelezte a Google egyik alkalmazottja, hogy foglalkoznak a dologgal. Most kíváncsian várom, mi lesz az eredmény.



2009. 11. 17.

Úgy tűnik a Google nem teketóriázott. A mokusweb.com -ra keresve az eddigi 14000 körüli találat helyett csak mintegy 30-35 jelenik meg, azok is csak hivatkoznak a mokusweb-re.
Remélem nem szúrtam ki egyetlen gyanútlan sorstársammal sem, aki esetleg ezen a címen regisztrált, és építgetett honlapot.


2010. 01. 11

A múlt év decemberében néhány online használható programmal egészítettem ki a honlapot. Egyrészt azért, mert betegségből lábadozva töméntelen időm volt, másrészt szeretném egy kicsit feltornászni a jelenleg elég szerény látogatottságot. Nem mintha ebből akarnék megélni, de hát különben mi értelme lenne az egésznek.
Átböngésztem tehát az oldalamról a webszolgáltatóm által generált statisztikát és találtam néhány olyan viszonylag gyakori keresőkifejezést, amely arra utalt, hogy egyes látogatók talán a honlap témájába vágó webes szolgáltatás után kutatva jutottak el hozzám.
Ezen témák némelyikéhez hoztam létre eddig összesen hat darab online szolgáltatást nyújtó oldalt.

Ennek kapcsán újra felmerült a kérdés, hogy hogyan viszonyuljak a javascript -hez. Hiszen a felhasználó szempontjából az lenne a legflottabb megoldás, mert a számítások elvégzéséhez nem kell elküldeni az adatokat a szerverre, és az eredménnyel újra letölteni az oldalt.
Végül is, nehogy a következetesség bűnébe essek, egyes feladatokat PHP-vel másokat javascript-el oldottam meg. Azután törtem a fejem, hogyan lehetne a kedves látogatót értesíteni arról, hogy a javascript-es oldalon felesleges kísérleteznie, ha nincs engedélyezve a böngészőjében a javascriptek futtatása. Természetesen nem úgy, hogy nagy bötűkkel kírom, ha van rá szükség, ha nincs, hiszen az olyan snassz.
A dolog nyilván csak magával a javasrcipttel oldható meg, mivel csak akkor tisztázható a helyzet, amikor az oldal már letöltődött. És itt azután bekerítve érzi magát a mezei webbuherátor. Egészen addig, amíg észbe nem kap, hogy javascripptel nem csak megjeleníteni lehet valamit, hanem megjelenésében módosítani, akár eltüntetni is. Tehát a megoldás az, hogy az oldal forrásában állandóan szereplő hibaüzenetet eltüntetjük a hőn szeretett látogató elől, ha a böngészőjében engedélyezve van a javascript.

Ezek után a következő kóddal oldottam meg a problémát:


Az eredmény kipróbálható a Mértékegység átváltás, vagy a Numerikus területszámítás oldalakon

Valószínűleg megint sikerült feltalálnom a spanyolviaszt. De közben legalább jól szórakoztam.


2010. 03. 31.

Tárhelyszolgáltatót váltottam.

Nem egészen saját jószántamból, hanem azért, mert az extra.hu üzemeltetője a DotRoll Kft. 2010. 03. 31. után megszüntette az addig ingyenes szolgáltatásait, és valahogy nem hittem abban, hogy a DotRoll -nál kellene webtárhelyet bérelnem.

Végigböngésztem a neten a magyar tárhelyszolgáltatókat, próbáltam megállapítani, hogy melyiknél érdemes tárhelyet bérelni. A leglényegesebb szempont az elfogadható bérleti díj volt. Ezen a téren igen nagy szórás van a szolgáltatók között. Egyes helyeken néhány száz MB -os statikus tárhely havi bérleti díja akkora, vagy magasabb, mint más szolgáltatóknál az 1-2 GB -os dinamikus tárhelyek évi költsége. Feltételezhetjük persze hogy a magasabb bérleti díjak profibb szolgáltatást garantálnak, de vajon biztosak lehetünk ebben? Egyébként is egyenlőre nem szándékoztam 10, maximum 15 ezer forintnál többet kiadni tárhely bérlésre.
Az ezek után versenyben maradt szolgáltatók közül azután már csak megérzés alapján választottam az Intrex-Hosting Kft. -t.
Így néhány hét tapasztalatai után nem igazán vagyok elbűvölve sem tőlük, sem a megérzéseimtől, mivel úgy tűnik, hogy gyakorlatilag nem létezik náluk support szolgáltatás, mert azt nemigen nevezhetjük support szolgáltatásnak, ha a feltett kérdéseimre 4-5 nap után válaszolnak. A legutóbbira egy hét után is hiába várom a reagálásukat. Ehez képest a DotRoll -nál szó szerint chat -elve tudtam tanácsot kérni a régi domain nevem átirányításával kapcsolatban, és pár perc alatt meg is oldhattam a feladatot. Lehet, hogy mégis inkább mellettük kellett volna döntenem?

(2011. 11. 10: Lényegesen javult a szolgáltatás ezen a téren, mind a válaszidő, mind a válaszok használhatósága tekintetében.)

A fizetős tárhelyhez persze saját domain név is kell tartozzon. Regisztráltattam tehát a pf-prg.hu domain nevet, és amint létrejött a regisztráció, felpakoltam az új tárhelyre a honlapomat, a régi tárhelyen pedig az oldalak fejlécében rikító üzenetet helyeztem el, amely felhívta a látogatók figyelmét, hogy április elsejétől csak az új tárhelyen lesz elérhető a honlap, és e-mail-ben értesítettem a honlapomra mutató linkek oldalgazdáit, hogy linkjeiket írják át az új webcímre.
A biztonság kedvéért éltem azzal a DotRoll Kft. által felkínált lehetőséggel is, hogy az eddigi pf.prg.extra.hu aldomain nevemet méltányos évi 1000 Ft. -os díjért megvásárolhatom, és átirányíthatom a honlap új címére.

Most ott tartok, hogy árgus szemekkel figyelem milyen tempóban indexeli be a Google honlapomat az új tárhelyen. Eddig meglepően gyorsnak tűnik a dolog, de bizonyára minimum négy öt hétig eltart amig megközelíti a régi helyen elért eredményeit

A tárhely szolgáltató váltással kapcsolatos kalandjaim kapcsán azt tudom ajánlani mindenkinek, hogy ha honlap építésébe kezd egy ingyenes tárhelyen, legalább a saját domain név regisztrálására ne sajnálja azt az évi néhány ezer forintot, mert a domain név birtokában sokkal könnyebben megoldhatja a honlap költöztetését a keresőkben elért helyezések, és a rendszeres látogatók megőrzése mellett, ha az bármilyen okból szükségessé válik.


2010. 11. 11.

Néhány napja kaptam egy e-mailt, amelyben egy webprogramozással is foglalkozó úr hívta fel a figyelmemet arra, hogy léteznek úgynevezett CMS (Content management system = Tartalom Kezelő Rendszer) rendszerek, online menügeneráló programok, és más rendkívül hasznos eszközök, amelyekkel megspórolhattam volna a fentebb leírt, vagy ott meg sem említett kínlódásaim elsöprő többségét.

Az igazság az, hogy részben már az induláskor tisztában voltam ezzel, hiszen ahogyan írtam, nővérem példáján felbuzdulva kezdtem saját honlapot építeni, és ő egy olyan helyen regisztrált tárhelyet, ahol csak egy ilyen rendszer használatával lehetet honlapot létrehozni. Nekem viszont ez nem volt ínyemre való, mert már gyermekkoromban is magam készítettem a játékaimat, és a honlap építésben is az motivált, hogy sajátkezűleg bütykölhetek össze valamit ami működik.
A honlap fejlesztése során, amikor a felmerült problémákra kerestem megoldást, még számos olyan lehetőségre rábukkantam, amelyek hasonló módon megkönnyíthetik egy-egy részfeladat megoldását. Ezek közül csak az üzenő füzetet működtető kódot vettem át, de később azt is teljesen át kellett dolgoznom, részben azért, hogy illeszkedjen a honlap többi részének dizájnjához, másrészt azért, mert kiderült, hogy szinte semmi védelme nem volt a rosszindulatú beavatkozásokkal szemben, így egy agyament "hacker" tele is nyomta az üzenő füzetemet halandzsa üzenetekkel.

Mivel így álltam a dolgokhoz, ezen az oldalon is elfelejtettem megemlíteni ezeket a lehetőségeket, pedig sokan használják, és bizonyára tökéletesen megfelelő megoldást kínálnak azok számára, akiket csak a végeredmény érdekel, és szeretnének ahoz minél gyorsabban és kényelmesebben eljutni. Így hát most megpróbálom pótolni a hiányt.

A tartalomkezelő rendszereket illetően a Joomla, Drupal, PHP Nuke, WordPress nevezetűekről hallottam valamit harangozni. Részleteket nem tudok róluk. A lényeg az, hogy fel kell telepíteni a kiválasztottat az elkészítendő honlap tárhelyére, majd annak segítségével kialakítható a honlap megjelenése, és feltölthető annak tartalma is.

Ha például elegáns és ötletes menükkel akarjuk kiegészíteni az oldalt, a neten számos letölthető ,vagy online használható menügeneráló programot találunk.
Hasonlóképpen találhatunk kész kódokat vendégkönyvre, fotóalbumra, és még sokféle egyéb célra is.


2012. 02. 19.

A honlap funkcióinak bővítése javítása során a javascriptek használatával kapcsolatos fentebb felvetett aggályaim jelentősen átértékelődtek. Egyrészt azért, mert tapasztalataim bővülésével többnyire találok olyan megoldásokat, amelyek használatával az oldalak letiltott javascript mellett is működőképesek maradnak. Erre jó példa lehet a Fénykép-tár lap legújabb verziója. Másrészt vannak olyan funkciók, amelyek javascript nélkül nem is lennének megvalósíthatóak, mint például a Google térkép megjelenítése, de nem szeretnék lemondani róluk.

Az ilyen feladatok megoldása során gyakorta beleütközik az ember abba a problémába, hogy a javascript kód a kliens gépen (A weboldal látogatójának számítógépén) fut le, akkor amikor az oldal kódja oda már letöltődött, és alapvetően nem alkalmas arra, hogy a weboldalt kiszolgáló szerverrel érdemben kommunnikáljon. A PHP nyelvű szkriptek pedig a szerveren hajtódnak végre, és csak az általuk előállított kimenet jut el a kliens gépre. Tehát a kétféle nyelven megírt kódok nem képesek közvetlenül információkat cserélni, pedig erre néha szükség lehet.
A nagy webguruk bizonyára számos trükköt tudnak bevetni ennek megoldására, én egyenlőre a következőket tudom alkalmazni ilyenkor:

Ha a szerver oldalon futó PHP szkripttel akarok információt átadni a kliens oldali javascriptnek, akkor legcélszerűb a PHP kimenetében elhelyezni azt úgy, hogy az az oldal vizuális megjelenését ne befolyásolja, és javascripttel könnyen kinyerhető legyen a kliens oldalon. Először úgy tűnt, hogy erre a legalkalmasabb megoldás az, ha a PHP az oldal forrásában elhelyezett rejtett input tag value tulajdonságában adja át például az alábbi módon:


Ezt a kliens oldalon javascripttel a következőképpen olvasom ki:


Ennek eredményeképpen a javascript adat nevű tömbváltozójának elemeiben megjelenik a szerver oldalon megadott név, cím, stb.

Azután rájöttem, hogy ha már úgyis a javascipt értelmezőnek szánjuk az adatokat, akkor célszerűbb azokat eleve javascript változókként beszúrni az oldal kódjába, például így:



Ennél kissé bonyolultabb annak megoldása, ha a kliens gépről akarom javascripttel megszólitani a szerver oldalt. Jelenlegi ismereteim szerint erre a megoldást az Ajax technika jelenti. Ezzel javascript kódból úgy hívhatunk meg egy a szerveren található fájlt, hogy az nem fog letöltődni az aktuális tartalom helyére, hanem végrehajtásának eredményét kapja meg egy általunk megadható javascript függvény, amelyben azután igen változatos módon használhatjuk azt fel.
Ilyen módon kérdezi le a nagyméretű képek megjelenítéséhez a kép méreteit, vagy a fotó készítési helyének bemutatásához a hely földrajzi koordinátáit a Fénykép-tár oldal legújabb verzióját működtető javascript kód.

Példa kódot egyenlőre nem biggyesztek ide, mert igen részletesnek és érthetőnek tűnik például a W3Schools Ajax Tutorial oldlalain fellelhető oktatóanyag. Ennek nem minden részletét rágtam meg alaposan, de így sem volt különösebb gond az első működőképes Ajax technikát használó kód megírása.


2012. 04. 02.

Eddig megfeledkeztem egy igen hasznos segédeszköz megemlítéséről. A honlap új tárhelyszolgáltatóhoz költöztetése után nem sokkal regisztráltam a Google Analytics szolgáltatásába, amely igen részletes és hasznos statisztikákat szolgáltat az oldal forgalmáról. Az én passzióból működtetett oldalam esetén is érdekes információk szűrhetőek le ezekből, Egy üzleti célú oldal esetén pedig nélkülözhetetlenek az így elérhető adatok

Most azért jutott eszembe itt megemlíteni, mert egy igen kellemetlen hiba létezéséről nélküle valószínűleg nem, vagy csak alaposan megkésve értesültem volna.
Ott kezdődött az ármány, hogy úgy döntöttem, Facebook like billentyűt biggyesztek a lapokba, mert az olyan trendi. Előböngésztem a megfelelő weboldalt, ahol néhány paraméter megadása után tálcán kínálták nekem a beépítendő tartalmat, amely lényegében két <div> tagből és az azok kidekorálására szolgáló javascript kódot betöltő szkriptből áll. Hogy azért ne legyen olyan egyszerű a dolog, úgy oldottam meg, hogy mindezt egy javascript függvény szúrja be a lapokba, amelyet egy olyan js fájlban helyeztem el, amelyet már régóta betölt meghíváskor minden fontosabb lap. Így nem kellet kb. ötven html vagy php fájlban végrehajtanom beszúrást, és bármikor könnyen módosítható lesz a kód.
Némi tesztelgetés - javítgatás után a dolog működött, fel is töltöttem a tárhelyre. Másnap az Analytics statisztikáimat böngészve feltűnt, hogy egyes oldalak url -jében (webcímében) olyan ismeretlen paraméter ( "fb_xd_fragment=" ) szerepel, amelyet én sohasem használtam. Először valami figyelmetlen felhasználó hibájának véltem, de amikor kiderült, hogy több helyről is érkeztek ugyanilyen paraméterrel elrontott oldallekérések, arra kezdtem gyanakodni, hogy valaki/valakik megint a honlap feltörésével kíserleteznek. Gyorsan utána néztem tehát a dolognak a neten. Az eredmény az lett, hogy a jelenség oka a Facebook button funkcióit megvalósító javascript kódban rejlő hiba, amelynek jóvoltából a látogató egy szép, tiszta és üres oldalt fog látni, a fáradságos munkával összegányolt oldalam helyett, és ha nem ír nekem erről egy zsörtölődő e-mailt valamelyikük, vagy nem használok Google Analytics -et, akkor sohasem értesülök a hibáról.
Mivel minden ilyen oldallekérés kapcsán mívesen káromkodó látogató, vagy a lapot a webindexből is kiírtó keresőrobot képe rémlett fel lelki szemeim előtt, azonnal le is tiltottam a Facebook buttonok megjelenítését, és nekiláttam a megoldás keresésének. A Facebook, bugok sorsát nyomonkövető oldalának ezzel a hibával foglalkozó lapján egyrészt az derült ki, hogy a probléma nem újkeletű, másrészt, hogy a Facebook fejlesztői nem pocsékolják drága idejüket a megoldására. Gondolom, minden energiájukat leköti a felhasználók netezési szokásainak nyomonkövetésére szolgáló kódrészletek csiszolgatása.
Tovább matatva a neten, találtam megoldásként elővezetett trükköket, de nem volt számomra világos a működésük és pontos kivitelezésük módja, így nem kockáztathattam meg a használatukat anélkül, hogy az eredményt tesztelni tudjam. Ugyanis a hibát a rendelkezésemre álló legbutább Internet Explorerrel sem tudtam reprodukálni, látogatókkal és keresőrobotokkal viszont nem illendő, illetve nem ildomos kísérletezni.
Más, Facebook buttont tartalmazó oldalak forráskódját átböngészve találtam rá egy egészen más módon működtetett Facebook button kódra, amely reményeim szerint megoldás lehet a problémára. Ez egy <iframe> -tagbe a Facebook szerveréről betöltött PHP fájllal jelenítteti meg a buttont. Lehet, hogy ez a megoldás is alkalmaz javascriptet, de talán az <iframe> karanténjába zárt script nem tud gondot okozni nekem. Azért még körbeszaglászom a dolgot, mielőtt élesben alkalmazom.


Folytatása következik.