Jakiś czas temu pisałem o KISS MVC – bardzo fajnym i prościutkim frameworku realizującym wzorzec architektoniczny Model View Controller w języku PHP. Na początek doskonale się nadawał, do jakichś prostych zastosowań, jednak z czasem okazywał się być zdecydowanie niewystarczający. Jakby naturalnym krokiem był wybór innego, bardziej złożonego i lepiej zaopatrzonego w najróżniejsze funkcjonalności frameworka. Wybór padł na polską Kohanę. Powodów było generalnie kilka, lecz najważniejszym był duży zestaw “upraszczaczy życia”, które wykonują naprawdę znaczną część roboty przy obsłudze sesji, bazy danych, tworzeniu i walidacji formularzy, czy w końcu dodatkowych modułów (w rezultacie nie użyłem żadnego poza formo, ale o tym niżej).

W teorii miało to wyglądać na całkiem przyzwoite i proste wykonanie projektu, jednak okazało się nietrywialne. Pierwszy problem jaki napotkałem, to problem z bazą danych, który opisałem tutaj. Drobny problem był także z routingiem do panelu administracyjnego, dodatkowo formo – moduł do łatwego i szybkiego tworzenia formularzy i do ich walidacji – okazał się nietrywialny w szczególnych zastosowaniach, oraz – najgorsze – problem z modułem multi_lang do internacjonalizacji. Cóż – wygląda to cokolwiek odstraszająco i niekonsekwentnie – biorąc pod uwagę moje ostatnie zachwalania w kierunku Kohany. Jednak projekt w rezultacie został ukończony i nawet jego funkcjonalność jest adekwatna w stosunku do założeń, ale… własne trochę na siłę wprowadzane helpery do ruszenia tego serwisu do działania jakoś nie przekonują mnie do końca i są nieestetyczne. Ale to jakby po kolei. Jedziemy od początku:

Panel administracyjny

W Kiss MVC panel administracyjny dało się dodać w sposób jak najbardziej bezproblemowy. Wystarczył folder admin do względnie prostego usadowienia tam panelu. Bez jakichś większych niuansów. W Kohanie dodanie folderu admin w controllers nie rozwiązuje problemów. Żeby jakoś zaczęło to działać możemy najprościej dodać nowy wpis do routingu Kohany w pliku /application/config/routes.php. Wygląda on mniej więcej tak:

$config['admin'] = 'admin/main/index';

Należy brać też pod uwagę ograniczenia nazewnicze dla swoich plików. Na przykład plik kontrolera o nazwie: main_login_setup.php nie będzie poprawnie przez Kohanę obsługiwany (znaczy go nie znajdzie). Kolejny problem jest taki, że jeśli napiszemy sobie nowy kontroler do panelu administracyjnego z myślą o tym by dziedziczył po innym kontrolerze z panelu administracyjnego, to niestety tak się nie da. Jest to jakby ograniczenie wynikające z samej budowy Kohany i żeby problem ten rozwiązać trzeba byłoby wprowadzić drobne poprawki w samym kodzie Kohany (Kohana przeszukuje foldery kontrolerów NIE-rekursywnie)

Formo

W Kohanie standardowo dostępna jest prosta biblioteka do walidacji i tworzenia formularzy Validation i Forge, których jednak nie używałem przy tym projekcie. Powód był nawet konkretny, tylko teraz nie mam pomysłu co to mogło być :) W każdym bądź razie zdecydowałem się na moduł Formo, którego dużą zaletą jest dość duża dostosowywalność do potrzeb nawet na etapie samego wykorzystania oraz zintegrowany moduł walidacji przez javascript (do którego nawet nie trzeba się dotykać by ładnie działał:)). Jest też jednak kilka minusów tego rozwiązania. Pierwszym problemem, którego w sumie nie rozwiązałem na dobrą sprawę jest trochę dziwna kolejność działania.

Przykład: formularz musi być budowany zawsze przed walidacją danych. Oznacza to dla formularza skonfigurowanego w ten sposób, że sam na siebie wskazuje, że w momencie kliknięcia przez użytkownika w przycisk Submit strona się przeładuje, utworzy się formularz formo i dopiero po utworzeniu nastąpi walidacja po stronie serwera i ewentualny zapis zmian. W rezultacie zmiany wprowadzone na formularzu przez użytkownika nie są widoczne po ich zapisie, mimo iż w bazie zostały poprawnie zapisane. Wynika to trochę z podejścia zapewne – możemy bowiem decydować się na ładowanie innej strony po zapisie zmian i wtedy nie ma problemu. Jeśli zaś koniecznie chcemy pokazywać ten sam formularz po zapisie zmian to najłatwiej jest przeładowywać stronkę. Lub formularz uzupełniać danymi dodatkowo po zapisie.

