Programozás

Az Apache HTTPD egyik jellemzője, hogy ".htaccess" fájlokban is lehet bizonyos szerverkonfigurációs paramétereket módosítani. Ezek a fájlok bármely könyvtárba letehetők és az adott könyvtárszinten belül érvényesek csak. Sok alkalmazás eleve tartalmaz egy vagy akár több .htaccess-t, de előfordulhat, hogy te magad szeretnél egyes paramétereken, a szerver viselkedésén változtatni. De hova érdemes és adott esetben hova lehet tenni ezeket a változtatásokat? Tényleg csak egy jó megoldás létezik, vagy árnyaltabb a probléma? Erre próbálok választ adni a cikkben.

A programozás világában vannak olyan eszközök vagy megoldások, amiket csak egy bizonyos réteg használ vagy akár ismer. A többi programnyelven vagy adott szintű feladat esetén nincsen rá szükség. A verziókezelés nem ilyen. Gyakorlatilag a legalacsonyabb szinteken is használunk valamilyen verziókezelő szoftvert hosszú évek óta, és bár a verziókezelés a szoftverfejlesztésből indult ki, más területeken is alkalmazzák, például szöveges dokumentumok verzióinak követésére. Nem azt mondom, hogy ez az első dolog, amivel mindenkinek kezdenie kell egy fejlesztést, de leginkább nem arra kell okot keresnem, hogy miért használjam, hanem arra, hogy miért ne. Utoljára 2011-ben írtam cikket a témában, de azzal ellentétben, ebben a cikkben a verziókezelés szükségességét és értelmét próbálom körüljárni, ezzel motivációt próbálva adni azok számára, akik még mindig azt a kérdést teszik fel, hogy "mi ez és miért kezdjek neki?"

A napokban kérdezte tőlem egy ismerősöm, hogy hol talál youtube linket értelmező BB kódot. Nyilván, ma már mindenhez írtak ezerféle megoldást, de egy gyors Google kereséssel nem találtam megbízhatónak tűnőt, ezért kis gyakorlásként írtam egyet. Ezen azért nyilván lehetne még optimalizálni, de ha valakinek hiányzik egy függvény, amivel Youtube videók linkjét vagy csak azonosítóját alakíthatja lejátszható videóvá, akkor használja bátran.

Tegye fel a kezét, aki még nem bizonytalanodott el abban, hogy mikor nyúljon absztrakt osztályhoz és mikor interfészhez! Annak ellenére, hogy a különbséget általában mindenki érti vagy érteni véli, mégis néha felcserélhetőnek tűnik a kettő. És ez pedig csak bonyolódott PHP-ben, mióta megjelentek a trait-ek, amik sok esetben nagyon vonzónak tűnnek. Ezekről mind írtam 2011-ben egy összefoglaló cikkben, amit szintén érdemes elolvasni, de vajon mikor, melyiket kell alkalmazni a gyakorlatban? Ezt igyekszem tisztázni ebben a cikkben.

Van egyfajta háború az programozói világban az osztályok, interfészek és most már a PHP esetén a trait-ek elnevezését illetően. Igen szélsőséges vélemények tudnak megjelenni, amik nagyon el tudják bizonytalanítani az amúgy is bizonytalan fejlesztőpalántát, de talán még a régebb óta programozókat is. Ahogy az sajnos általában lenni szokott, sokan annyira ragaszkodnak a véleményükhöz, hogy a másik oldal képviselőin már-már szánakoznak, mily balgaságot követnek el. Azt hiszem, itt az ideje egy kissé rugalmasabb megközelítésnek és összehasonlításnak arról, hogy a fenti definíciókat miként érdemes elnevezni, illetve miért nem eredendő bűn egyik vagy másik megoldástól eltérni. A cikkben az egyes csoportok nevei a saját fantáziám szüleményei, hogy megfoghatóbbá tegyem a különbséget.

A Phar egy mozaik szó, ami a PHP Archive, azaz a PHP Archívum szavakból jött létre és egyben az archívum fájlok kiterjesztése is. Java programozók a JAR-hoz, illetve WAR-hoz hasonlíthatják. Bár bizonyos tekintetben a Windows DLL fájljaival is párhuzamot vonhatnánk, hiszen egy fájlba csomagolt programkönyvtárról beszélünk. A DLL-ekkel ellentétben viszont a PHAR fájlok futtathatók is, mint egy exe. Természetesen attól távol áll, mivel továbbra is a PHP értelmező lesz az, ami az értelmezést, futtatást végzi.

A PHAR kicsit mostoha gyerek, mert el is terjedt és nem is. Míg a JAR gyakorlatilag kéz a kézben jár a Java-val, a PHP archívumok nem ennyire általánosak és bizony gondolkodni kell rajta, hogy mikor, mire is érdemes használni, ha egyáltalán érdemes.

A PHP, fájlkiterjesztések és kódszervezés című cikkben kihagytam ezt a formátumot, ami lehetett volna szándékos, de szimplán elfelejtettem. Most viszont alaposabban körbejárom a témát. Igyekszem választ adni néhány potenciális kérdésre, illetve mutatok példákat és felhívom a figyelmet a buktatókra.

Abból, amit ez a formátum ígér, nem sikerült mindent kipróbálnom. A dokumentáció gyakran hiányos, és nem is beszélnek róla mások sem. Ettől függetlenül összeállítottam egy példasorozatot a főbb funkciók bemutatására a teljesség igénye nélkül. A példák elérhetők github-on vagy letölthetők Docker image-ként is "1.0" tag-et megadva.

A fájlkiterjesztések kérdéséről azt gondolhatja mindenki, hogy ez egyértelmű, pedig nem az. Legalábbis sokaknak valószínűleg nem. Megpróbálom tehát tisztázni, hogy egyáltalán mi a jelentősége a témának, főként PHP programozás esetén, de általában véve is. Kitérek arra, hogy mikor, milyen kiterjesztést érdemes választani, illetve mikor, milyent nem. Ha pedig nem javasolt egy megoldás, akkor mi az, ami a követendő út.

A félreértések elkerülése végett, nem arról lesz szó, hogyan tölthetsz be új tartalmat görgetéssel, hanem egy statikus weblap egyes részei között válthatsz úgy, mintha azok önálló oldalak lennének.

Megjegyzem, nem biztos, hogy én vagyok a legalkalmasabb ember ennek a témának a kitárgyalására, de minden esetre egy, a mai böngészőkben működő megoldást részletesen bemutatok és a tőlem telhető módon általánosan is beszélek a témáról.

Akit csak a végeredmény érdekel mindenféle rizsa nélkül, kattintson a tartalomjegyzékben a "Csak a végső kód" linkre.