Ś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:
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.
Kilka nieatrakcyjnych cech, jakie pozwoliłem sobie wytknąć framework’owi Symfony w poprzednim wpisie, pokazuje jego niedoskonałość. Cóż, trudno - ponoć nie istnieją rozwiązania doskonałe.
Jednak w przypadku tego framework’a, dużo ma się zmienić i to na lepsze. Zapoznając się z jednym z ostatnich wpisów na blogu Symfony, dowiadujemy się szczegółów nt. tego co ulec ma zmianie. Są nimi w większości:
- całkowicie napisany od nowa Command Line Interface (CLI), wraz z solidnie rozpisanym helpem. Jest faktem że podczas procesu developerskiego, Symfony CLI jest wykorzystywany często. Jest więc to krok w dobrą stronę,
- zbudowano nowy subframewok do budowy formularzy. Jest on całkowicie obiektowy. Konsekwencją tego zabiegu jest: wyeliminowanie View Helperów (bardzo dobrze, zalatywały PHP4 ), zastąpienie wątpliwego mechanizmu walidatorów budowanych w plikach YAML, walidatorami obiektowymi ( jako część wspomnianego subframeworka), oraz wszelka integracja warstwy widoku, oraz żądań (Request’ów) z tym systemem. Tutaj duże brawo,
- integracja zabezpieczenia przeciw atakom Cross-site request forgery (CSRF), jako element subframeworku formularzy. W mojej opinii, mechanizmy przeciwdziałania CSRF, są bardzo ciekawym zjawiskiem jakie jest aktualnie w modzie. I dobrze, ponieważ obszar jaki pokrywają serwisy internetowe jest coraz większy. Zwiększanie bezpieczeństwa witryn poprzez propagowanie kolejnych standardów jest przez mnie jak najbardziej uznawane,
- rozszerzono możliwości systemu cache’owania. Woila! Jedna z najgorzej przygotowanych rzeczy w wer. 1.0 została przystosowana do użyteczności. Będzie więc można:
- łatwo usuwać cache’e innej aplikacji, niż aktualna,
- podczas potrzeby uzyskania dostępu do grupy cache’ów w celu usunięcia ich, możemy skorzystać z znaków wieloznaczności ( wildcards ) ( zapowiada się dobra alternatywa dla tagów znanych z Zend Framework),
- jako z miejsca składowania cache’y będziemy mogli wybrać Memcache ( przy aktualnych niskich cenach RAMu, trzymanie np aż 8GB cache’owanych danych w pamięci RAM serwera www nie jest żadnym problemem ),
- generalnie cache w końcu będzie można zastosować nie tylko do warstwy widoku, lub całościowo MCV, ale do wszystkiego, np: warstwy modelu,
- usprawniono pracę z konfiguracjami, tj: lepszy parser YAML, pomocne informacje o błędach w YAML, możliwość większego prze strukturyzowania warstwy konfiguracyjnej. Nie znajduję jednak tutaj żadnej rewolucji. Dotychczasowe rozwiązania były czytelne w mojej ocenie,
- rozbudowano możliwości mapowania obiektowo-relacyjnego (ORM), wraz z aktualizacją przy tym PROPEL‘a do nowszej wersji. Co zwróciło mą uwagę, to poprawienie czytelności plików schematu YAML podczas “zrzucania” istniejącej DB do YAML, oraz dodana możliwość definiowana danych testowych w relacji wiele-do-wielu (w tzw. plikach “fixtures”, zawierających stałe dane testowe, które się exportuje do bazy danych )
- usprawniono system routingu. Nie wiele tu do skomentowania. Dobrze, ot co!,
- rozbudowano możliwości systemu wielojęzykowego ( i18n ). To chyba jedno z ważniejszych usprawnień! Dzięki podłączeniu silnika cache’owania, oraz dodaniu narzędzi CLI do zarządzania różnicami w treści szablonów widoku, a słownikami (XLIFF w tym przypadku), tworzenie projektu wielojęzykowego w Symfony będzie w końcu wygodne!
To większość zmian jaka idzie z nową wersją. Jak widać jest tego na tyle sporo, a w mojej ocenie zmiany mają na tyle znaczenie, są tak wspaniałe i usprawniające pracę i jej jakość, iż z własnej strony, osobie noszącej się z zamiarem nauki tego framework’a polecał bym zaczekać jeszcze. Tak by zacząć od studiowania najnowszej wersji 1.1. Opinię tę opieram na fakcie tego jak wiele z wersji 1.0 stanie się nieaktualne i nie zalecane, jak również na tym, iż dokumentacja w postaci książki “The Definitive Guide to symfony”, owszem dostępna on-line w wersji 1.1, nie jest jeszcze zaktualizowania ( przez co informacje w niej o rozwiązaniach z wersji 1.1 jest szczątkowa ).
Ostatnio opublikowana rewizja w wersji 1.1 to Beta2. Nie udało mnie się jednak dotrzeć do informacji, kiedy możemy sie spodziewać rewizji Public Release. Z pewnością będzie to jeszcze kilka tygodni, przynajmniej.
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.