PHP ve vlastním rámu
Varování pro neprogramátory: pokud nejste programátoři, nebude tomuto článku pravděpodobně rozumět. Proto si raději přečtěte něco jiného.
Varování pro programátory: tento článek obsahuje nápady jdoucí proti některým zaběhnutým praktikám. Pokud lpíte na coding standards a desing patterns, nebude se vám tohle líbit.
tohle. kurva. ani. omylem.
-- Ed Finkler: Manifest miniaturního PHP
Nemám rád Symfony framework. To natolik, že jsem si to přidal do životopisu, začal jsem psát hejtovací článek a založil si repozitář s kritikou Symfony na Githubu.
Ve firmě, kde pracuji, bylo totiž rozhodnuto, že Symfony je ta cesta, kterou chceme jít. A tak (více či méně tiše) trpím a moje frustrace ze Symfony roste.
Jako každý správný programátor i já programuju ve svém volném čase. A jako každý správný PHP programátor i já jsem si (někdy kolem roku 2013) naprogramoval svůj vlastní framework. Ten můj se jmenoval brickyard a jednalo se o minimalistickou záležitost - celé to bylo ve čtyřech třídách, třech rozhraních a jednom souboru. Brickyard byl použit jenom parkrát, nejlepší příklad je asi wiki, kterou jsem používal pro správu své osobní stránky.
V současné době žádný vlastní PHP framework nemám, nicméně pro potřeby dvou svých projektů - sociální sítě Kyselo a dříve zmíněného Trans Europ Express - vznikla jakási šablona, podle níž je aplikace vytvořena. Nejedná se o framework ale spíš o jakýsi rámec slepený z různých kusů kódu nasbíraných na webu.
Je celkem zajímavé tento rámec porovnat se Symfony frameworkem.
Moje architektura
- nepoužívám Composer, výhodou je okamžitá funkčnost aplikace pro rozbalení a zprovoznění databáze
- strukturu aplikace tvoří tři složky:
lib
- zde bydlí PHP soubory- v její podsložce
views
jsou pak šablony
- v její podsložce
st
- zde bydlí statické soubory (javascript, obrázky, CSS)db
- zde bydlí soubor s SQLite databází
- kontrolery jsou funkce nebo soubory, nejsou to třídy nebo objekty
- nemám napsány testy na kontrolery, v praxi jsem doposud neviděl testy kontrolerů, které by k něčemu byly
- nepoužívám thin controllers and fat models, píšu to naopak
- nepoužívám ORM, nevidím důvod, proč to používat
- používám SQLite, protože u ní funguje "rozbal a jeď"
- adminer součástí projektu, zatím nemám admin
- logika ve view, zjednodušuje to controller
- formuláře definované ve view (asi opustím)
Opačné výsledky kvůli opačným zadáním
- firma potřebuje dlouhodobou údržbu více lidmi
- já potřebuju rychlý vývoj jedním člověkem
složení ideálního frameworku
- ošetření prostředí
- autoloading
- routing
- šablony
-
request/response
- databázová třída
- formulářová třída
- výpisová třída
- administrační třída
- session třída
- přihlašovací třída