Michał Matyas

Ze względu na to, że w najbliższym czasie będę uczył pewną osobę obsługi frameworka Kohana PHP, postanowiłem rozpocząć serię wpisów na ten temat. Dzięki temu w przyszłości nie będę musiał się powtarzać. Wpis ten dotyczy Kohany w wersji 2.3.4 i ogólnie serii 2.x, seria 3.x różni się w wielu miejscach, ale jest jeszcze zbyt niestabilna, żeby z niej powszechnie korzystać.

Dla początkujących, a już w ogóle zaczynających pracę z frameworkami, Kohana jest świetnym wyborem. Wygodny, obiektowy i nowoczesny zbiór ułatwień, na dodatek nie odstający za bardzo od tego do czego człowiek jest już przyzwyczajony. Mimo to dokumentacja ma tą poważną wadę, że opisuje jak działają poszczególne elementy, a nie pomaga zacząć pracy. Pewnym rozwiązaniem miało być umieszczenie serii tutoriali na oficjalnej stronie, ale są one niestety pełne dziur i nie do końca ułatwiają, a czasami nawet gmatwają rozpoczęcie pracy z Kohaną. Czas to zmienić, przynajmniej dla polskich czytelników ;)

Zacznijmy może od wprowadzenia do frameworka, jego budowy i rozłożenia elementów.

Struktura katalogów

Przede wszystkim pierwsze co rzuca się w oczy to podział na trzy podstawowe ‘działy’ - application, modules oraz system. Zacznę od końca - w system przechowywane jest ‘serce’ Kohany - core, biblioteki, helpery, słowem wszystko to, czego będziemy używać przy pisaniu aplikacji. Application zawiera zatem nasze pliki, czyli wszystko to co sami tworzymy lub modyfikujemy. Modules z kolei służy do umieszczania w nim kodu, który często stosujemy w różnych projektach dzięki czemu możemy opakować go właśnie w moduł. Przykładami takich modułów są np. Auth służacy do prostej obsługi użytkowników czy Payment do obsługi serwisów płatności.

W tym momencie musimy się zatrzymać i zastanowić. Skoro posiadamy trzy różne katalogi, w którym są identyczne zestawy podkatalogów (o których za chwilę) to skąd framework ma wiedzieć, którego pliku użyć jeśli wystąpi kolizja nazw?

Otóż głównym założeniem Kohany jest możliwość ‘nadpisania’ dowolnego elementu frameworka bez zamiany plików w system. Dzięki takiemu rozwiązaniu katalog ten możemy trzymać dla wielu projektów w niezmienionej formie, a w razie konieczności modyfikacji np. biblioteki Image czy któregoś z helperów możemy po prostu utworzyć plik o identycznej nazwie w application, a framework sam z niego skorzysta. O szczegółach nadpisywania plików będę mówił później w szerszej formie, chwilowo uznajmy, że tak jest.

Mamy więc trzy katalogi, z których application i system zawierają z grubsza te same podkatalogi. W modules posiadamy podkatalogi z modułami, a dopiero te podkatalogi zawierają taką samą strukturę jak dwa poprzednio wymienione. Przeanalizujmy ją więc.

• cache - katalog odpowiedzialny za cache aplikacji. Nie musimy z niego korzystać jeśli nic nie cache’ujemy, ale w innym wypadku musi mieć nadane prawa dostępu i zapisu
• config - konfiguracja skryptu. Łatwo się domyślić co się tutaj znajduje. O konfiguracji będę mówił dokładniej za chwilę.
• controllers - kontrolery aplikacji. O tym jak działa architektura MVC powiemy sobie również za chwilę w formie przypomnienia.
• core - w przypadku katalogu system/, tutaj znajduje się silnik frameworka. To jedyny katalog, którego zawartości nie możemy nadpisywać z poziomu plików aplikacji, co jest dość logiczne.
• fonts - czcionki wykorzystywane przez bibliotekę Captcha
• helpers - helpery aplikacji. Czym są i jak działają w Kohanie powiemy sobie później
• hooks - ciekawa zbieżność nazw, gdyż są to właśnie hacki wszelkiego rodzaju - wszystko to, czego nie dało się załatwić elegancko. Osobiście nie lubię tego katalogu i staram się go unikać, ale czasami jest konieczny, np. przy tworzeniu własnych stron błędów 403. Na temat ‘haków’, sposobu ich działania i możliwości jakie dają napiszę w przyszłości osobny wpis.
• i18n - pliki z tłumaczeniami wykorzystywane przez Kohana::lang(). Więcej na ten temat znajduje się w dokumentacji, ale powiem również i o tym. Innym razem.
• libraries - biblioteki frameworka oraz nasze własne. Jeśli w core znajdowało się serce frameworka, to tutaj znajdują się jego organy wewnętrzne ;)
• logs - jak sama nazwa wskazuje, logi. Ten katalog również wymaga praw zapisu.
• models - modele aplikacji
• upload - domyślnie jest to katalog służący do zapisu plików pobranych z helpera Upload. Można go zmienić w konfiguracji (patrz niżej)
• vendor - zawiera zewnętrzne skrypty zintegrowane z Kohaną przez helpery lub biblioteki. Domyślnie zawiera SwiftMailera, ale jest to też miejsce na np. Smarty
• views - ostatni katalog, widoki aplikacji

