De senaste åren har det varit trendigt med indexinkludering i webbutvecklingssammanhang. Det finns en klar fördel med att göra detta, eftersom globala konventioner och inställningar görs en gång istället för flera. En nackdel är att det finns många fallgropar, särskilt för nybörjare där det kan gå fel. Vanligaste misstaget är att HTML-utskriften sker selektivt: index.php inkluderar först filen ./header.php och sedan ($_GET['page']).php. Om den unika sidan misslyckas att skriva ut bemöts användaren av ett sidhuvud och ett kryptiskt felmeddelande någonstans på skärmen, vilket är alltifrån önskvärt.
Vid användning av t ex mallar och vyer är detta problem dock eliminerat, eftersom HTML-dokumentet kommer i en enda ström istället för flera selektiva. Och problemet jag nyss beskrev är inte specifikt för applikationer med indexinkludering. Ett problem som däremot är en direkt verkan, och ett högst viktigt problem att ta itu med är det här:
http://madr.se/?controller=blog&action=archive&date=2007-08-28
Med indexinkludering blir det en massa parametrar som måste skickas efter frågetecknet. En vanlig besökare ser detta som en enda lång kryptisk kedja och visar med stor säkerhet inget intresse för den. Själv tycker jag om att kunna navigera direkt med adressfältet, och jag föreställer mig att jag inte är ensam om att vilja det. Adressfältet är ett verktyg som finns i webbläsare, precis som bakåt- och framåtknapparna, och den är mest dominant sett till dess storlek. Det är farligt att neka användare användbarhet.
Indexinkludering ställer till det för gränssnittet.
Den absolut bästa lösningen på problemet om man har Apache eller IIS är att använda en omskrivningsmodul. I Apache heter denna mod_rewrite. Ovanstående adress kan då skrivas om till
http://madr.se/webblogg/2007/8/28
Vilket är betydligt mer semantiskt och användarvänligt. Vill en användare kika på inlägg från 5:e september går det att ändra direkt i adressfältet.
Men omskrivningsmoduler går aldrig att räkna med. De kräver plattformsspecifik konfiguation, både i webbapplikationerna och på webservern. Det kräver också litet inlärning. En applikation som fungerar på utvecklingsservern som är Apache har ingen garanti att fungera om den skall användas på en publik IIS-server. Ett webbhotell har också makten att neka kunder sådana moduler för deras säkerhetspolicies (har sett sådant hända för 'mindre' saker än omskrivningsmoduler).
Såvida man inte har en egen server eller 100% koll är det alltså en risk att förlita sig på omskrivningsmoduler. Vad finns det för alternativ då, för att råda bukt på det tråkiga adressfältet?
Faktum är att jag i detta fall predikar om att gå tillbaka till enkelhet. Låt alla sidor ligga i egna filer. Vår testsida skulle i så fall se ut såhär:
http://madr.se/webblogg/arkiv.php?date=2007-08-28
Vår sidas adress har inte lika tvättsäker semantik som med omskrivningsmoduler, men det är betydligt bättre. Dessutom är implementationen så enkel att den garanterat fungerar överallt där stöd för PHP finns. Det går fortfarande att hantera utskrift med vyer, det går fortfarande att skriva komplexa MVC:er och tillämpa designmönster, eftersom varje fil agerar som kontrollerare. De procedurer som index.php innehåller i sammanhanget vid indexinkludering kan med fördel flyttas ut till en egen fil som inkluderas av varje kontrollerare. Det handlar om ett fåtal rader extra kod.
Faktum är att jag suttit och lekt med just detta till MWA, som agerar skelett åt den här webbplatsen. Jag ville ha ett skalbart MVC där det skulle gå att skifta mellan användande av frontcontroller i index.php och fallet med en fil för varje kontrollerare.
I min implementation finns det två frontcontrollers för indexinkludering, där den enda är beroende av mod_rewrite och den andra inte. Båda implementerar madr_interface_frontcontroller och sköter litet inputvalidering och annat utöver att inkludera en kontrollerar-fil.
Konstanter och andra viktiga faktorer för körning ligger i init.php, som inkluderas på första raden.
Min filstruktur:
- /cache
- /controller/pages
- /controller/scripts
- /lib
- /log
- /model
- /public
- /view
Jag lyckades uppnå sådan skalbarhet att jag endast behövde flytta kontrollerarna från controllers/pages och /controllers/scripts till /public, den enda katalogen som nås utifrån(normalt ligger endast index.php där). I varje kontrollerare lade jag till
require '../lib/init.php'
överst och i de kontrollerare som är 'pages' lade jag till
$view = new madr_view($vyfilens_namn); $view->compile();
sist i koden, då detta normalt sätt sköts av ett madr_controller objekt för mig. Och bevare mig väl, det fungerade. Jag är nöjd. :)
Nu när jag slagit mig själv i ryggen litet för att jag är så bra(;p), så reflektera litet över mina tankar. Blir allt verkligen 'snyggare' och 'enklare' med indexinkludering?