$this->post(’wstep do symfon(y)ii’, ‘II starcie’);

Jako że zadowolony jestem z tego że udało mi się przebrnąć dalej przez dokumentację do frameworka Symfony to postaram ‘pociągnąć’ dalej cykl wywodów na temat tego narzędzia. Osobiście jestem już po generowaniu admina, tworzeniu modelu bazy danych ( żeby nie było ‘łatwiej’ to na początek oszczędziłem MySQL’a i zacząłem od postgresa ), korzystania z Propela ( ehh… ciężko się przestawić) itp. Ale co by nie zdradzać szczegółów kolejnych wpisów to zacznę od początku. Po raz drugi. Ale tym razem szczegółowiej ponieważ na ‘dzień dobry’ można się pogubić w ilości opcji, katalogów, klas i czego tam sobie użytkownik nie zażyczy….

Struktura katalogów czyli co do czego w projekcie.

Na początek, tak jak już pisałem w poprzedniej relacji z pola walki dobrze by było aby przy korzystaniu z takiego narzędzia jakim jest symfony, podporządkować się ‘porządkowi’ katalogów z jakim się stykamy po zainicjowaniu projektu. Tak więc możemy sobie stworzyć katalog ‘projekty’ gdziekolwiek na dysku (pod warunkiem że będziemy mogli część tego katalogu udostępnić szerszej publiczności (czytaj. udostępnić serwerowi WWW do pokazania jako stronę). Następnie żeby już kompletnie porządek nam zawrócił w głowie stwórzmy sobie w katalogu projekty, podkatalog o nazwie dowolnej byle by się nam kojarzyła z projektem lub abyśmy pamiętali że w nim mamy nasz projekt. Tak więc jesteśmy gotowi do inicjacji naszego projektu. Pamiętając z pierwszej relacji, dobrze by było abyśmy mieli PHP w wersji CLI aby móc skorzystać z dostępnego w symfony generatora struktur katalogów do projektu/aplikacji/modułów. Inaczej będziemy musieli tworzyć wszystko ręcznie, co nie jest niemożliwe, ale dość żmudne i wymaga od początkującego porządnej wiedzy na temat działania samego FW. Tak więc aby stworzyć strukturę katalogową z podstawowymi plikami należy wywołać polecenie:

mojHost$ php /path/to/symfony/data/bin/symfony init-project mojPierwszyProjekt

Przykład jest z linux’a ale nic nie stoi na przeszkodzie aby uruchamiać to pod windowsem czy innym OS’em. Wyjaśniając szczegółowo co do czego to:

• fragment ‘mojHost$’ to jest prompt czy jak ktoś woli znak zachęty systemu i tłumaczyć nie będę tego :)
• ‘php’ to wywołanie interpretera php; jeżeli nie macie ścieżki dostępu do niego dopisanej do zmiennej PATH to musicie podać bezpośrednią ścieżkę do tego
• /path/to/symfony/data/bin/symfony to jest wywołanie skryptu ’symfony’ znajdującego się w ścieżce tak gdzie rozpakowaliście swoją wersję FW (w późniejszym etapie nie trzeba będzie podawać całej tej ścieżki gdyż po wykonaniu inicjacji projektu, skrypt wywołujący polecenia fw jest kopiowany do katalogu projektu)
• init-project to już polecenie samego fw powodującego stworzenie struktury katalogów i stworzenie podstawowej wersji plików
• ‘mojPierwszyProjekt’ to prostu nazwa projektu, którą możemy sobie dowolnie nazwać (w podręczniku do symfony nie znalazłem informacji czy można w nazwie używać spacji ale raczej wychodzę z założenia że nie; polskich liter też raczej nie należy używać - przynajmniej zrobicie to na swoją odpowiedzialność)

Po poprawnym uruchomieniu polecenia pojawi się lista przelatujących na ekranie informacji o tworzeniu plików/katalogów/tokenów oraz informacja na temat ustawiania uprawnień do katalogów do których symfony ma mieć dostęp w trybie RW (read-write). Struktura, która się stworzyła powinna wyglądać mniej więcej w taki sposób:

