Wprowadzenie

Kohana jest jednym z wielu frameworków stworzonych w języku PHP.

Jej korzenie sięgają innego frameworka o nazwie Code Igniter (CI). Ponieważ deweloperzy CI zapowiedzieli, że ich produkt nie będzie wspierał PHP w wersji 5, grupa programistów korzystających dotychczas z CI postanowiła utworzyć nowy projekt, idący z duchem czasu i wspierający coraz bardziej rozwijającą się obiektowość dla PHP. Tak powstała Kohana, początkowo bardzo podobna do CI, lecz w tej chwili utożsamia się tylko z jego ogólnymi ideami działania, ponieważ sam projekt jest w pełni samodzielny i jego rozwój biegnie własnym torem.

Co cechuje Kohanę?

• Oparta o wzorzec MVC (o tym za chwilę);
• Napisana w PHP 5, także jeśli jesteś osobą znającą ten język, to być może Kohana przypadnie ci do gustu;
• W porównaniu z niektórymi kolosami typu Symfony, Mojavi itp. jest dość szybka;
• Poza samym wzorcem MVC i ogólnymi zasadami konstrukcji Kohana daje dość ogromną swobodę w tworzeniu aplikacji.

Czym jest MVC?

Jak możemy wyczytać w Wikipedii, MVC jest wzorcem projektowym dzielącym aplikację na 3 części:

• Model – jego zadaniem są operacje na danych. Najczęściej modele korzystają z baz danych, ale równie dobrze mogą odwoływać się do dokumentów będących na dysku czy też innych stron;
• Widok – w wielu serwisach rolę widoku określa się jako oddzielenie kodu PHP od HTML, co jest oczywiście nieprawdą. Jednym słowem widok tworzy to, co użytkownik otrzymuje na wyjściu, w zależności od założeń działania aplikacji. Może to być reprezentacja danych pobranych z modelu – w formie tabeli – połączonych z interfejsem zapisanym jako kod HTML, czy też inny rodzaj pliku (PDF, XML);
• Kontroler –  jest łącznikiem między modelem i widokiem. Jego zadaniem jest odbieranie żądań użytkownika, wysyłanie zapytania do modelu o konkretne dane, a po ich otrzymaniu odesłanie ich do widoku. Jednym słowem kontroluje on przebieg aplikacji.

Co nam daje taki podział?

Przede wszystkim model stanowi pewnego rodzaju czarną skrzynkę, o której wiemy tylko to, co z nią zrobić, żeby zwróciła interesujące nas dane. A to, w jaki sposób to zrobi i z jakiego źródła danych skorzysta (plik, baza MySQL, PostgreSQL, XML itp.) nie będzie już nas interesować. Jego zadaniem będą tylko operacje na danych (odczytywanie, zapisywanie itp.) i nic poza tym.

Dajmy na to, że mamy dostawcę, którego prosimy o dostarczenie danego produktu (np. soku). Nie interesuje nas, czy weźmie go z hurtowni A czy z hurtowni B. Ważne, że otrzymamy to o co prosimy. Może być taka sytuacja, że dotychczas dostawca brał towar z hurtowni A, która z nieznanych przyczyn ogłosiła upadłość. Żeby wywiązać się z umowy, dostawca szuka innego źródła i znajduje hurtownię B, skąd dostarczy nam towar. My jako kupujący nie dostrzegamy różnicy, bo wszystko, o co poprosiliśmy zostało dostarczone, a kwestia „skąd” to już zmartwienie dostawcy.

Podobnie jest z modelem. Załóżmy, że do tej pory model pobierał dane z bazy MySQL, ale cały serwis musi być przeniesiony na PostgreSQL. Z zewnątrz nic się nie zmienia, nadal jest ten sam model i te same metody odwołujące się do niego, zmianie ulega tylko wnętrze modelu. Dzięki temu oszczędzamy wiele czasu i nerwów, bo nie musimy zmieniać wpisów odwołujących się, być może w kilkudziesięciu (czy nawet więcej) plikach do naszego modelu.

Podobnie sprawa może mieć się w przypadku widoku. Wyobraźmy sobie sytuację, że wszystkie dane pobrane z modelu były wyświetlane w formacie HTML, ale stworzyliśmy sobie program, który odwołuje się do naszej strony. Operuje on zaś na plikach XML. Co robimy? Przepisujemy naszą stronę na nowo? Nic podobnego – zmieniamy tylko widok tak, aby wyświetlał to co chcemy, czyli w tym przypadku XML. Pozostała część aplikacji (kontroler i modele) nie ulega zmianie.

Choć nic nie stoi na przeszkodzie, żeby tak dostosować kontroler, aby w zależności od tego czy żądanie wywodzi się od przeglądarki internetowej czy też z naszego programu, wybierał odpowiedni widok i wyświetlał go.

Jak widać rozwiązanie takie pozwala na zaoszczędzenie mnóstwa czasu. Ponadto możemy podzielić prace nad projektem na kilka osób, gdzie jedna np. może tworzyć model, inna widok, a jeszcze inna scalać oba te elementy tworząc kontroler.

To tyle tytułem wstępu. Kolejne części opisują budowę i zasadę tworzenia aplikacji z wykorzystaniem Kohany. A to wszystko na przykładzie tworzenia prostego blogu internetowego.