Ruby on Rails, CakePHP och Code Igniter
Efter att ramverket Ruby on Rails lanserades i juli 2004, har det följts av åtskilliga kopior. Slagordet är ”web development that doesn’t hurt”, och meningen är bland annat att ramverket ska tillhandahålla mycket färdig funktionalitet för utvecklaren. Majoriteten av koden i nästan alla webbapplikationer gör ungefär samma saker (exempelvis hanterar användare, laddar upp filer, visar dokument, låter användaren mata in data i formulär). Om ramverket kan göra de vanligaste uppgifterna lättare – och samtidigt utgöra ett stöd för utvecklingen – borde man kunna korta ned utvecklingstiderna.
De ramverk jag har tittat lite på är CakePHP (PHP), Code Igniter (PHP) och django (Python) – men det finns många fler. Alla dessa ramverk slåss naturligtvis om att vara det bästa. Ett citat som jag tycker är lysande och helt rätt tänkt, hittade jag i Code Igniters forum:
Use the one that you can figure out how to do something with. The less time you spend figuring out the framework, the more time you can spend coding.
Jag försökte använda Ruby on Rails, men det tog för lång tid att förstå hur jag skulle göra något. Och jag kan inte språket Ruby, alltså valde jag bort det ramverket. Istället provade jag CakePHP, som jag hade läst mycket bra saker om. Det visade sig att den inspelade video-guiden för nybörjare var helt felaktig, eftersom den inte uppdaterats efter ändringar i de senare versionerna. Den skrivna dokumentationen var knapphändig, och när jag frågade en sak i deras IRC-kanal fick jag svaret att jag nog borde titta i källkoden. Det tog alldeles för lång tid, och även CakePHP ratades.
Slutligen hittade jag rätt: Code Igniter! Inte lika mycket finesser som CakePHP, men fullt tillräckligt för att skapa webbapplikationer med. Jag var lite skeptiskt till CakePHP, eftersom det var så mycket ”magi” bakom kulisserna som jag inte hade kontroll över, eller ens förstod. Jag tror att skillnaden är att CakePHP utvecklas utan mål, medan Code Igniter, liksom Ruby on Rails, utvecklades för att möjliggöra ett konkret projekt. Ruby on Rails togs fram för att göra samarbets- och produktivitetsapplikationerna i Basecamp, och Code Igniter för att göra det kommersiella blogg/wiki/publicering/forum-verktyget ExpressionEngine. Det gör att CakePHP driver vind för våg, och ingen ställer de viktiga kraven på utvecklarna.
Också django verkar lovande. Det handlar i och för sig mest om att jag inte gillar PHP, men älskar Python. Det är dock få webbhotell som har stöd för Python, så jag har inte provkört django än.
Model-view-controller (MVC)
Dessa ramverk implementerar alla designmönstret Model-view-controller, som kan sägas vara en variant på treskiktsarktitekturen. Man separerar modellen (”model”), presentationen (”view”) och händelsehanteraren (”controller”, jag kan inget bättre svenskt ord). Genom att dela upp all kod i olika lager eller hanterare, får man renare och mer lättunderhållen kod.
Så här kan ett typiskt informationsflöde i en webbapplikation gå till:
- Användaren öppnar en URL
- Rätt händelsehanterare aktiveras beroende på URL, och denna skickar eventuellt formulärdata till modellen
- Modellen bearbetar och stoppar in data i databasen
- Händelsehanteraren startar presentationen, som hämtar data att visa från modellen
- Input från användaren inväntas
Det går självklart att använda sig av MVC utan att använda något ramverk. Men jag upptäckte att strukturen i Code Igniter uppmanade till separation, och gjorde det lite svårare att skriva fulkod. Det är ingen heltäckande lösning, förstås, men jag skulle rekommendera alla webbutvecklare att ta en titt på MVC-ramverken, och prova ett av dem. Alla mina framtida webbprojekt kommer nog göras i Code Igniter.
Läs fler artiklar om:
cakephp, codeigniter, django, mvc, ramverk, rubyonrails, webbutveckling

Jag kollade bara lite snabbt på Code Igniter, och det föll lite grann när jag såg hur den hämtade från $_POST i en model. Egentligen är det mest löjligt att vara någon slags kodpoet som tycker att det är viktigare att man följer ett ”rätt” designmönster (t.ex. MVC), men i det här fallet tycker jag att det konventionella sättet är enklare och tydligare.
Skrivet av Hannes, onsdag 16 augusti 2006, 23:41
Vad jag inte riktigt förstår med de där ramverken är att de är tänkta att ta över gränssnittet mellan mig och internet vilket innebär att hela sidan måste köras inom ramverket och inte bara en del av koden, vilket ställer till svårigheter på sitt vis.
Om någon outsourcar en viss funktionalitet på mitt bolag och jag amvänder CakePHP eller kanske Code Igniter för mina funktioner så har jag ett färdigt bibliotek som enkelt kan implementeras i uppdragsgivarens sida - om uppdragsgivaren följer samma ramverk som jag. Om inte får jag konvertera funktionerna till den situationen min uppdragsgivare står inför om det nu är ett annat ramverk eller en total avsaknad av ramverk.
Användbart vore om ett ramverk kunde agera enbart på serversidan och att jag kunde länka in det i mina script trots att de kanske ingår i ett helt annat ramverk. På så vis får jag en mer portabel kod.
Nu har jag inte orkat sätta mig in jättemycket i detta med ramverk men det känns spontant som en svårighet.
Skrivet av Pelle, onsdag 6 september 2006, 15:13
Code Igniter är ganska lätt att inkludera i det paket du skickar till din uppdragsgivare. Det är helt enkelt en massa PHP-filer, och inga avancerade inställningar behöver göras.
Däremot blir det svårt att använda Code Igniter-kod i ett annat ramverk. Men om din uppdragsgivare har ett ramverk bör du ju använda det istället.
Om du vill ha ett extremt portabelt ”ramverk” finns ju bibliotek som PEAR. Tanken med ett ramverk är att det ska vara stommen i ditt projekt, och sådana är sällan portabla eller utbytbara.
Skrivet av Christian Davén, onsdag 6 september 2006, 15:41
Jo, men det jag tänke rär att om uppdragsgivaren vill ha en blogg och jag har en blogg så måste min blogg vara i ett sådant format att den utan ett krävande konverteringsarbete till någon annan plattform går att installera i den sidans system.
Men det går väl då med Code Igniter - får väl kolla lite vidare på det. Alternativet är väl att bygga in det själv i sin egna kod, men då tjänar man inte lika mycket arbete som när man får ta del av andras arbete.
Skrivet av Pelle, onsdag 6 september 2006, 15:50