Zanim przejdziemy do utworzenia pierwszego kontrolera, zapoznaj się ze strukturą katalogów i elementami jakie posiada Kohana.

Całość dzieli się na 3 katalogi:

• system – tu znajduje się „serce” naszego frameworka, w tym główny rdzeń (core) oraz inne elementy, których krótki opis znajduje się poniżej;
• modules – zawiera kod (biblioteki, modele, widoki itp.), który jest na tyle uniwersalny, że może być wykorzystywany w innych projektach (np. obsługa użytkowników);
• application – ten katalog będzie nas interesował najbardziej. To w nim przechowywane są wszystkie pliki związane z naszą aplikacją.

Skrypty uruchamiane są poprzez plik index.php. To on ładuje podstawowe klasy Kohany, które później decydują który z elementów naszej aplikacji ma być odpalony.

Elementy Kohany

Jak zapewne zauważyłeś, we wszystkich 3 katalogach jest podobna struktura podkatalogów:

• classes – folder ten zawiera kontrolery, modele oraz klasy pomocnicze, dzięki którym nasza aplikacja działa tak jak tego sobie życzymy;
• config – jak sama nazwa wskazuje zawiera pliki z konfiguracją aplikacji, bibliotek czy też poszczególnych modułów;
• i18n (skrót od internationalization) – katalog ten zawiera pliki językowe z komunikatami i tekstami, które chcemy aby były przetłumaczone na naszej stronie. Poza zdefiniowanymi standardowo można utworzyć własne. Pliki językowe zawierają w sobie tablice, gdzie kluczem jest wyrażenie do przetłumaczenia, a wartością przetłumaczony tekst. Pliki językowe nie są poddawane nadpisywaniu (patrz kaskadowy system plików), lecz są ze sobą łączone w kolejności od najstarszego do najnowszego wpisu (system->modules->application);
• messages – wiadomości w przeciwieństwie do plików językowych nie są tłumaczone, za to pozwalają na ujednolicenie komunikatów w aplikacji (np. dla walidacji formularzy). Podobnie jak pliki językowe komunikaty są łączone;
• vendor – znalazłeś w internecie jakąś bibliotekę, której chciałbyś użyć w Kohanie? To miejsce jest właśnie dla niej. W tym katalogu przechowywane są klasy zewnętrznych bibliotek, do zaadoptowania by współpracowały z naszym frameworkiem;
• views – widoki były opisane w poprzednim rozdziale, więc nie ma sensu się nad nimi rozwodzić. W następnych wpisach zajmę się dokładniej ich tworzeniem i zastosowaniem w aplikacji.

Kaskadowy system plików

Charakterystyczną rzeczą, wartą uwagi w Kohanie jest kaskadowy system plików. Takie rozwiązanie pozwala na nadpisanie plików bez konieczności ich modyfikacji czy usuwania. Jeśli chcemy otworzyć jakiś plik będzie on przeszukiwany w katalogach w kolejności application -> modules -> system. Jeśli plik nie znajdzie się w żadnym z nich, to zostanie wyświetlony komunikat błędu (w przypadku braku kontrolera błąd 404). Podkatalogi w modules są przeglądane w kolejności ich dodania w pliku konfiguracyjnym bootstrap.php następnym artykule). Spójrz na poniższy rysunek.

W katalogu system/views mamy widok error.php,który posiada stronę błędu. Ale my chcemy mieć swoją stronę błędu z własnym wyglądem. Dlatego też tworzymy plik o tej samej nazwie w katalogu naszej aplikacji (application/views). Dzięki temu Kohana otrzymując polecenie odnalezienia widoku, szuka go najpierw w naszym katalogu. W tym przypadku znalazł go od razu, więc pomija pozostałe lokalizacje. Dla pliku classes/database.php szuka w application. Ponieważ tam go nie ma, kontynuuje w katalogu modules. Moduł common również nie posiada szukanego pliku, kohana przeszukuje kolejny moduł database gdzie jest nasz plik, kończąc tym samym dalsze poszukiwania (katalog system nie będzie już brany pod uwagę).

Rozwiązanie to jest bardzo użyteczne w przypadku konfiguracji. W zasadzie nie powinieneś nic zmieniać w katalogu system, ponieważ w przypadku aktualizacji Kohany stracisz wszystkie zmiany, a po pewnym czasie raczej nie będziesz pamiętać co i gdzie zmieniłeś. Zatem jeśli brakuje jakiegoś pliku, który istnieje w katalogu system/config, bądź w którymś z modułów, a który chcesz zmodyfikować, to skopiuj go do application/config i tam dopiero modyfikuj.

Standardy nazewnictwa

Aby Kohana wiedziała gdzie znaleźć elementy naszej aplikacji musimy zachować pewne standardy.

• Klasy (classes):
  • wszystkie klasy znajdują się w podkatalogu classes;
  • nazwa pliku musi być zapisana małymi literami, np. artykuly.php;
  • nazwa klasy musi pokrywać się z nazwą pliku, wyjątkiem są klasy, które w swojej nazwie posiadają podkreślenia, np. Controller_Home, wtedy dla członów poprzedzających ostatni należy utworzyć strukturę katalogów zamieniając podkreślenie „_” na slashe „/”. W podanym przypadku będzie to controller/home.php;
  • wielkość liter w nazwie klasy nie ma znaczenia.

  Przykładowe nazwy klas i ścieżki dla nich:
  Game – classes/game.php
Model_Users – classes/model/users.php
Moja_Klasa – classes/moja/klasa.php
Klasa_Nazwa_Dluzsza_Niz_Zwykle – classes/klasa/nazwa/dluzsza/niz/zwykle.php

• Widoki (views):
  • w przypadku widoków nazwy plików mogą być dowolne, wielkość liter nie ma znaczenia, byleby przy wywołaniu widoku ją zachować. Musi być jedynie zakończona rozszerzeniem .php;
  • Dopuszczalne (a nawet zalecane dla większego porządku) jest umieszczanie plików w podkatalogach.

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.