Heavymind

Gdyby ludzie rozmawiali tylko o tym, co rozumieją, zapadłaby nad światem wielka cisza.

Pragnę poinformować, iż zaktualizowałem trzecią część serii Zend Framework Tutorial, pt.: “Rozwijanie Zend View - Zend Layout“. Artykuł ten jest w tym momencie dostosowany do zmian jakie zostały wprowadzone wraz z wersją 1.5.0 Zend Framework.

Dodatkowo udostępniłem za pośrednictwem serwera SVN, kompletny kod źródłowy. Szczegóły w akapicie Repozytorium SVN.

Świadom zapotrzebowania, przygotowałem drodzy moi czytelnicy, dostęp do kodów źródłowych, gotowych przykładów samouczków z serii Zend Framework. Dostęp do źródeł za pośrednictwem serwera SVN, udostępniam dzięki usługom Google Code.

Osobom nie znającym jeszcze systemu kontrolowania wersji Subversion (SVN), polacam zapoznanie się z jego możliwościami i obsługą, ponieważ jest to jedno z podstawowych narzędzi każdego programisty. Aktualnie, czasowo nie jestem w stanie, by streścić podstawy obsługi jakiegokolwiek klienta SVN, dlatego odsyłam do źródeł wujka Google.

Szczegóły nt. dostępu do kolejnych tagów repozytoriów odpowiednich części samouczka, znajdują sie w dodanych przez mnie sekcjach owych samouczków. Są nimi kolejno:

• akapit Repozytorium SVN w “Zend Framework Tutorial - Pierwsze kroki z Zend Framework“
• akapit Repozytorium SVN w “Zend Framework Tutorial - Rozwijanie aplikacji“

Celowo nie zamieściłem odnośników do repozytorium z kodem źródłowym aplikacji z III części samouczka “Zend Framework Tutorial - Rozwijanie Zend View - Zend Layout“, dlatego że po opublikowaniu Zend Framework w wersji 1.5.1, treść tego artykułu wymaga gruntownego przepisania. Wiąże się to bezpośrednio z faktem załączenia do jądra Zend Frameworka biblioteki Zend_Layout, która w III części samouczka jest opisana jako dodatkowa biblioteka rozszerzająca. Przy tej okazji nie radzę wręcz, by starać się korzystać z treści tej części samouczka.

Pochłonięty światem frameworka Symfony, całkowicie zatraciłem poczucie czasu i “przespałem” moment, w którym to pewnie wszyscy “wymacywali” wszystkie nowe “ficzery” Zend Frameworka 1.5. Zajęty jednak mnogością zagadnień jakie pokrywa swoją funkcjonalnością Symfony, nie sposób było zrobić inaczej.

Po bardzo dokładnym jednak zapoznaniu się z Symfony, wyrobiłem sobie własną opinię na jego temat, która w paru detalach stawia go w nie najlepszym świetle. W mojej opinii :

• model cache’owania jest na tyle niewygodny podczas potrzeby usunięcia “nieaktualnych cache’y”, że jedynym rozwiązaniem pozwalającym użyć ten mechanizm w dużym, a nawet średnim projekcie, jest rozszerzenie go samodzielnie o “tagi”, którymi poszczególne cache można by oznaczyć (co nie było by takie łatwe uwzględniając bardzo rozbudowaną strykturę cache’owania w Symfony)
• i18n (moduł budowania aplikacji wielojęzykowej) jest straszny. Otóż podczas pracy z nim potrzeba jest przenoszenia każdej frazy z template’a do pliku słownika, który można budować np. w formacie XML Localization Interchange File Format (XLIFF) (co akurat jest dobrym rozwiązaniem ze względu na to, że istnieją programy wspomagające pracę z słownikami w tym formacie). Jednak każdorazowa potrzeba pisania frazy w template’cie oraz ponownego zdefiniowania jej w XLIFF’ie jest niewygodna. A już na pewno nie do zniesienia jest, w razie potrzeby poprawienia frazy w oryginale ( w template’cie ), wymóg poprawiania jej w słowniku (np XLIFF). Stosując w kolejnych projektach stałe i sprawdzone rozwiązanie oparte na kluczach stałych ( np “NAVIGATION_ITEM_MEMBER_HOME” ), zastanawiam się skąd takie podejście. Owszem, są sposoby by to obejść, jednak nie w tym rzecz by trzeba było obchodzić domyślne schematy.
• integracja JavaScript ( w tym Prototype oraz Scriptaculous ) w szablony HTML ( template’y ) poprzez zastosowanie licznych tzw View Helperów (znane zagadnienie również dla programistów Zend Framework) jest jeszcze bardziej straszne i w mojej ocenie nie do zaakceptowania! Otóż, idąc tą drogą, jako rezultat szablonu zawierającego udogodnienia web2.0 (w kontekście interaktywności JavaScript i AJAX), otrzymujemy kod HTML, licznie posiekany wstawkami “<script></script>”, czy też CDATA. Mimo więc mej znajomości wszelkich “remote” Helperów (właśnie tych od komunikacji AJAX, oraz wstawek zwykłego JavaScript) w Symfony , pasuję i wybieram tworzenie logiki po stronie klienta (JavaScript) w dotychczasowym stylu: jako osobne pliki .js.
• ostatecznie odniosłem wrażenie, że autorzy książki “The Definitive Guide to symfony“, opisując liczne Helpery widoku (tj. input_tag(),  object_input_tag() itp.), nieraz sami próbowali na siłę przekonać samych siebie do potrzeby pisania template’u za ich użyciem. W mojej skromnej ocenie, szablony HTML, mają być szablonami HTML, a nie zbitką kodu PHP, gdzieniegdzie tylko poprzedzielaną znacznikami DIV. Tak jak w przypadku podstawowych Helper’ów widoku w Zend Framework, pachnie to sztuką dla sztuki.

Jednak to już wszystko co mogę powiedzieć złego o Symfony. Zauważyć więc należy, że by wytypować większość zalet tego framework’a, musiałbym napisać serię felietonów. Szala przeważa za tym, by traktować Symfony jako poważny framework, gotowy by pisać w nim duże, wielojęzyczne i nowoczesne aplikacje www.

Swoją drogą, framework ten w aktualnej stabilnej wersji 1.0 ma już ponad rok, co każe domniemywać , iż w nadchodzącej wersji 1.1 dużo się zmieni. I owszem, ale o tym już w następnym wpisie wkrótce.