• ./apps/ - katalog w którym będziemy definiować i tworzyć swoje aplikacje oraz moduły do nich,
• ./batch/ - katalog w którym możemy stworzyć pliki uruchamiające naszą aplikację z lini poleceń (tworzymy je poleceniem ./symfony init-batch <application-name> <environment> <batch-name>; do opisu co i jak z tym wróćę w następnych wpisach),
• ./cache/ - kesz/cache/pamięć podręczna/itp. naszego frameworka,
• ./config/ - katalog z podstawową konfiguracją frameworka (tutaj definiujemy schematy baz danych, połączenia do nich itp.)
• ./data/ - w tym katalogu nasz fw będzie przetrzymywał swoje dane np. wygenerowane zapytania SQL do stworzenia tabel na podstawie schematu
• ./doc/ - jak sama nazwa wskazuje to chyba ‘pojemnik’ na jakąś dokumentację :),
• ./lib/ - w tym katalogu, bazując na swoim przykładzie, znalazły się pliki klas modelu Propela do obsługi bazy danych; co jeszcze tam się może znaleźć to należy doczytać
• ./log/ - chyba nie trzeba tłumaczyć co tu jest
• ./plugins/ - katalog na pluginy do FW; do instalacji pluginów potrzebny jest prawdopodobnie PEAR (nie znalazłem w ’symfony book’ innej metody ale może dokładnie nie szukałem ponieważ chwilowo nie jest mi to potrzebne)
• ./test/ - katalog do tworzenia modułów do testowania naszych aplikacji
• ./web/ - katalog który należy udostępnić serwerowi WWW do pokazywania do jako naszą docelową stronę
• ./symfony - skrypt którym inicjujemy/generujemy/synchronizujemy/wykonujemy polecenia FW.

Od tego momentu możemy spokojnie zamiast wywołań typu ‘php /path/to/….’ korzystać z prostego ‘./symfony’ oczywiście znajdując się na głównej ścieżce naszego katalogu projektu. Symfony już zadbało o to aby w tym pliku były odpowiednie odwołania oraz żeby miał on odpowiednie prawa do wykonywania.

Aplikacja też chce mieć katalog

Jak już doszliśmy do momentu że mamy zainicjowany projekt to należało by następnie zainicjować aplikację. Polecenie które do tego służy to :

mojHost$ ./symfony init-app <aplication_name>

Warto wspomnieć tak naprawdę co to są aplikacje i po co to całe zamieszanie. Aplikacje - oczywiście wg. tego co zdążyłem zauważyć na podstawie swoich doświadczeń to nic innego jak osobno pracujące strony internetowe jednakże korzystające ze wspólnych niektórych zasobów. Przykładem może być strona zawierająca forum dyskusyjne, galerię zdjęć oraz panel administracyjny do obu tych rzeczy jednocześnie. Osobnymi aplikacjami nazwiemy ‘forum’ i ‘galerię’ oraz ‘adminPanel’ jednakże wszystkie mogą korzystać ze wspólnej bazy danych. Czy można to zrobić wszystko razem ? Myślę że tak tylko po co ? Przy mocno rozbudowanej aplikacji możemy w pewnym momencie nie umieć dość dobrze zapanować nad ilością plików/klas/konfiguracji. Po za tym warto skorzystać z chociażby hierarchicznego konfigurowania symfony, które daje ogromne możliwości dostosowania sobie modułu czy całej aplikacji.

Wracając do tematu to po wywołaniu tego polecenia (oczywiście zamiast <aplication_name> wpiszemy sobie swoją nazwę aplikacji) stworzy nam się w katalogu ./apps/ podkatalog o nazwie naszej aplikacji i zawartej w nim gotowej strukturze plików i katalogów gotowych do działania. Jednocześnie w katalogu ./web/ stworzą się dwa pliki. Jeżeli to będzie pierwsza nasza aplikacja to pliki będą miały nazwy index.php oraz index_dev.php. Zawarte są w nich instrukcje uruchamiające ‘Front Controllera’. Co to ten kontroler ? Ano polecam lekturę opisu Bartosza Rychlickiego. Myślę że jest to ładnie opisane i w miarę zrozumiałe. Tak więc kontynuując należy napisać że każda następna aplikacja doda swoje pliki ale już o nazwach takich jak nazwa aplikacji.