Inna sprawa z Formo to słaba dokumentacja. Z dostępnej dokumentacji naprawdę trudno wywnioskować nietrywialne rzeczy. Pozostają oczywiście eksperymenty lub wertowanie netu w poszukiwaniu dość wyspecjalizowanych informacji. Cóż, nie będę się dalej na ten temat rozpisywał; podam tylko kilka przydatnych mocno rzeczy w codziennej pracy z tym rozwiązaniem:

Zmiana tytułu pola (Changing field title)

$form = Formo::factory()->add('textarea', 'FIELD_TITLE',
    array('label' => 'Tytuł pola', 
        'class' => 'textarea', 
        'required' => false 
    )
);

Wgrywanie plików (Uploading multiple files)

$form = $form->add('file', '_myFile2',
    'allowed_types=png|jpg|gif, max_size=1000K, upload_path=content/upload/, label=Field title, required=0');

Ustawianie wartości na stworzonym formularzu (Setting form values)

$form = $form->set('title', 'value', 'VALUE');

Odnośnie Formo jeszcze jedna mała uwaga: Formo używa co prawda phpowej globalnej tablicy $_POST oraz $_FILES, jednak zdecydowanie zalecanym jest by nie grzebać w tej części wykorzystywanej przez Formo. Oczywiście nic nie stoi na przeszkodzie by poza Formo używać części swoich formularzy, które zostały stworzone nie przez Formo.

Wielojęzyczność

I tak zbliżamy się do zasadniczego problemu na jaki napotkałem, czyli rozszerzeniu strony tworzonej w Kohanie na wiele języków. Kohana zawiera wiele rzeczy, które są (a raczej mogą być) niesamowicie przydane przy wielojęzyczności. Jest taką rzeczą np. wbudowany i18n (Internationalization), który znacząco (phi – niesamowicie, ale tylko w teorii) pomaga w organizacji treści dla wielu języków i to do tego w bardzo prosty i przystępny sposób. Jednak z dziwnego powodu zmiana języka w Kohanie była niemożliwa.

Próba wykorzystania modułu multi_lang też raczej nie pomogła nawet przy sprzyjającej konfiguracji wobec czego musiałem napisać własny prościutki helper do pobierania ciągów odpowiednich dla konkretnego języka oraz do prostego zmieniania języka (przez $_CACHE), co dało mi działające bez zastrzeżeń rozwiązanie :)

Co do samego tłumaczenia dostępnego w Kohanie to mój problem najprawdopodobniej wynikał z tego, że na serwerze PHP hostowanym na Windowsie (zarówno mój localhost jak i Webio są tej kategorii) może występować problem ze zmianą kultury i języka przez standardową funkcję php do tego celu.

Dokumentacja

Ostatnim punktem, który chciałem poruszyć odnośnie Kohany to dokumentacja. Oceniam ją na WZGLĘDNIE DOBRĄ. Jest trochę materiałów pomocnych w zrozumieniu idei, jest też dużo tutoriali (w tym też mój ulubiony Kohana Starter), jednak na późniejszym etapie, gdy ma się już podstawy, trudno znaleźć coś co się przyda i pomoże w konkretnym problemie. Poza tym większość dokumentacji dla Kohany cierpi na przestarzałość. Dużo materiałów jest dobra dla wersji 2.0, 2.1, 2.2, ale dla 2.4 już mało co jest dobre. Ponadto mało materiałów zawiera informację o tym, pod którą wersję Kohany był pisany artykuł.

Ale i tak pod względem dokumentacji jest lepiej niż w najnowszym SharePoincie :)

Podsumowanie

Troszkę się rozpisałem, ale mam nadzieję, że moje przemyślenia i spostrzeżenia przydadzą się w Waszych projektach i Waszych stronach. Nie ma tu co prawda wielu gotowych rozwiązań i bardziej konkretnych odpowiedzi na zaprezentowane problemy, jednak może przydać się to osobom, które są właśnie na etapie planowania całego projektu. Żeby na przykład ustrzec przed zabieraniem się za wielojęzyczność strony na samym końcu ;) Lepiej się z nią wcześniej pobawić, bo może dzięki temu unikniecie przykrych niespodzianek projektowych.