Poprzednim razem gdy zabrałem się za ocenę Symfony2, moja cierpliwość bardzo szybko się skończyła. W komentarzach nie zostawiliście na mnie suchej nitki (tylko kilka osób wykazało zrozumienie), dlatego postanowiłem nieco dłużej pomęczyć Symfony2 i jeszcze raz opisać moje wrażenia (tym razem odkładając emocje na półkę). Zatem do dzieła.

Wszystko zaczyna się na stronie Quick Tour, gdzie poznajemy podstawy frameworka. Przewodnik został podzielony na cztery części.

The Big Picture

Sposobów na pobranie frameworka jest kilka. Ja zdecydowałem się na najprostszy z nich, czyli pobranie paczki Symfony Standard Edition. Po rozpakowaniu jej, sprawdzamy czy wszystkie wymagane rozszerzenia PHP są zainstalowane. Czego nam brakuje dowiemy się po wpisaniu do przeglądarki adresu http://localhost/Symfony/web/config.php. Niestety już na samym początku pojawiły się problemy – Install and enable a PHP accelerator like APC (highly recommended). Nie mam nic przeciwko akceleratorom jako wsparciu aplikacji działających pod dużym obciążeniem, ale jeśli akcelerator jest wymieniany jako wysoce zalecany do działa w ogóle, to źle to świadczy o frameworku.

Nie zrażając się pierwszymi zgrzytami, kontynuuję przewodnik i wpisuję do przeglądarki adres http://localhost/Symfony/web/app_dev.php/. Zgodnie z oczekiwaniami, pojawiła się strona startowa oraz pasek z debugiem, który jak się okazało zawiera wiele informacji przydatnych na etapie tworzenia i testowania aplikacji.

Następne w kolejce są podstawy działania frameworka – routing, kontrolery, szablony oraz bundle.

Routing

Ścieżki można definiować na kilka sposób i wszystko byłoby dobrze, gdyby nie możliwość korzystania z adnotacji. Dlaczego? Ponieważ w myśl zasady “skoro można tak zrobić, to tak będzie to robione”, wiele osób będzie “chowało” ścieżki w kontrolerach, skutecznie utrudniając ich odnalezienie i ewentualną modyfikację.

Poza tym, routing prezentuje się świetnie. Jest prosty w użyciu, nie wymaga znajomości magicznych zaklęć i daje nieograniczone możliwości w definiowaniu ścieżek. In plus należy zaliczyć możliwość określania typu requestu, a co za tym idzie dla jednego adresu, np. /kontakt możemy przypisać dwie akcje – jedną dla GET, drugą dla POST. Bardzo pomocne. Jeszcze bardziej pomocne jest określanie formatu odpowiedzi. Na koniec jeszcze warto wspomnieć, że parametry ścieżki są dostępne jako argumenty metody (tak jak w ASP.NET MVC).

Ponieważ debugowanie ścieżek zapisanych w kontrolerach to koszmar, Symfony2 dostarcza konsolowe narzędzie pozwalające wylistować wszystkie ścieżki i ich szczegóły.

Kontroler

Sercem każdego frameworka MVC jest kontroler, który obsługuje przychodzące żądanie i odpowiada na nie, najczęściej w postaci kodu HTML, rzadziej jako JSON, XML, tekst lub przekierowanie (inne typy również są możliwe). W sumie na ten temat nie da się wiele napisać. Kontroler jaki jest każdy widzi i nic nowego w tej materii nie da się wymyślić.

Szablony

W mojej opinii systemy szablonów w PHP to pomyłka, ale skoro już i tak Symfony2 wszystko pakuje do cache’u to niech będą. Składnia to kalka szablonów z Django. Przynajmniej wzorują się na dobrym rozwiązaniu. Nic nie stoi na przeszkodzie, aby wykorzystać dowolny inny system szablonów.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Od dwóch dni przez środowisko programistów PHP (i nie tylko) przetacza się wiadomość o migracji kodu interpretera PHP z Subversion na gita. Kiedyś w jednym z komentarzy na blogu Wojtka Soczyńskiego obiecałem, że także spróbuję podjąć misję informowania o co ciekawszych wiadomościach pochodzących z wnętrza grupy php.internals, także zapraszam do lektury pierwszego wpisu z tej [...]

Pracując na stanowisku programisty nie uciekniemy od kwestii kontroli wersji. O ile na czyimś serwerze dostaniemy po prostu login, hasło i adres repozytorium, o tyle na swoim [lub jakimkolwiek innym administrowanym przez nas] musimy się o wszystko zatroszczyć sami. W dzisiejszym wpisie chciałbym przedstawić kilka informacji nt. tego, jak naprawić jeden z dosyć irytujących problemów [...]

Prawie rok temu popełniłem wpis Symfony 2 okiem zendowca. Mimo iż testowana wersja nie była finalna, wywarła dobre ogólne wrażenie. Jakiś czas temu społeczność PHP świętowała wydanie stabilnej wersji frameworka, organizując przy tym różnego rodzaju imprezy i zalewając Twittera i RSS informacjami na temat Symfony 2. Konfetti opadło, dokumentacja wydaje się być skończona, przede mną duży projekt, przyszła więc pora na sprawdzenie co w trawie piszczy.