Słówko wyjaśnienia należy się do nazewnictwa tych dwóch plików. Dlaczego akurat jeden ma nazwę aplikacji a drugi ma dodane podkreślenie _dev ? Otóż symfony daje nam do dyspozycji coś takiego jak środowisko uruchamiania aplikacji. Jest to nic innego jak odpowiednia konfiguracja uruchomieniowa aplikacji, osobna do np. testowania i działania. Każde środowisko daje nam dostęp do tej samej aplikacji ale pozwala nam na sprawdzenie szybkości, użycie testowych wartości z bazy itp. Domyślnie FW daje nam trzy środowiska:

• prod - środowisko produkcyjne czyli takie jakie klient odwiedzający stronę widzi,
• dev - środowisko testowe pozwalające nam na śledzenie zachowania się aplikacji, czasów wykonywania poszczególnych modułów, ilości zapytań do bazy danych czy chociażby na sprawdzanie wysyłanych wartości i otrzymywanych odpowiedzi,
• test- środowisko do testowania aplikacji jednak dostępne tylko i wyłącznie z lini poleceń.

Oczywiście nie jesteśmy ’skazani’ tylko na te trzy środowiska. Takich alternatywnych konfiguracji uruchomieniowych możemy tworzyć ile dusza zapragnie.

Ale znowu odbiegłem od tematu. Tak więc plik o nazwie application_dev.php jest po prostu informacją dla nas że wywołując ten skrypt mamy środowisko dev włączone. Oczywiście mamy dowolność w zmienianiu nazwy pliku ponieważ konfiguracja jakie środowisko jest uruchamiane jest w środku skryptu.

Co do samej struktury stworzonej przez framework to wygląda ona mniej więcej tak:

• ./apps/mojaNazwaAplikacji/config/ - trzymana jest tu konfiguracja aplikacji
• ./apps/mojaNazwaAplikacji/i18n/ - w tym katalogu umieszczamy pliki z tłumaczeniami na inne języki w formacje XLIFF
• ./apps/mojaNazwaAplikacji/lib/ - katalog z bibliotekami
• ./apps/mojaNazwaAplikacji/modules/ - katalog w którym będziemy tworzyć moduły dla naszej aplikacji
• ./apps/mojaNazwaAplikacji/templates/ - katalog w którym możemy zdefiniować szablony (znajduje sie tutaj domyślnie plik layout.php który jest głównym szablonem aplikacji - bardziej szczegółowy opis znajdziecie w dalszych częściach tego trochę już nudnawego wywodu)

Przerwa na wstęp do konfiguracji aplikacji

Warto zatrzymać się tu na chwilkę przy katalogu config w którym, jak już napisałem jest konfiguracja aplikacji. Mimo że nie jestem jeszcze w stanie mocno szczegółowo go opisać to myślę że na chwilkę można przystanąć aby wprowadzić użytkownika w co nieco. Po pierwsze ‘primo’ - warto zapoznać się z plikiem view.yml. W nim mamy możliwość zdefiniowania sobie chociażby takich wartości jak tytuł strony, słowa kluczowe czy opis. Również mamy możliwość dołączenia arkuszy stylów czy plików ze źródłami skryptów JS. Zmienić w nim również możemy domyślny szablon strony lub go po prostu wyłączyć. Aha… byłbym zapomniał. Wszystkie pliki konfiguracyjne mające rozszerzenia YML są napisane w języku YAML. Co do formatu tych plików to krótkie wprowadzenie zrobię ale warto jednak zapoznać się z linkiem po więcej szczegółów. Znowu odbiegłem od tematu ale chyba już się zdążyliście przyzwyczaić :). Po drugie ‘primo’ - kolejnym plikiem na którym warto się skupić to settings.yml. W nim są parametry dla każdego ze środowisk, które mamy stworzone dla naszej aplikacji. Generalnie warto zajrzeć tam i chociażby poczytać komentarze aby mieć podgląd co i jak można tam zepsu^H^H^H^H ustawić :). Przykładowo możemy np. wyłączyć całą naszą aplikację w czasie przeprowadzania konserwacji. Po trzecie ‘primo’ - warto zapoznać się z plikiem routing.yml w którym to definiujemy zasady konstrukcji URL’i dla naszej aplikacji. Z domyślnych wartości które tam widnieją można łatwo wywnioskować o co chodzi. Wytłumaczę na przykładzie rutowania do modułu obsługującego artykuły:

