Fórumok
Mai napon megjelent a LISA nevet viselő PHP keretrendszer 0.2.0-ás stabil verziója, mely kihasználja a PHP 5.3 nyújtotta lehetőségeket. A rendszer az elmult majd egy évben rengeteget fejlődött, és számtalan eszköz teszi élvezetesebbé a fejlesztést, absztrakciós rétegeinek köszönhetően pedig könnyedén testre szabható. A dokumentáció folyamatos frissítés alatt áll, ízelítőt itt és itt talál a kedves olvasó.
Hozzászólások
Miért döntöttél úgy, hogy létrehozol egy új PHP framework-öt?
Az ok igen egyszerű, számtalan olyan egyedi elképzelésem volt/van, amit nem találtam meg semelyik másik fellelhető rendszerben.
- Ilyen megoldás pl az url kezelés. Alapértelmezetten van egy config állomány ahol regexp-ek segítségével tudom kinyerni, hogy melyik url-re melyik controller fusson le, annak melyik funkciója, lehet beállítni statikus változókat, illetve a regexp találatait is változókba lehet helyezni. Többnyelvű oldal esetén csak a variációkat kell felsorolni. Amennyiben az a megoldás nem tetszik vagy nem alkalmas az adott feladatra a Config.ini-ben átírod a handler paramétert egy másik osztályra, máris lecserélted az url feloldását kb 2 mozdulattal.
- Egy másik alappillérje a keretrendszernek a model, mely 2 részből tevődik össze. Az egyik rész maga a Model, ami keres tárol, számlál stb, a másik elem pedig az Entity, amely az adatbázis adott sorát reprezentálja. Amennyiben valami miatt nem az alapértelmezett Entity-t akarod használni, egyszerűen a Model-nek paraméterként átadod, hogy melyik osztályt használja fel a fentebb sorolt műveletekhez. Ennek eredményeképpen mindig csak a külömbséget kell programozni ha valamiben el szeretnék térni az alapértelmezett működéstől.
- Példának mondhatnám még a Viewt, ami amellett, hogy szintén egy mozdulattal lecserélhető tud teljes cachelést. Tehát ha beérkezik a kérés, és talál érvényes cache-t, akkor kitolja a már teljesen legenerált tartalmat, elég sok erőforrást megtakarítva.
- A képméretezési megoldás is elég egyedi szerintem. Minden képre vonatkozó kérés egy php-be fut, ami megnézi, hogy létezik-e az adott fájl a megadott méretben. ha létezik visszaadja, ha nem akkor a megadott négyzetbe méretezi a képet, és elmenti, hogy legközelebb meglegyen. Ez működés közben úgy néz ki, hogy HTMl-ben src="/images/kep_100x100.php" ezt egy sitebuilder is megtudja csinálni, nekem nem kell foglalkozni a képekkel, max csak feltölteni.
Biztos tudnék még litániát írni, de nem ez a cél. A végeredmény egy igen kézreálló, flexibilis, magjában "lightweight", de funkcióiban teljes keretrendszer lett.
.:LISA PHP Framework:.
hehe, elso 3 pont az en listamon is rajtavan amiert elkezdtem atirni a java spring frameworkot phpba anno (legalabbis az alapfunkcioit tekintve lemasolni) :) abban is hasonlokeppen vannak ezek a dolgok. Az en listamon meg volt dependency injection es inversion of control is tobbek kozott
Azt örömmel tapasztaltam, hogy a wed.xml-ben egy része visszaköszönt az url feloldásnak, amit használok, mikor Java-val kezdtem foglalkozni. A Model-Entity páros kialakításába is nagy ihletést adott a Java-s EntitManager-Entity páros. Jó volna ha PHP tanulna egysmást a Perzisztencia-kontextusból, de ez egy szép álom. El tudnék képzelni egy p2ee-t :)
.:LISA PHP Framework:.
Hat elvileg springben (meg az atiratomban is) a configban felsorolod ugyanigy az urleket meg hogy melyik controller kezelje, es majd aztan ezt az egesz configot, beleertve az url stringet (hogy patternkent kezelodik e vagy akarhogy mashogy) majd egy handler class fogja feloldani amit akar le is cserelhetsz barmilyen sajat megvalositasra (persze nyilvan az interface-t meg kell valositania de azutan akar feltalalhatod a "myPatterns" mintanyelvet is, es adhatsz meg abban urleket, mert ugyis a te classod fogja kiertekelni).
Entityk ~domain objectek, bar tipikusan tobb mint csak egy adatbazis rekord, inkabb egy logikai egyseg, de sokszor tenyleg csak annyi itt is (bar van un. Rich domain object is, ami mar lehet joval bonyolultabb)
Object perzisztencia tenyleg egy szep alom :) Probaltam ilyen automatikus serializalgatasokkal kicsit utanozni a framework szintjen mielott ugye konkretan eljutna az oldal a userspace feldolgozo objektumokig, csak igy a proba kedveeret, de ugyebar erossen korlatoltak a lehetosegek az esetleges parhuzamos requestek miatt. Ha meg lockokat raksz mindenhova akkor nagyon be fog lassulni.
"Entityk ~domain objectek, bar tipikusan tobb mint csak egy adatbazis rekord" ez így van, viszont LISA-ban az alapértelmezett Entity csak egy rekord - nincs idegen kulcsos összekapcsolás meg semmi -, ere írtam, hogy ha valami bonyolultabbat akarsz, akkor azt meg kell írni, és át kell adni a Model-nek, hogy ne az alapértelmezett Entity-t használja .
.:LISA PHP Framework:.
Kérdezem, hogy miért volt fontos a számodra, hogy php 5.3.* kelljen hozzá.
--
Ami elől menekülsz, az után szaladsz.
Segít a konkurenciának.
eztnemértem!
.:LISA PHP Framework:.
Viccvót.
A rövid válasz az, hogy van 5.3-as PHP miért ne lenne egy keretrendszer ami ki is használja?
A hosszabb válasz az, hogy van egy futó project, ami 3 részből áll. Van egy adminisztrációs felület ahol a megrendeléseket lehet kezelni, meg modulokat lehet feltölteni, meg felügyelni lehet az egész rendszert, nevezzük A-nak. Vannak kissebb egységek, akik használják a modulokat, ezek egyébként komplett weboldalak, legyenek B-k, és minden B-hez tartozik egy adminisztrációs felület, C, ahol a honlappal kapcsolatos ügyesbajos dolgokat intézhetik a felhasználók. És van a keretrendszer egy központi helyen D. Azt találtuk ki, hogy ne kelljen sok kódot karban tartani, hogy minden B, A helyről szedi a modulokat, és központi C helyről szedi az adminisztrációs modulokat, és mind A,B,C - D helyről szedi a keretrendszert. Ennek eredményeképp nincs kódduplikáció, egy javítást csak egy helyen kell elvégezni, a B helyeken szinte csak a grafikus megjelenést kell tárolni, meg a class autoloadert. A probléma áthidalására a névterek hozzák a megoldást, tehát \A\Valami() meg \B\Valami()... Persze csinálhattuk volna A_Valami meg B_Valami-re de épp mikor ezt kitaláltuk, aznap jött ki a 5.3-as PHP, és gondoltuk 2 legyet csapunk egycsapásra:
- a problémánk elegánsan oldodik meg
- a keretrendszer 5.3 ready lesz
.:LISA PHP Framework:.
Viszont akiknek a tárhelye még nem 5.3-ast futtat, nem fogja tudni használni még egy ideig élesben a kódot ha erre a keretrendszerre épít.
De hát, vesszenek a fejlődés kerékkötői. Feltéve ha van értelme a fejlődésnek.
Az előző stabil 0.1.8-as verzióhoz képest funkcionalitásban nem sok újdonság került, az pedig továbbra is elérhető a innen és az 5.2.x-es PHP-ra van írva.
.:LISA PHP Framework:.
off
Gondolod, hogy érdemes olyasvalamit bebetonozni a rendszerbe, ami jó esetben egy év alatt hömpölyög át a világon, a tárhelyszolgáltatók amúgy is lusta frissítési szokásainak köszönhetően? Bátorságra vall. Én inkább a lassan kihulló posix regex és egyéb funkciókat szedem ki a régi kódjaimból, úgy érzem mintha egyre kevesebb funkciót mernék használni.
Nézd szerintem komolyabb projecteket saját szerveren hosztol a jóízlésű megrendelő. Az előző verzióhoz hibajavítást nyújtunk, mivel számtalan project fut azon, ha találunk hibát természetesen foltozzuk (tudom nincs tökéletes rendszer de április óta éles üzemben elég sok site használja, így a hibák száma eléggé lecsökkent, jelenleg nincs ismert bug), így azok akik nem tudnak/akarnak 5.3-asra fejleszteni továbbra is megtehetik az előzővel. Mivel egyébként is átírtuk volna saját felhasználásra, miért ne tettük volna közzé? Ahol használjuk ott megér annyit hogy feltegyük az új PHP-t, valljuk be nem nagy ördöngősség.
.:LISA PHP Framework:.
Csak azért kérdezem, mert használok egy pár linux disztribúciót, és egyik stable-ban sincs benne az 5.3. Amíg nem lesz, nem is fogom telepíteni, és így a LISA-t sem fogom kipróbálni. Lehet, h addigra már el is felejtem. :-(
--
Ami elől menekülsz, az után szaladsz.
brekekének válaszoltam erre a kérdésre, tehát az előző stabil verzió 5.2.x-es PHP-ra épül és még dokumentáció is több van hozzá.
.:LISA PHP Framework:.