Zaczęło się standardowo od pobrania paczki z frameworkiem i rozpakowaniu jej na serwerze. Po uruchomieniu check.php, pokazało kilka błędów i ostrzeżeń wynikających ze świeżej instalacji PHP. Po dodaniu wymaganych rozszerzeń, wszystko poszło jak po maśle. Moją uwagę przykuło groźnie brzmiące ostrzeżenie Install a PHP accelerator like APC (highly recommended). Niby nic, ale jeśli już na dzień dobry dostaję po twarzy informacją, że framework wymaga akceleratora, to zaczynam w niego wątpić.

Pamiętny ostrzeżenia, zabrałem się za konfigurację Nginx (nie korzystam z Apache od pewnego czasu). Nie będę rozpisywał się na ten temat, ponieważ dokładne instrukcje można znaleźć pod adresem http://www.zalas.eu/nginx-configuration-for-symfony-projects.

Po zainstalowaniu frameworka, odpaliłem przygotowane strony, pobawiłem się Hello Fabien! i zabrałem za przeglądanie kodu. Pierwsze zdziwienie – ogromna ilość plików cache. Co to musi być za kobyła, że wszystko leci do cache? Ok, niby dzięki temu wszystko ładnie śmiga, ale jaki jest sens tworzenia czegoś, co bez takiej ilości cache nie będzie w stanie działać (nie zapominajmy o wysoce zalecanym akceleratorze). Co mnie najbardziej zdziwiło to cache Twiga, który zapisany do postaci klasy, przy pomocy echo, wyświetla kod HTML bezpośrednio w metodzie. O tak:

    // line 15
    public function block_menu($context, array $blocks = array())
    {
        // line 16
        echo "<span class=\"label\">
    <img src=\"";
        // line 17
        echo twig_escape_filter($this->env, $this->env->getExtension('assets')->getAssetUrl("bundles/webprofiler/images/profiler/mail.png"), "html");
        echo "\" alt=\"Configuration\" /></span>
    <strong>E-Mails
    <span class=\"count\">
        <span>";
        // line 20
        echo twig_escape_filter($this->env, $this->getAttribute($this->getContext($context, 'collector'), "messagecount", array(), "any", false), "html");
        echo "</span>
    

";
    }

Mój niepokój wzrósł po tym, jak w katalogu app nie znalazłem kodu aplikacji. WTF? Czy aplikacja to tylko cache, logi, konfiguracja i widoki? Gdzie reszta? Okazało się, że kontrolery (modeli się nie doszukałem) znajdują się w katalogu src. Czyżby kod Symfony2 był kompilowany ze źródeł do postaci binarnej lub jeszcze większej ilości cache? Tego nie wiem – mój limit WTF/minutę za szybko się wyczerpał.

A wyczerpał się między innymi dlatego, że routing, coś po powinno być jak najprostsze, został beznadziejnie zaprojektowany. Dlaczego? Ponieważ ścieżki można zdefiniować jako adnotacje w kontrolerze. Znaleźć takie coś w większej aplikacji musi graniczyć z cudem.

Niestety nie miałem okazji dotrwać do modeli i generatorów. Co więcej, nie udało mi się w sensownym czasie dotrzeć do tutoriali traktujących o tych zagadnieniach. Wygląda na to, że Zend Framework na długo pozostanie moim ulubionym frameworkiem PHP (przynajmniej do czasu wydania drugiej wersji).

Zainspirowany wpisem na blogu Kamila B., a dokładniej fanboy'owskimi komentarzami, postanowiłem sprawdzić jak się ma sprawa z własnymi selektorami dla prototype.js. W końcu oba (jQuery i prototype) mają wspólny silnik - Sizzle.Toteż wpis będzie porównaniem tego jak wygląda sytuacja w jQuery i w mojej ulubionej bibliotece.

Dawno, dawno temu opublikowałem Linkdump #19 prezentujący zbiór materiałów dotyczących biblioteki MooTools. Kontynuując tą "krucjatę przeciwko jQuery", zapraszam Was dzisiaj do lektury kolejnej serii linków związanych z tym narzędziem.     Fotografia: jeffisageek, CC-BY. Linkdump #57: MooTools. NPM + MooTools + Ender = <3. Czyli kilka słów o zarządzaniu pakietami związanymi z MooTools. Events with [...]

Kolejny quiz z serwisu Nettuts+. Tym razem nasze szare komórki zostaną wystawione na naprawdę duży wysiłek, ponieważ nie będzie tutaj podstępnych pytań zakładających znajomość najgłębszych sekretów języka. W przypadku CSS przetestowana zostanie nasza znajomość kaskadowości. Za pierwszym razem uzyskałem 80% (3 błędy). Jak wam poszło? Zapraszam do zabawy.

http://net.tutsplus.com/quizzes/nettuts-quiz-5-css-specificity-and-cascading/