tytul_rutowania:
  url: /artykul/:action/:kategoria/:rok/:tytul
    param: { module: showArticles }

W pierwszej lini jest identyfikator metody rutowania. Generalnie mamy wolność wyboru jak ją nazwać tylko jak zwykle bez pl literek i spacji. Możemy go później wykorzystać w ‘helpersach’ (funkcje pomagające w wyświetlaniu elementów strony w szablonach). Druga linia to jest url do którego będą że tak powiem ‘przymierzane’ url’e i sprawdzane czy pasują do tego wzoru. Przykładowy url który będzie pasować to : ‘/artykul/pokaz/opisy/2005/theBestOf’. Porównując to zostanie wywołany moduł o nazwie ’showArticles’. Z tego modułu wywołana zostanie metoda ‘executePokaz()’. A parametry jakie zostaną przekazane do tej metody to:

• ‘kategoria’ o wartości ‘opisy’
• ‘rok’ o wartości ‘2005′
• ‘tytuł’ o wartości ‘theBestOf’

Trzeba pamiętać że samo dopasowanie URL’a do wpisanego przez nasz wzorca nie spowoduje sprawdzania poprawności wpisanych danych. Należy pamiętać o tym przetwarzając przekazywane dane. Pamiętać należy również o tym że symfony przetwarzając ten plik ‘przechodzi’ przez niego od góry do dołu i przy pierwszym pasującym wzorcu po prostu go używa. Tak więc zalecanym jest dopisywać swoje metody na początku pliku.
Co do samego wzorca to oprócz dwóch wpisów ‘:method’ oraz ‘:action’ to mamy dowolną rękę przy definiowaniu nazw zmiennych (bo tak naprawdę o to chodzi). Jeżeli spodobało się i chcecie więcej to polecam rozdział 9 symfony book. Tam jest wszystko dokładnie opisane.

Kolejne już ‘primo’ to plik app.yml. W nim definiujemy stałe dostępne dla całej aplikacji. Z używanych przeze mnie plików to jeszcze jest i18n.yml. W nim definiujemy środowisko językowe dla naszej aplikacji. Po dokładny opis reszty parametrów konfiguracyjnych odsyłam do rozdziału 5 symfony book (tym odsyłaniem nie chcę Was zniechęcić do zaniechania czytania moich wypocin lecz poprosić o uzupełnienie sobie wiadomości na temat zagadnień których ja z jakichś przyczyn nie poruszyłem).

Struktura modułów

Skoro napisałem A jak aplikacja to kolejnym krokiem należało by napisać M jak moduł. Moduły są to części aplikacji odpowiedzialne za realizację poszczególnych zadań. Przykładowo możemy stworzyć moduł który będzie miał za zadanie zwracać tylko dane z bazy, moduł który będzie obsługiwał wyświetlanie obrazków w normalnych rozmiarach bądź ich miniaturek itp. Przykładów można by mnożyć. Do stworzenia modułu używamy następującego polecenia:

myHost$ ./symfony init-module <application-name> <module-name>