MVC - Model, View, Controller

Obiecałem przed chwilą, że opiszę na czym polega architektura MVC. Czytający, którzy korzystali już z frameworków na pewno wiedzą co to jest i mogą spokojnie przejść do następnego akapitu, gdyż tłumaczy on łopatologiczne podstawy takiego podziału. Pozostałych zapraszam do lektury.

Podczas pisania własnego projektu na pewno zetknęliście się z sytuacją gdy trzeba było umieścić te same elementy stron w wielu miejscach. Jestem pewien, że rozpoczynaliście naukę od właśnie include(“header.php”) chociażby, czy innych przerażających konstrukcji. Być może po jakimś czasie zainteresowały was systemy szablonów jako sposób na eleganckie oddzielenie warstwy prezentacji od kodu, a tym samym ułatwienie życia przy przebudowie designu.

W najprostszej formie, której uczą różne książki i internetowe kursy, każda strona była osobnym plikiem, w którym include’owane były klasy, funkcje i inne tego typu śmieci, a następnie wykorzystywany był system szablonów, lub - o zgrozo! - bezpośrednio HTML połączony z PHP. Czasami gdy include’owane były te same pliki wciąż i wciąż, tworzony był jeden plik, index.php, który się tym zajmował i dołączał właściwe pliki.

Architektura MVC powstała jako rozwinięcie tego, powiedzmy sobie szczerze dość prymitywnego sposobu tworzenia witryn. Mamy tzw. FVC - Front View Controller, czyli skrypt ładujący odpowiedni kontroler w zależności od adresu, a także kontrolery, modele i widoki.

Kontroler jest czymś w rodzaju spoiwa. Prosi o dane modele i przekazuje je do widoków. Operuje on jedynie na adresie czy requestach (np. POST, GET), sam nie ma bezpośredniego kontaktu np. z bazą danych. Tym, czyli całą logiką serwisu zajmuje się model. Otrzymuje on prośbę o określone dane i je przekazuje. Dostaje rozkaz modyfikacji danych - zmienia je. Modelu nie obchodzi jaki jest właśnie adres strony ani kto go prosi o informacje, on je jedynie przekazuje. Na tej samej zasadzie kontroler nie interesuje się tym skąd brane są dane - z bazy danych? Z pliku? Z powietrza? Nieważne - grunt, że są. Pozostaje jeszcze trzecia część tego triumwiratu - widok. Widoku nie interesuje ani to jakie dane otrzymuje, ani to skąd są i co się w ogóle dzieje dookoła. On chce po prostu dostać to co ma dostać, wyświetlić to użytkownikowi i mieć spokój.

Bystrzejsi na pewno dostrzegają już zalety tego rozwiązania. Przede wszystkim o ile zachowamy zgodność ABI¹, nie ma znaczenia to skąd pobierane są dane ani to co je wyświetla. W teorii możemy dzięki temu zmienić np. źródło danych z bazy MySQL na pliki tekstowe (to tylko przykład, bez głupich pomysłów) bez modyfikacji logiki działania strony ani jej wyglądu albo w drugą stronę - przemodelować całą stronę od zera nie dotykając przy tym modelu czy kontrolera (albo modyfikując kontroler jeśli zmienimy przy tym nawigację - blaski i cienie, co?)

