Długo się broniłam przed przejściem z kohana v2 na v3. Parę rzeczy w v2 napisałam i polubiłam ten framework. Jednak jak wszystko ma on swoje ograniczenia i słabe strony. Ostatnio zaczęłam przyglądać się wersji trzeciej, bo klient chciał koniecznie aplikację napisaną w tej wersji frameworka. Do kontraktu nie doszło, a moje przyglądanie się zaowocowało pewnymi wnioskami. Otóż zauważyłam, ze pewne rzeczy w v3 są jednak lepiej zorganizowane niż w v2. Mechanizm routingu bardzo mi się spodobał. Metody before i after, które w v2 musiałam sobie sama zdefiniować i obsłużyć. Jeszcze nie wszystko jest dla mnie jasne i proste i pewnie v3 ma jeszcze więcej zalet, które wkrótce dostrzegę, ale decyzja już zapadła. Następna aplikacje robię w kohana v3. Póki co będę się posiłkować tutorialem na blogu Patryka Wójcika. Szkoda, że dawno nie było tam nowych wpisów. Póki co to co tam jest będzie musiało wystarczyć. Przestudiowałam juz część oficjalnej dokumentacji, niestety niezbyt kompletnej. Przede mną jeszcze zapoznanie się z nieoficjalna dokumentacją do której zawsze odsyłają koledzy z polskiego forum kohana ilekroć pyta się o rzeczy fundamentalne.
EDIT
Po sugestii jednego z użytkowników postanowiłam dodać jeszcze link do niezłego anglojęzycznego tutoriala do Kohana 3, żeby nie zaginął w czeluściach komentarzy.
Dla mnie wystarczającym argumentem jest wsparcie (K2 już chyba nie jest wspierana). Jeśli miałbym zaczynać jakiś projekt to biorę najnowszą wersję, poprawiam (zawsze jest coś do naprawienia:), dopiero pisze stronę. Trzymanie się starszych wersji wg. mnie nie ma sensu, chyba że dysponuje się “swoją” modyfikacją z dużą ilością poprawek, czy usprawnień.
Kohana v2 wspierana pewnie już nie jest, ale jest stabilna i ma spore możliwości. Kohana v3 to od wersji do wersji ciągle jeszcze rewolucja.
Dobra decyzja. Ja się broniłem i broniłem, aż w końcu poległem ;)
Generalnie, kerkness.ca + analiza kodu jeśli potrzeba, to w zupełności wystarcza. Kod prosty do analizy jak coś nie idzie.
Ja osobiście siedzę na 3.0.9, trochę zmodyfikowana. Nowymi wersjami nawet się na razie nie interesuję – za dużo zmian i moim zdaniem trochę śmieszne podejście deweloperów do całego projektu.
Jakby coś, służę radą.
Czemu nie masz powiadamiania emailem o nowych komentarzach zainstalowanego?
Będę pamiętać do kogo uderzać jak by co.
A co do powiadamiania, to byłam pewna, że jest :)
kohana jest dość przyjemna, ja dużo czasu potrzebowałem żeby zrozumiec o co chodzi i długo sie broniłem przed wszystkimi frameworkami – moze dlatego ze ich nie rozumialem. Ciesze sie ze zacząłem własnie od kohany choć mam z nią czasami problem i rzeczywiście dokumentacja jest skromna i bez forum bym nie ujechał
Ja się przed frameworkami nie broniłam. Zrobiłam kilka projektów “z palca”, poznałam problematykę i błogosławię framework za to, że odwala za mnie czarną robotę (routing, inkludowanie, architektura MVC itp). Teraz tylko muszę się przestawić na trochę inny mechanizm działania frameworka, bo jest spora różnica między wersją 2 a wersją 3.
KO3 jest dla mnie pierwszym frameworkiem jaki wybrałem (. Jest mało problematyczny, jeżeli się zrozumie podstawy :)
Jeśli chodzi o tutorial to o wiele lepszy jest ten z linkowany z nieoficjalnej dokumentacji kohany(http://www.dealtaker.com/blog/2009/11/20/kohana-php-3-0-ko3-tutorial-part-1/). Przynajmniej mi o bardziej przypadł do gustu.
a to już nie wiem jak było z ko2, ja przez jeden dzień miałem do czynienia do CI ale Ko3 mnie bardziej przekonała.
Na Kohana 2.3.4 sporo kodu napisałem; zapoznawanie się z Kohana 3 uznałem za bezcelowe – co tydzień nowa wersja? (mniejsza bo mniejsza, ale zawsze to częste upgrade’y) i niestety brak SOLIDNEJ dokumentacji (dla Kohana 3). Po wstępnych oględzinach coraz większe szanse, że przestawię się kompletnie, z Kohana 2 na Yii.
No tak. W Kv3 te różnice między kolejnymi wersjami i beznadziejna dokumentacja są rzeczywiście denerwujące. Dłubię od kilku dni realizując pewien projekt i dochodzę do wniosku, że wiele rzeczy w Kv3 jest o wiele lepiej dopracowanych niż w w Kv2.
Denerwuje mnie tylko, i to bardzo, struktura katalogów i mechanizm kaskadowości (to znaczy nie sam mechanizm, ale sposób w jaki został zrealizowany), gdyż niestety w związku z brakiem dokumentacji trzeba dużo po kodzie grzebać i dociekać.
Za to moje ulubione moduły (ot choćby Formo czy Query_Builder) pracują w Kv3 lepiej niż w Kv2. Póki co więcej plusów niż minusów.
Póki co nie planuje przerzucenia się na zupełnie
@SuchyMTW. Masz rację to niezły tutorial. Też do niego zaglądałam.
Struktura katalogów i mechanizm kaskadowości to jedna z najlepszych rzeczy w KO :) Z początku też byłem lekko “zagubiony”, ale podstawą jest dobre środowisko programistyczne, dzięki któremu możemy jednym kliknięciem w kodzie przenieść się do pliku w zupełnie innym katalogu. Nie wiem na czym Ty pracujesz, ale dobre IDE to podstawa przy pracy w KO.
Ba. Ja ciągle korzystam z Eclipse for PHP Developers i mimo pewnych wad trudno mi się z tym edytorem rozstać. Myślałam nawet o przejściu na nowszą wersję Eclipse, ale jakoś się n ie mogę nawet do tego zebrać.
Mi osobiście brak dokumentacji nie sprawia trudności na większość pytań znajduje odpowiedz przeglądając pliku KO3. A ide to netbeans w najnowszej odsłonie.
Ja przez parę lat też pracowałem na Eclipse, ale ponad rok temu przeszedłem na NetBeans i to jest właśnie to :) Polecam!
No może się skuszę?
Spróbuj :) Naprawdę można się zakochać w tym programie ;)
@skowron-line – A zauważyłeś jak siódemeczka przyspieszyła? ;)
@.c41x – Nie do końca się mogę zgodzić. Oni po prostu robią za dużo bezsensownych zmian (vide gałąź 3.0.x i 3.1.x).
Też eclipse używałem, po przejściu na NetBeans-a odczułem ulgę – wszystko działa po prostu lepiej: refaktoring, debugger, podpowiadanie kodu php, html, javascript, nawet ostatnio mysql, podkreślanie błędów i ostrzeżeń i to wszystko “w pudełku”. Konfiguracja Eclipse to koszmar, lub ja nie jestem wystarczająco pro żeby to ogarnąć :) Okazja do wytestowania NB jest dobra, bo kilka tygodni temu wyszła wersja 7.0.
Dokumentacja nie potrzebna !!
Zamiast pisać dla klienta zamówienie, to szukasz po sieci jak coś napisać lub przeskoczyć, naprawdę piękne rozwiązanie..
Dokumentacja to podstawa !!
Ja o tym wiem i wielu kolegów się zemną zgodzi..
Prawdę mówiąc nie wiem co miał na celu Twój bezsensowny komentarz. Przypuszczam, że zazdrościsz, ze mam czas i zlecenie zrobić dla klienta i w sieci poszperać i jeszcze coś napisać…
Dzięki za świetne tutoriale dotyczące kohany. Otworzyły mi one oczy na wiele aspektów dotyczących OOP. Poza tym, zastanawiałem się nad możliwością uruchomienia przykładów z kohana.bexlab.pl pod frameworka w wersji 3.2 Próbowałem odpalić kod z ‘Moja pierwsza strona w Kohana’ pod aktualną paczką, ale wywala ‘HTTP_Exception_404 [ 404 ]: The requested URL / was not found on this server’. To na pewno nie jest związane ze złą konfiguracją .htaccess lub bootstrapem – sprawdzałem. Mam strasznie dużo pytań, ale nie wiem jak się z Tobą skontaktować i dlatego pisze ten komentarz tutaj. Z góry przepraszam i prosze o kontakt. Pozdrawiam.
No wiesz. Nie bardzo mnie to dziwi, że ci to nie zadziałało. Uwzględniłeś to, że w Kv3 jest inna filozofia routingu i inne nazewnictwo jeśli chodzi o akcje w kontrolerach?
Faktycznie, różnica w API jest diametralna. Zapoznałem się już z konstrukcją klasy kontrolera. Stworzyłem prosty layout oparty o 4 podstrony, które ładuje przez $this->template->content = View::factory(‘podstrona’), metodą action_index() zdefiniowaną dla każdego osobnego kontrolera z klasą Controller_Podstrona extends Controller_Default, które dzięki routingowi mogą być inicjowane wewnątrz podstawowego kontrolera Controller_Default extends Controller_Template, rozszerzającego standardową klasę kontrolera kohany. No i wszystko było by super, tylko teraz nasuwa mi się pytanie: czy do zdefiniowania kodu dla menu i submenu mam użyć Modelu, czy definiować to na osobnych kontrolerach? Pytam, bo zdążyłem się zorientować, że w przypadku HMVC, klasy modelu używa się do pracy z bazą danych (ORM lub DB). W każdym bądź razie, chwilowo utknąłem i myślę, że przydałoby się na tym blogu jakieś małe sprostowanie, co do prawidłowego wykorzystania MVC w Ko3, choćby na przykładzie kodu z artykułu ‘Moja pierwsza strona w Kohana’. Teraz nie bardzo wiadomo, co gdzie definiować…
Aha, zapomniałem! Stronka z artykułu ‘Moja pierwsza strona w Kohana’ wygląda tak: http://galeria.webh.pl/k24/
Oczywiście, brakuje submenu, bo tak jak napisałem wyżej – utknąłem. Może autorka, zasugeruje jakieś rozwiązanie.
“No i wszystko było by super, tylko teraz nasuwa mi się pytanie: czy do zdefiniowania kodu dla menu i submenu mam użyć Modelu, czy definiować to na osobnych kontrolerach?”
Napiszę Ci jak ja to robię, ale z zastrzeżeniem, że nie mam pewności, że to jest najlepsze rozwiązanie. Dla menu głównego używam metody before głównego kontrolera (u Ciebie to będzie Controller_Default), żeby pobrać za pomocą modeli dane do menu). Następnie w odpowiedniej akcji odwołuje się do tych danych, żeby sobie zaznaczyć, która pozycja jest aktywna. Na końcu w metodzie after głównego kontrolera zanim zrenderuję stronę wczytuję widok dla menu głównego i przekazuję mu dane.
Podobnie działam w przypadku submenu. Z założenia submenu jest wspólne dla wszystkich akcji danego kontrolera. Zatem jego dane wczytuję za pomocą modelu w metodzie before danego kontrolera, a potem postępuję tak jak z menu głównym.
Właśnie dla ‘Mojej pierwszej strony w Ko3’ używałem dla głównego kontrolera metody before() do pobrania zmiennych, oraz metody after() do przekazania danych do tych zmiennych (w moim przypdku tylko tablicy $main_menu, $styles i $scripts) bez metody, bo nie wiedziałem, gdzie ją wywołać. Teraz widzę, że dobrym nawykiem staje się stosowanie metod before() i after() także w kontrolerach ‘potomnych’ i wywoływanie tam odpowiedniego modelu dla submenu, np. tak: $model = Model::factory($name);.
A jak sprawdzić pozycję aktywną? Czy $request = Request::current(); nadaje się do tego?
Dlaczego w ogóle wspomniałem o tych wątpliwościach dotyczących Modelu. Ponieważ, kiedy rzucimy okiem na dokumentację, np. na użycie ORM, łatwo można wyciąągnąć konkluzję, że Model stosuje się do operacji na bazie danych, albo przynajmniej wszystko zmierza w tym kierunku:
To create a new Model_User instance, you can do one of two things
$user = ORM::factory(‘user’);
// Or
$user = new Model_User();
Nie mniej jednak, wydaje mi się, że zastosowanie Modelu do wygenerowania menu jest najlepszym rozwiązaniem. Nadal będę kombinował z tym kodem i może nawet wrzucę źródło w najbliższym czasie.
Kolejna kwestia (sorry, że w kolejnym poście, ale nie chce niszczyć czytelności tego bloga), to jak to jest z tą wydajnością metod before() i after()? Ile danych można tam wrzucić i jak to wpłynie na pracę serwera?
I wreszcie, trochę o konstruktorach:
1.Dla mojej stronki w Ko3 nie definiowałem zmiennej publicznej $template, gdyż jest ona zdefiniowana w Kohana_Controller_Template, a poza tym nie zakładałem zmiany szablonu z poziomu użytkownika. Czy to jest dobry nawyk?
2.Gdzieś na forum php.pl, ktoś zasugerował, że nie ma sensu definiowania metody konstruktora w głównym kontrolerze, a jeśli już to lepiej w klasie kohany. Co o tym sądzisz?
public $template = ‘template’;
public function __construct(Request $request, Response $response) {
parent::__construct($request, $response);
}
Można np wykorzystać Route::name($this->request->route()); żeby sprawdzić która akcja kontrolera została wywołana. To do submenu. A do sprawdzenia który kontroler został wywołany może być $this->request->controller();
Osobiście wydaje mi się, że stosowanie modelu do czegokolwiek innego niż pobieranie i wstępne przygotowywanie danych jest błędem i nieco wypacza ideę MVC.
Nie wiem jak to jest z wydajnością. To są metody, których się używa po to, żeby zrobić to co i tak zawsze byś zrobił przed i po wywołaniu akcji, jak choćby sprawdzenie autoryzacji jeśli to konieczne, czy ustawienie pewnych stałych elementów widoku jak menu. Moje aplikacje nawet w Kv2 zawsze miały coś na kształt before (upychałam w konstruktorze) i after. Tylko moje after musiałam w każdej akcji wywoływać jawnie, a teraz nie muszę.