Czyli standardowo: <application-name> zamieniamy na nazwę naszej aplikacji a <module-name> zamieniamy na nazwę nowo tworzonego modułu. Nasz moduł a raczej pliki odpowiedzialne za działanie tego modułu pojawiły się w: ./apps/mojaNazwaAplikacji/modules/nazwaModulu/. Standardowa struktura to:

• …./modules/nazwaModulu/actions/ - w tym katalogu są pliki odpowiedzialne za realizowanie akcji oraz za działanie komponentów używanych w szablonach,
• …./modules/nazwaModulu/config/ - konfiguracja modułu,
• …./modules/nazwaModulu/lib/ - przy poprzednich takich katalogach prosiłem Was abyście doczytali; tak więc ja też posłuchałem się i okazało się że w tym katalogu możemy umieszczać pliki ze swoimi klasami które chcemy użyć; przez to nie trzeba ich importować do skryptu poprzez ‘include’ czy ‘require’ ale autoloader z symfony sam je tam znajdzie i załaduje,
• …./modules/nazwaModulu/templates/ - szablony dla modułu
• …./modules/nazwaModulu/validate/ - pliki konfiguracji wspomagające walidację danych wprowadzanych przez użytkownika.

Domyślnie nas, jako niezaawansowanego użytkownika interesują na początek dwa katalogi: ‘actions’ i ‘templates’. W pierwszym znajduje się plik z klasą obsługującą akcje danego modułu. Każda z akcji (czyli metod klasy) musi mieć odpowiednią nazwę aby można było ją wywołać. Początek nazwy metody musi zawierać wartość ‘execute’ a po nim dołączona jest ‘prawdziwa’ nazwa akcji z tym że zawsze z dużej litery, niezależnie od tego z jakiej tak naprawdę się zaczyna.

Do każdej z tych akcji przyporządkowany jest szablon znajdujący się w katalogu modułu - ‘templates’. Nazwa pliku z szablonem również jest nieprzypadkowa. Nazwa pliku zaczyna się od nazwy metody a kończy się, jak to napisać tak żeby wam nie zakręcić mocno, nazwą wartości zwracanej przez akcję z tym że ta nazwa musi być stałą pochodzącą z klasy sfView. Najlepiej uczymy się na przykładach tak więc oto on:

- URL (domyślne ustawienia konfiguracji ) : /pages/showInfo/id/2
- moduł wykorzystany: pages
- metoda modułu: executeShowInfo()
- wartość zwracana przez metodę ( domyślnie ) : sfView::SUCCESS
- parametr dostępny w metodzie ‘id’=>2
- szablon wyświetlany: showInfoSuccess.php

Teraz proste ? Mam nadzieje że tak.

Trochę widoku

Skoro już wiemy co i jak z tworzeniem modułów/akcji/aplikacji to należało by skubnąć nieco informacji na temat samego wyświetlania danych dla użytkownika. Bo czymże jest aplikacja bez, przepraszam za określenie tzw. międzymordzia czyli interfejsu użytkownika ? Na początek warto wspomnieć o wykorzystywaniu przez tego frameworka wzorca projektowego o dźwięcznej nazwie ‘dekorator’ do wyświetlania informacji zawartych w szablonach. Co by długo nie owijać w bawełnę pozwolicie że zacytuję obrazek z ’symfony book’:

Jak widać szablon zwracany przez akcję modułu dekorowany jest przez (domyślnie) plik layout.php znajdujący się w katalogu ./apps/mojaNazwaAplikacji/templates/. Jeżeli podejrzymy źródło tego pliku to od razu widać na czym to polega. Wyświetlany jest nagłówek strony, dołączane są pliki CSS/JavaScript a następnie wyświetlana jest surowa wartość zwracana przez szablony z modułów. Na końcu szablon główny dodaje tagi kończące i sprawę mamy załatwioną. Czy możemy mieć wpływ jakiś większy na to co się wyświetla ? Oczywiście.