Kohana PHP jest frameworkiem bardzo swobodnym. Dzięki temu nie musimy w ogóle korzystać z modeli, a całą logikę trzymać w kontrolerze. Nie jest to zbyt fortunne rozwiązanie, osobiście staram się go unikać (chyba, że deadline przyciśnie, a projekt jest malutki, dobrze, przyznaję się), ale dla osób dopiero zaczynających naukę może to być prostsze. Nie polecam, tylko informuję.

Konfiguracja aplikacji

Najważniejszym plikiem konfiguracyjnym Kohany jest application/config/config.php . Zawiera on najważniejszą, podstawową konfigurację skryptu. Co z resztą? Otóż domyślnie reszta jest zapisana w system/config . Aby edytować np. ustawienia bazy danych czy routingu, należy przekopiować odpowiednie pliki z tego katalogu do application/config . Nie będę wymieniał tutaj wszystkich plików konfiguracyjnych, gdyż większość zawiera komentarze opisujące ich zawartość. Skupmy się na najważniejszych, czyli:

• database.php - łatwo się domyślić, konfiguracja bazy danych. Drugi najczęściej używany plik w całym katalogu zaraz po config.php ;)
• email.php - konfiguracja do helpera Email, pozwala na ustawienie ‘sterownika’ obsługi maili stosowanego przez SwiftMailera
• locale.php - określa domyślny język aplikacji oraz strefę czasową
• routes.php - trzeci najczęściej używany plik - określa działanie Routingu. Na ten temat prawdopodobnie poświęcę osobny wpis lub skupię się w innej części tej serii ;)
• upload.php - określa konfigurację helpera Upload, najważniejsza jest tutaj ścieżka zapisu plików

Najczęściej stosowane pliki to jak już wspominałem - config.php, database.php oraz routes.php. Polecam od razu skopiować je do application/config, gdyż to je będziemy najczęściej modyfikować.

Cóż, zanim zacznę opisywać dokładniej wszystkie niuanse Kohany, może jeszcze:

Pierwszy start

Początkującym wiele problemów sprawia przystosowanie Kohany do początkowej pracy. Przede wszystkim zaraz po rozpakowaniu nie jest ona gotowa do użycia o czym wiele osób nie wie i przez to szybko się zniechęca. Spróbujmy więc razem:

Przede wszystkim zacznijmy od pobrania i rozpakowania skryptu. Dla potrzeb wpisu uznajmy, że został rozpakowany w ~/public_html/KohanaPHP/. Przede wszystkim musimy ustawić najpierw mod_rewrite (zakładam, że na serwerze jest aktywny i działa, jeśli nie - najwyższy czas zastanowić się nad nowym serwerem testowym / produkcyjnym). Zmieńmy nazwę example.htaccess na .htaccess.

Są w Kohanie dwa miejsca, gdzie należy zmienić katalog, żeby mod_rewrite działało poprawnie - właśnie .htaccess oraz application/config/config.php. Edytujmy pierwszy i zmieńmy RewriteBase /kohana/ na /KohanaPHP/ (jeśli skrypt znajduje się w głównym katalogu serwera, należy wstawić tam /). Następnie wejdźmy do drugiego i zmieńmy wartość zmiennej $config[‘site_domain’] na taką jak przed momentem RewriteBase. Ostatnia ważna rzecz - w pliku config.php należy ustawić $config[‘index_page’] na ”.

W tym momencie powinniśmy mieć już działającą instalację Kohany na serwerze. Po wejściu na adres adres-serwera/KohanaPHP/ powinniśmy otrzymać informację o prawidłowej instalacji skryptu. Tym samym udało nam się postawić pierwszy kroczek. Ale to dopiero początek długiej drogi ;)

Dotknąłem w tym wpisie tylko części materiału, który chciałbym opisać. Gdybym się w tym momencie nie zatrzymał, wpis nabrałby rozmiarów książki ;) Trochę wyszło chaotycznie, ale nie mógłbym opisać np. pierwszego startu nie ruszając przy tym plików konfiguracyjnych, a nie chcę zaczynać opisu tworzenia aplikacji na tym poziomie. Wszystko w swoim wpisie :)