Heavymind

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

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.

advAJAX, HTML_AJAX, SAJAX, scriptaculous - to nazwy bibliotek AJAX’owych, które w mniejszym lub większym stopniu znam i używałem dotychczas. Tak więc gdy odkryłem istnienie kolejnego framework’a: jQuery, byłem nastawiony sceptycznie do niego. Mimo wszystko musiałem się z nim zapoznać ze względu na projekt nad jakim zacząłem pracować. Teraz wiem że warto było - nie zajęło wiele czasu by się o tym przekonać. Wart on jest z całą pewnością dokładniejszego poznania. Otóż jego innowacyjność zawiera się w jego prostocie i zaawansowaniu zarazem. Poruszanie się po strukturze drzewa DOM w każdym kierunku, jak i odwoływanie się do poszczególnych elementów poprzez selektory CSS, XPath oraz własne zaimplementowane w jQuery, odbywa się w bardzo prosty i wygodny sposób. W mej ocenie, ten framework jest bardzo mocnym kandydatem na zdobycie flagi pierszeństwa wśród wszystkich framework’ów AJAX. Tak więc jeśli nosisz się z zamiarem tworzenia współczesnej aplikaji web2.0, ten framework jest wspaniałym do tego celu narzędziem. Dla prostego przykładu dodam, iż dzięki niemu, wyróżnienie wszystkich moich komentarzy w tym weblog’u, poprzez nadanie szarego im tła, było żadnym problemem. Łatwo i przyjemnie.

advAJAX, HTML_AJAX, SAJAX, scriptaculous - are AJAX libraries that more or less I already know and use. So when I’ve discover this another framework : jQuery, I was sceptic to use it as another one. After all I had to, because of the project I was going to work on. Wasn’t take me long, to find out that this one is really worth of spending a time to learn it. I’ve found it very advanced and ease to use at once. By using it, we can navigate the DOM tree in any direction and access any elements by CSS, XPath and own jQuery custom selectors. In my honest opinion this framework is a good pretender to be one of the best. So if any of You is going to learn how to wrote modern web2.0 applications, definitely You should chose this AJAX framework as Your web2.0 tool. For basic example wasn’t no harm, to made a gray background to all my comments on this weblog. Nice and easy.