Some of posts from this blog has been moved to dywicki.pl. You will be automatically redirected to new blog if you would submit comment.
New posts are published on dywicki.pl, this blog contains old content and it is not continued.

Niektóre posty z tego bloga zostały przeniesione do dywicki.pl. Zostaniesz automatycznie przekierowany jeśli bedzięsz chciał dodać komentarz.
Nowe posty sa publikowane na dywicki.pl, ten blog zawiera stare treści i nie jest kontynuowany.

Agavi 0.11 RC3, flow

Filed under Agavi,Framework,PHP by

Mam niebywałą przyjemność oznajmić, że dnia 23 lutego zostało wydane, jak sam tytuł posta wskazuje, Agavi 0.11 RC3. Do pierwszej, w pełni stabilnej wersji jest już coraz bliżej.
Zgodnie z rozkładem jazdy został otwarty jeden ticket, którego realizacja została odsunięta na sam koniec. Mianowicie, opis migracji z wersji 0.10 do 0.11. Ogrom zmian, które przetaczały się przez trunk repozytorium mógł przyprawić o zawrót głowy. Zmiany z rewizji na rewizję potrafiły w jednym momencie zniszczyć skrzętnie budowane narzędzia, które opierały się na zmieniających się wciąż mechanizmach.
Co zyskało Agavi o wersji 0.10? Przede wszystkim developerzy uwolnili projekt od niezręcznej i nieporęcznej konfiguracji w plikach INI, która poza łatwością odczytu nastręczała przede wszystkim problemów… a to brak hierarchiczności, brak możliwości łączenia konfiguracji, w końcu brak narzędzia do walidacji zapisanych danych. W poście “Dlaczego konfiguracja w XML” porównywałem XML również do YAMLa.
Sporą zmianą, naturalnie, na lepsze było zrezygnowanie z tradycyjnego flowu Mojavi 3. Do tej pory wyglądało to w ten sposób, że każda akcja miała metodę getRequestMethods, która zwracała informacje o tym w jaki sposób dostępna jest akcja. Czy to GET, POST, bądź cokolwiek (odpowiednie stałę w klasie Request – GET, POST, NONE). Teraz o sposób dostępu do akcji determinuje nazw akcji. Akcja o nazwie executeRead będzie wykonana w chwili żądania typu GET. Metoda o nazwie executeWrite będzie wykonana w chwili gdy otrzymamy formularz via POST. Metoda execute będzie wykonywana zawsze (o ile walidacja przebiegnie bez zakłuceń). Zysk z tego jest taki, że implementacja różnych kontrolerów nie wpływa na kształt akcji. W chwili gdy wiązały się z tym stałe GET/POST implementacja wywołań z poziomu konsoli była ciężka. W zapowiedziach pojawia się ConsoleRequest, ponieważ z Agavi 0.11 wyleciały kontrolery zależne od kontekstu. Jest jeden Controller, różne są implementacje requestu vide ConsoleRequest (jeszcze niegotowy, będzie w 1.0), WebRequest oraz SecureWebRequest.
W międzyczasie pożegnaliśmy również stałe View::SUCCESS, ERROR, INPUT, ALERT, a metoda getDefaultViewName każdej akcji zwraca po prostu suffix do nazwy widoku (np. metoda akcji “Cart” zwraca wartość “Product”, stąd klasa widoku to CartProductView).
Co więcej w połączeniu z innym mechanizmem Agavi, Output types, zmiany formatu widoku oraz języka nie wiążą się z implementacją bądź powielaniem logiki biznesowej. Implementujemy tylko logikę związaną z widokiem.
Warto również wspomnieć, że od tej chwili metoda Controller::forward(module, action) jak i samo używanie powiązanych akcji jest odradzane, jako źródło potencjalnych problemów (dlaczego widok nie jest uruchamiany) tym bardziej, że tworzenie widoków i akcji załatwia samo Agavi przez taski dla Phinga. W chwili, gdy chcemy użyć innego widoku, spoza tych, które dostarcza sama akca po prostu zwracamy array(module, view name, parameters). Zniknęła również możliwości zrobienia forwarda z widoku (ogólnie problemy z request methods, to co było post-only nie szło przy fowardzie przy żądaniu otrzymanym via get), co wydaje się jak najbardziej uzasadnione.
Widok nie jest organem decyzyjnym, który powinien wskazywać na wykonanie logiki biznesowej. Nie mniej jest możliwość przekierowania do widoku innej akcji.. poprzez redirect bądź poprzez zwrócenie array(module, view name, parameters).