Po pierwsze mamy możliwość zmiany domyślnego pliku layout.php na inny. Można zmienić to w plikach konfiguracyjnych modułu lub aplikacji. A można to zrobić już w samej akcji danego modułu wywołując metodę $this->setLayout(’mojWyglad’). Wykonanie tego spowoduje ‘wydekorowanie’ wyników z modułów szablonem o nazwie mojWyglad.php z tego samego katalogu w którym znajdował się domyślny szablon.

Po drugie, podczas tworzenia szablonów mamy w nich do dyspozycji trzy funkcje, dzięki którym mamy możliwość dołączania do szablonu:

• innych części szablonów zawierających jedynie dane które do nich przekażemy
• innych szablonów które korzystają z danych z warstwy modelu
• dynamicznie dołączanych szablonów

Teraz, mimo późnej pory pisania należy przejść do wyjaśnienia pokrótce każdej z funkcji.

- include_partial($name, [$vales])

Funkcja include_partial robi za nas dołączenie do edytowanego szablonu gotowego fragmentu. Pierwszym parametrem i obowiązkowym jest nazwa dołączanego fragmentu szablonu. Możliwe wartości to :

• <nazwa_fragmentu> - załączany jest plik z katalogu ‘mojModul/templates/_<nazwa_fragmentu>.php’
• <nazwa_modulu>/<nazwa_fragmentu> - załączany jest plik z katalogu ‘<nazwa_modulu>/templates/_<nazwa_fragmentu>.php’
• global/<nazwa_fragmentu> - załączany jest plik z katalogu ‘mojaNazwaAplikacji/templates/_<nazwa_fragmentu>.php’

Jako drugi parametr możemy przesłać tablicę asocjacyjną z przypisanymi wartościami do kluczy. Funkcja ta jest najprostszą metodą na dołączenie do szablonu np. menu, które na każdej stronie musi wyglądać tak samo. Dzięki temu możemy uniknąć takich sytuacji, że przy uaktualnianiu wszystkich szablonów akurat jeden pominiemy i na jednej z podstron naszej witryny istnieć będzie niezaktualizowane menu.

- include_component($module, $action, [$values])

Drugą z prezentowanych funkcji jest include_component. Dzięki tej funkcji mamy możliwość wykorzystania pełnego dostępu do danych podobnie jak z metod istniejących w module. Tak naprawdę dla mnie to jest to samo co akcja z tą różnicą że wywoływane jest z szablonu a nie z URL’a. Definicje akcji komponentu tworzymy w pliku components.class.php który tworzymy zaraz obok pliku actions.class.php dla konkretnego modułu. Gwoli przypomnienia - obydwa pliki muszą znajdować się w katalogu …./mojModul/actions/. Każda akcja w pliku komponentów definiowana jest identycznie jak w pliku akcji. Czyli : metoda musi mieć w nazwie ‘execute’, następnie z dużej litery nazwa metody. Różnica jest w nazwie szablonów. Szablony do komponentów znajdują się tam gdzie szablony akcji lecz nazywają się wg. wzoru: _<nazwa_akcji_komponentu>.php. Dzięki tej funkcji, a korzystając z przykładu z opisu poprzedniej, możemy zrobić np. dynamiczne menu pobierane z bazy danych. Parametrów chyba nie muszę tłumaczyć ? No dobra:

• $module - nazwa modułu z którego będzie wywoływana metoda komponentu
• $action - nazwa wykonywanej metody i w sumie też załączanego szablonu
• $values - podobnie jak w poprzedniej funkcji możemy przekazać do innego komponentu wartości, które tam mogą być użyte

- include_slot($name)

No i wreszcie ostatnią z funkcji, które dają nam dostęp do łączenia szablonów jest include_slot(). Ta funkcja pozwala nam na zdefiniowanie w szablonie głównym ( domyślnie : layout.php ) miejsca, które będzie można ‘podmienić’ przez szablon dowolnego modułu. Funkcja przyjmuje jeden parametr i jest nim nazwa ’slotu’. Jednakże do poprawnego używania trzeba skorzystać jeszcze z trzech innych funkcji:

• has_slot($name) - sprawdza czy w załączanych szablonach istnieje zdefiniowany slot,
• slot($name) - początek definicji slotu,
• end_slot() - koniec definicji slotu.

W sumie to nie napisałem o najważniejszej sprawie. Sloty można definiować w dowolnym miejscu: w szablonach akcji, w szablonach komponentów, w szablonach częściowych (partials) bez obawy że zostaną one właśnie w tym szablonie wyświetlone. Czy trzeba czegoś jeszcze ?

helpers ?

Generalnie rzecz biorąc to chyba do szczęścia potrzeba nam tylko kilkunastu funkcji które za nasz zrobią żmudną robotę i wyświetlą HTML’owe tagi na stronie. Nic prostszego. Od tego są właśnie funkcje zwane ‘helpers’ czyli pomocnicy w wolnym tłumaczeniu. Jak używać spytacie ? Ano jak już pisałem, najlepiej człowiek uczy się na przykładzie.

Załóżmy że mamy swoją aplikację i chcemy na jednej ze stron generowanej przez jeden z naszych modułów zrobić odnośnik do innego i w dodatku przekazać parametr. No to piszemy: <a href=”/modul/akcja/parametrName/parametrValue”>linkowany tekst</a>. A co jak zmienimy rutowanie URL’i ? Albo chcemy mieć aktualne odnośniki we wszystkich środowiskach których używamy ? Nic łatwiejszego. Użyjmy helper’a: funkcji link_to(). Wywołanie jest następujące:

echo link_to(’linkowany tekst’, ‘modul/akcja?parametr=wartosc’);

Czyż nie piękne ? Jeszcze jako trzeci parametr możemy przekazać różne wartości np. ‘popup=true’ i mamy gotowy link do otwarcia w nowym oknie przez funkcję JS: window.open.

Helpers’y dzielą się na grupy: ‘Helper’, ‘Tag’, ‘Url’, ‘Asset’, ‘Partial’, ‘Cache’ i ‘Form’. Które grupy są standardowo dołączane do aplikacji można sprawdzić w pliku settings.yml w katalogu ‘config’ dla aplikacji ( jako zadanie domowe ). Do najszęściej używanych (wg. symfony book) to: tag(), content_tag(), link_to, image_tag() itp. Oczywiście symfony nie byłby dobrym frameworkiem gdyby nie można było sobie samemu zdefiniować helpers’a. Aby to zrobić należy w którym z katalogów ‘lib/’ (w zależności od tego jak mocno widoczny ma być) stworzyć podkatalog ‘helpers/’ a w nim plik <nazwa_grupy_helpera>Helper.php. W tym momencie możemy definiować w nim swoje funkcje a użycie ich należy poprzedzić funkcją use_helper(<nazwa_grupy_helpera>) w szablonie.

Co do reszty helper’sów można o nich poczytać w rozdziale 7 symfony book oraz w API znajdującym się na stronie projektu symfony.

Na dzisiaj koniec

Patrząc na ogrom możliwości frameworka wiem że powyższy tekst jest tylko kroplą w morzu potrzeb ale pisząc go mam nadzieję że ktoś, kto będzie szukał informacji jak zacząć z symfon(y)ią skorzysta z niego i przyniesie mu on ulgę, i nie będzie musiał bezskutecznie buszować w internecie w poszukiwaniu polsko-języcznych materiałów. Ja niestety nie miałem tyle szczęścia i musiałem czytać dokumentację angielską ( co niekoniecznie musi mi wyjść na niekorzyść :)). Mimo wszystko, tekstami o tym frameworku pragnę się podzielić z ludźmi którzy bądź nie znają języka lub tak jak ja przez jakiś czas, mają obiekcję czy tak naprawdę poświęcenie kilku/nastu dni na czytanie, czytanie i jeszcze raz czytanie jest warte ‘zmarnowanego’ czasu i snu. W moim mniemaniu warte. I tą puentą skończe moje wywody. W następnym odcinku wstęp do Propela (jak uda mi się do wszystkiego dojść :)))