Pamiętam swoje pierwsze implementacje MVC, w czasach gdy słowo framework nie było jeszcze trendy a wiele osób, w tym i ja, nawet go nie używało. W owych pierwszych implementacjach MVC model był pewnego rodzaju fasadą, która zapewniała dostęp do danych. Problem polegał na tym, że kod np klasy User wyglądał następująco:
PHP:
Nieco się rozczarowałem możliwościami oraz wygoda w użytkowaniu własnych “osiągnieć” w dziedzinie frameworków MVC… Freyą … która narazie ląduje w kącie na czas nieokreślony. Być może do niej kiedyś wróce gdy nabiorę troche doświadczenia bo w tym momencie jest to sztuka dla sztuki. Nasty_psycho namówił mnie abym przyjrzał się Symfony za co jestem mu dłużnikiem bo rzeczywiście FW jest świetny. Moje piersze wrażenia są bardzo pozytywne, wiecej napisze gdy skończe czytać ebooka dostępnego na stronie, który jest swoją droga bardzo dobrze przygotowany. Nieco szkoda, że najbilższe ~2 tygodnie będe musiał spędzić tworząc pod php4 ( wiwat państwowe serwery! ), najprawdopodobniej w mojavi, ale potem… cud, miód i orzeszki :D
Ostatnio zacząłem zabawę z ImageMagick. Podczas lektury manuala natrafiłem na setki tysięcy problemów, a moja przygoda się dopiero zaczyna. Pytanie: po co? Tak naprawdę Imagemagick jest potrzebny mi do komponentu Rapide_Image, za który jestem odpowiedzialny w Rapide Framework.
Pierwszym problemem na który natrafiłem to pobieranie parametrów obrazu typu: wysokość, szerokość. Owe dane potrzebne są do różnorakich operacji, np. skalowanie, nakładanie obrazu na obraz (wyliczanie automatycznych pozycji), nakładanie napisu w dowolnym roku obrazu itp.
Następnym problemem będzie wykonanie polecenia exec(), bowiem GD operuje bezpośrednio na resource zawartym w zmiennej, a imagemagick korzysta z linii poleceń, gdzie nie jest to możliwe. Zatem wszelkie metody typu save(), czy display() musiałyby wykonać prywatny call do metody _execute(), która wykonywałaby sformatowane polecenie poprzez funkcję exec(), sprawdzając hash całej komendy, czy nie została już wykonana.
Problemów jest więcej niż się spodziewam… ostatnio nasunęła mi się myśl, gdzie będą zapisywane pliki, na których wykonywujemy operacje, które wymagają uprzedniego zapisania pliku, np metoda display() musi pobrać odpowiedni content z pliku graficznego i wyświetlić go. Gdzie wówczas taki plik by się zapisywał? Wydzielony katalog /var/ we frameworku (do cache i logów, przy okazji do Rapide_Image_Engine_ImageMagick), czy może wlepić pliki do /var/ serwera? Rozważań wiele… póki co skupie się na nauce komend ImageMagick.
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ą.
Jedną z nowości jaką niesie Agavi w wersji > 0.10 jest mechanizm output types. Jest to bardzo proste rozwiązanie, które umożliwia uniknięcie gimnastyki z tworzeniem widoków w różnych technologiach, z którymi wiąże się różna logika. Banalny przykład. Te same dane prezentujemy w postaci HTML jak i PDF a do tego możemy je pobierać przez XmlHttpRequest. Dane są praktycznie identyczne, różny jest format wynikowy i proces jego tworzenia. Dla zwykłej strony wskazujemy szablon, dorzucamy dane i koniec, dla XmlHttp zwracamy JSONa. Stworzenie outputu w formacie PDF nie będzie tak proste jak pozostałych, ponieważ konieczne będzie stworzenie układu strony, dorzucenie fontów etc. Ogólnie w żaden sposób nie da się połączyć tych formatów w jednym widoku bez sporej ilości warunków i "protez". By uniknąć zakopania się w tym wszystkim zwykle tworzy się dodatkową akcję, która w sporej części pokrywała się z pierwotną a różni się tylko widokiem i szablonami. Począwszy od Agavi 0.11 problem przestaje istnieć.
W pliku konfiguracyjnym output_types.xml określamy renderer dla danej technologii, dodajemy obiekty przedefiniowane (parameters name="assigns") i następnie konfigurujemy mapowania adresów do plików (swoją drogą najlepsza implementacja tego mechanizmu z jaką się do tej pory spotkałem). Jest odpowiedni plik zawierający definicję routingu.
Zajmijmy się jednak w pierwszej kolejności konfiguracją output types:
XML:
Jak widać trochę tej konfiguracji jest, nie mniej celowo usunąłem przekazywanie parametrów do drugiego formatu wynikowego by pokazać, że w najskromniejszej wersji definicja taka potrafi się zmieścić maksymalnie w 10 linijkach. Do wszystkich parametrów możemy odwoływać się w widoku. Specyficzne są parametry o nazwie assigns oraz i18n. Pierwszy z nich Agavi wykorzysta po to by od razu w fazie tworzenia renderera wrzucić do niego wskazane obiekty, które znajdują się w kontekście. Drugi z atrybutów jest szczególnie przydatny podczas tworzenia aplikacji z wieloma językami. Parametr i18n jest prefiksem dla nazwy pliku. W przypadku gdy przypiszemy mu wartość subdir framework będzie szukał szablonów po katalogach np. pl/IndexSuccess, en/IndexSuccess. Inne, dopuszczalne wartości to postfix oraz prefix. Nazwy szablonów to odpowiednio IndexSuccess_pl oraz pl_IndexSuccess Atrybut extension określa suffix dla nazwy pliku, którego użyje Agavi przy wczytywaniu szablonu np IndexSuccess.tpl.php. Argumenty ignore_slots oraz ignore_decorators odnoszą się do strategii budowania widoku. W chwili gdy zrezygnujemy z nich wynik nie będzie dekorowany. Tzn. w odpowiedzi użytkownik zobaczy tylko treść wygenerowaną przez widok akcji. Tutaj drobna uwaga. W wersji stabilnej Agavi 0.11 mechanizm ten zachowuje się nieco inaczej. Wybór plików oraz zachowanie dekoratora determinuje layout i elementy layer.
Następnie w routes.xml dla każdej ścieżki możemy określić również format wynikowy danych. Np:
Kanał ATOM