To co jest bolesne w execution flow oferowanym w Agavi to niestety jego prostota. Przede wszystkim brakuje mi (jak w wielu miejscach Agavi) interfejsów. Jest to dla mnie naturalne, że dążę do generalizacji, interfejs jest podstawowym elementem, który uniezależnia od implementacji. Interesuje nas to, co jest widoczne na zewnątrz a nie to co wewnątrz implementacji. Brakuje mi opakowań dla tych tablic, które informacje o widoku. Prosty kontener, bean, który zawiera tylko informacje, ale nie jest tablicą. Przede wszystkim mam możliwość kontroli danych, które otrzymuje. Mogę już w fazie tworzenia obiektu reprezentującego flow wstępnie przeprowadzić jego walidację (czy widok istnieje?).
Zmiany w akcjach i widokach jest jak najbardziej pozytywna i rzeczywiście usprawnia działanie całości. Nie mniej do wersji 2.0 w Agavi na pewno zajdzie ich jeszcze sporo, miejmy nadzieję, że również w celu uporządkowania struktur, usunięcia nadmiaru klas abstrakcyjnych i zastąpienia ich interfejsami (pamiętaj, zanim napiszesz linijkę w klasie, która jest autonomiczna, a której implementacja może się zmieniać, generalizuj, twórz typ bazowy).

Pytaniem ciągle jest czy Agavi podąży w stronę Symfony? Jak najmniej pisania.. Twórcy Symfony ochrzcili wersję 1.0 swojego frameworka nazwą, czy też przydomkiem “enterprise”. Ciężko mi powiedzieć czy było to uzasadnione. Temat Symfony-Agavi często pojawia się w rozmowach między Michałem Mechem a mną. Obaj jesteśmy zgodni w dwóch kwestiach – w Symfony pisze się bardzo szybko oraz ma ono bardzo dobrą dokumentację. Nie ustępuje ona pod żadnym względem dokumentacji Zend Frameworka.

Myślę, że najlepszym życzeniem dla nas wszystkich będzie to: by developerzy Agavi nadążyli z dokumentacją za implementacją.

5 responses so far

5 Responses to “Agavi 0.11 RC3, flow”

  1. Whis says:

    No ładnie :) Choć oznaczenie agavi teraz było czymś kosmetycznym, bo w końcu na co dzień byliśmy świadkami zmian :)
    Sporą zmianą była dla mnie zmiana implementacji widoku, ale zmiana na lepsze. Teraz dla każdej akcji czy też widoku modułu możemy zdefiniować rodzica – jest to nie ocenione w przypadku gdy akcje/widoki danego modułu wykonują takie same zadania – pobieranie jakiś danych, ustawienie zmiennych.
    Co do dokumentacji to fakt, jest hmmm właściwie jej nie ma. Dlatego muszę męczyć co poniektórych wyjadaczy agavi :) Ale miejmy nadzieję że to się rozkręci.
    A tak btw to zapraszam na kanał #agavi irc.freenode.net , bo pamiętaj I TY możesz wspomóc projekt agavi ;)

  2. Michał Mech says:

    Zmiany z 0.10 na 0.11 są ogromne. Tak naprawdę to już prawie inny framework. Dużo lepszy niż wcześniej i na starcie dużo lepszy niż większość istniejących. Niestety ta dokumentacja. Niestety obawiam, że dokumentacja nie pojawi się za szybko.
    Na początku było Mojavi, pojawi umierało, lecz zanim mieliśmy okazję zbierać popiół powstało Agavi. Niestety przędło tak kiepsko, że ktoś zrobił z tego cholernie dobry framework Symfony, któremu na razie niewiele dorównuje (a nie za bardzo ktoś przerasta).
    Teraz piłeczka jest po stronie Agavi, czy stanie się poważnym konkurentem dla swego potomka?
    Na polu kodu i możliwości mogą walczyć jak równy z równym ale na polu dokumentacji i promocji Agavi chowa się w piach.
    A nie tego mu życzę, przecież musi być alternatywa dla Symfony :)

  3. Whis says:

    A i mamy już RC4 ;) Chyba ostatnia wersja przed 1.0 :>

  4. Przyznam się szczerze, że nie miałem zbyt wielu okazji do zaznajamiania się z oboma frameworkami (Symphony oraz Agavi). Gdzieś ponad rok temu, musiałem/chciałem/potrzebowałem się określić, w który z dostępnych na rynku framewroków jest tym jedynym. Wtedy Symphony wydawało mi się za ciężkie, pozostałe frameworki też do mnie nie przemawiały. Ostatecznie wybór padł na PRADO i przyznam szczerze, że jestem tym frameworkiem zachwycony.
    Wydaje mi się (ale to moje prywatne zdanie), że pójście w kierunku programowanie sterowanego zdarzeniami (event-driven programming) opartego również na gotowych komponentach, to droga w którą należy pójść i już wkrótce to ona “zapanuje” w światku PHP a moda na MVC troszeczkę osłabnie. Potwierdzeniem mojej hipotezy jest np. wypuszczenie przez Borlanda “Delphi for PHP“.

Leave a Reply