selft::write(new subject(’symfony - widok’))->part(1);

Aby obietnicy stało się zadość, blog musi wzbogacić się o nowy wpis. Będzie nim kolejna część informacji dla początkujących, którzy chcieliby zacząć pracę z Symfony ale ogrom tego środowiska napawa ich przerażeniem. Ten wpis poświęcony będzie trochę tym, którzy projektują layouty dla stron, tną grafikę i okraszają ją tekstem - czyli ? Oczywiście napiszę co nieco o warstwie View w modelu MVC. To do dzieła…

We wpisie pt. “II starcie” napisałem odrobinę informacji na ten temat, ale pewnie po przeczytaniu tego macie pewien niedosyt. No i dobrze ponieważ miało to Was zachęcić do samodzielnych poszukiwań głębiej w dokumentacji a mi miało to dać odrobinę wytchnienia przed następnym artem :).
To co powinieneś wiedzieć na początek…

Symfony daje nam ogrom możliwości jeżeli chodzi o warstwę widoku. Możemy konfigurować cały layout dla strony inaczej dla każdego modułu, możemy sterować wywołaniem konkretnych szablonów za pomocą kilku metod, możemy również pominąć całkiem wyświetlanie szablonu i z akcji wygenerować wynikową stronę. Jest wiele opcji od których należało by zacząć ale ja zacznę od omówienia plików konfiguracyjnych.

Główny plikiem w którym mamy zamiar się “grzebać” jest view.yml. Znajduje się od w katalogu “moj_projekt/apps/moja_aplikacja/config/”. Oczywiście znajduje się tam domyślny plik, generowany na potrzeby całej aplikacji. Standardowo ma on postać:

default:
  http_metas:
    content-type: text/html
  metas:
    title:        symfony project
    robots:       index, follow
    description:  symfony project
    keywords:     symfony, project
    language:     en  stylesheets:    [main]

  javascripts:    [ ]
  has_layout:     on
  layout:         layout

Analizując ten plik możemy wyciągnąć z niego informacje na temat domyślnych ustawień dla całej aplikacji w warstwie widoku. Widać, że definiujemy tutaj tagi <meta> określające słowa kluczowe, opis, język i tytuł strony. Dołączamy pliki stylów CSS dyrektywą stylsheets (w nawiasach kwadratowych podając nazwy plików css znajdujących się w katalogu: “moj_projekt/web/css/”, rozdzielając nazwy przecinkiem). Analogicznie postępujemy z plikami skryptów JavaScript’u (znajdują się one w katalogu “moj_projekt/web/js/”). Końcowe dyrektywy mówią nam w jakim pliku znajdować się będzie główny szablon strony - jeżeli oczywiście będziemy chcieli go mieć. Oczywiście, możemy szablony główne zdefiniować dopiero na poziomie modułu co jednak nie zmieni katalogu w którym się one muszą znajdować - “moj_projekt/apps/moja_aplikacja/templates/”. Nasuwa się od razu pytanie czy to wszystko co można zrobić z widokiem ? Owszem, nie wszystko. Co powiecie gdy napiszę, że plik ten możemy stworzyć na poziomie modułu i co więcej, możemy w nim zdefiniować wygląd i informacje, które widzieliście w standardowym pliku dla całego modułu bądź konkretnych szablonów ? Jak dla mnie to dość duże udogodnienie, dzięki któremu mam możliwość chociażby generowania dla różnych podstron mojej aplikacji, innych nagłówków na potrzeby np. SEO. I tak załóżmy że mamy moduł test zawierający dwie akcje: index oraz akcja. Zdefiniujmy osobne parametry dla akcji index a reszta akcji znajdujących się w tym module niech ma również swoje ustawienia (nadpisane z ustawień aplikacji). Plik konfiguracyjny view.yml umieszczamy w katalogu “moj_projekt/apps/moja_aplikacja/modules/test/config/” i ma on następującą postać:

indexSuccess:
  metas:
    title: tytuł modułu test i akcji index
  stylesheets: [-main]
  layout: IndexLayout

default:
  metas:
    title: akcje z modułu test
  layout: ModuleTestLayout

W pierwszej linii pliku, określiliśmy do którego szablonu ma się odnosić konfiguracja a następnie zmieniliśmy tytuł oraz, co jest pewną nowością, usunęliśmy z listy plików CSS załączanych przez aplikację, tylko plik main.css. Co to w praktyce oznacza ? Oznacza to, że konfiguracja widoku, jak z resztą inne moduły też, jest zbudowana hierarchicznie i ustawienia są dziedziczone z nadrzędnego obiektu. Czyli na chłopski rozum pisząc: jeżeli w pliku view.yml dla aplikacji zdefiniowaliśmy pliki css: “main.css”, “menu.css”, “ie7hack.css” a w pliku view.yml dla szablonu indexSuccess z modułu test zawarliśmy wpis usuwający plik “main.css” to i tak zostaną w nim załączone obydwa pozostałe pliki. To samo tyczy się również plików ze skryptami JavaScript’u.

Na końcu zmian dla szablonu indexSuccess, zmieniamy główny szablon nadrzędny na plik “IndexLayout.php” znajdujący się w podkatalogu “templates” w katalogu głownym naszej aplikacji. Kolejne linie definiują domyślne ustawienia dla wszystkich innych szablonów z akcji modułu test. Co ważne, akcja executeIndex() zwracając inną wartość niż domyślna sfView::SUCCESS również zakwalifikuje się do ustawień domyślnych. Mam nadzieje że otworzyłem Wam teraz oczy na to co zwykłym plikiem tekstowym możemy zmienić w ciągu kilku chwil. Pomyślcie sobie ile czasu by trwała zmiana w 50 plikach html parametry <title>. Tutaj możemy go zmienić w ciągu kilku chwil edytując jeden plik konfiguracyjny.

Teraz powinno paść pytanie - A co jeśli nie chce na sztywno wpisać tytułu strony tyko wygenerować go dynamicznie ? A co gdy na podstawie przesłanych parametrów z formularza ma się załączyć konkretnie wybrany plik ze stylami ? A co w końcu gdy chcemy generować inny “Content-type” dla każdej z podstron w zależności od parametrów przypisanych do zalogowanego użytkownika ? A nic odpowiem. Możemy owszem te wszystkie prośby spełnić. A jak ? Na te pytania mam tylko jedną odpowiedź:

obiekt sfResponse

Do tego obiektu dostać się możemy z poziomu akcji wywołaniem:

$this->getResponse();

No i co dalej ? No dalej np. możemy zmienić tytuł strony:

$this->getResponse()->setTitle(’tytuł mojego modułu’);

Proste ? Proste. Oczywiście obiekt klasy sfResponse ma wiele więcej metod do wywołania. I tak np. możemy skorzystać z metody addStylesheet(’nazwa_pliku_bez_rozszerzenia’); aby dodać plik ze stylami, możemy wywołać funkcję addJavascript(’skrypty_javascriptu’); aby zmienić tag <meta> z opisem naszej strony wystarczy wywołać metodę addMeta(’description’, ‘mój opis strony w danej akcji’); itd.

Pełną listę funkcji, które możemy uruchomić możemy zobaczyć tutaj. Oczywiście nie jest to opis dokładnie klasy sfResponse tylko dziedziczącej po niej sfWebResponse ponieważ w przypadku stron internetowych, automatycznie zwracany jest obiekt tej klasy.

Budowa i zasada działania szablonów

Na chwilę odejdziemy od plików konfiguracyjnych, gdyż zanim omówimy następne wartości konfiguracyjne, muszę objasnić w jaki sposób jest zbudowany system szablonów. Otóż szablony to nic innego jak pliki PHP, w których staramy się tylko wyświetlać dane (takie założenie wzorca MVC). Na próżno szukać będziemy w nich jakiegoś specjalnego języka znaczników jak w np. Smarty lub OPT. Symfony daje nam prostą możliwość wyświetlania danych tak jak je “PHP stworzyło” :). Oto przykład prostego szablonu:

<div id=”bodyContent”>
<?php if($page): ?>
<h4><?php echo $strona->getTitle(); ?></h4>
<span class=”date”>data ostatniej modyfikacji: <?php echo $page->getModified(); ?></span><br/>
<?php echo $page->getBody(); ?>
<?php endif; ?>
</div>

Jak widać, w szablonie znajduje się zmienna $page, przekazana z akcji, która jest obiektem mojej klasy zwracającej zawartość strony. Oczywiście mogliśmy zapisać to w prostszej postaci, nie “bawiąc się” w stosowanie akternatynego zapisu lecz zaleceniem twórców symfony jest aby w każdej linii była osobna instrukcja z PHP aby szablon był czytelniejszy. Możemy się do tego stosować, ale nie jest to wymagane.

Zapytacie teraz : a jak przekazać zmienną do szablonu ? Możemy to zrobić na dwa sposoby: albo skorzystać z właściwej metody dla akcji bądź komponentów (o których za chwilę) albo zapisać zmienną za pomocą magicznej funkcji __set() zaimplementowanej w klasie sfComponent (dla dokładnej informacji, ta klasa jest bazową klasą dla klas sfAction -> sfActions oraz sfComponents używanych jako podstawy do tworzenia klas akcji i komponentów). Przykład:

$this->setVar(’page’, new PageObject());
$this->page = new PageObject();

Dwa powyższe zapisy są tożsame i oznaczają stworzenie zmiennej dla szablonu i nazwie page i zapisanie w niej nowego obiektu klasy PageObject. Te dwie metody są najbardziej uniwersalne i łatwie do zapamiętania ale jeżeli chcemy to skomplikować, to możemy skorzystać zawsze z pośrednictwa obiektu klasy sfParameterHolder, który tak naprawdę odpowiada za zarządzanie parametrami na potrzeby np. szablonów. Po dokładny opis powyższej klasy, jak zwykle odsyłam do dokumentacji. Odwołujemy się do tego obiektu za pomocą metody:

$this->getVarHolder();

Skoro już wiemy w jaki sposób przekazać zmienne, powinniśmy poznać reguły, wg których Symfony wie, ktory plik jest plikiem domyślnym dla aktualnie wykonywanej akcji lub komponentu.

Nazewnictwo szablonów

Jak już powinno nam być wiadomo, każda akcja musi mieć określoną nazwę. Czyli najpierw słowo “execute” a później nazwa akcji zaczęta z dużej litery. Szablony również mają podobne zasady. Pliki dla danego modułu muszą się znajdować w podkatalogu “templates” w katalogu modułu. Nazwy ich zaczynają się od nazwy akcji, zaczynając małą literą, a następnie dodane są, zaczynające się z dużej litery nazwy statusów zwracane przez akcję pochodzących z klasy sfView. I tak dla funkcji w module executeRegister() nazwy szablonów będą mogły się nazywać:

• registerSuccess.php - w przypadku zwócenia sfView::SUCCESS lub bez zwracania jakiejkolwiek wartości (jest to wartość zwracana domyślnie)
• registerAlert.php - w przypadku zwrócenia sfView::ALERT,
• registerError.php - w przypadku zwrócenia sfView::ERROR,
• registerInput.php - w przypadku zwrócenia sfView::INPUT

Oprócz wymienionych wartości, funkcje mogą jeszcze zwracać wartości:

• sfView::HEADER_ONLY - zwracane są tylko zdefiniowane uprzednio nagłówki ($this->getResponse()->setHttpHeader();),
• sfView::NONE - pomijane jest wykonywanie części tworzenia widoku,
• sfView::RENDER_CLIENT - zawartość zostaje przetworzona/zrenderowana i zwrócona wysłana bezpośrednio do klienta akcji, zwracana jest wartość null,
• sfView::RENDER_NONE - nie są zwracane żadne wartości,
• sfView::RENDER_VAR - zawartość zostaje przetworzona/zrenderowana i zwracana jest w postaci ciągu znaków.

Jak można wywnioskować, możemy dla jednej akcji stworzyć kilka szablonów i w zależności od zwracanej wartości wyświetlić dla nich inne wyniki.

Nazewnictwo komponentów

Wspomniałem też o komponentach. Jeżeli nie mieliście jeszcze z nimi do czynienia to pokrótce wyjaśnie o co chodzi. Otóż, komponent to nic innego tylko specyficzny rodzaj akcji, ale wywoływany z wewnątrz szablonu za pomocą funkcji:

<?php include_component(’nazwa_modulu’, ‘nazwa_akcji_komponentu’, array()); ?>

gdzie nazwa modułu to moduł do którego odwołujemy sie, nazwa akcji komponentu to po prostu nazwa metody znajdującej się w klasie komponentu. Ostatni parametr to tablica zmiennych przekazywana do funkcji komponentu. Jest on opcjonalny. Dlaczego i po co je stosować ? Na przykład weźmy stronę internetową na której menu generowane jest dynamicznie. Po co na każdej ze stron generować na nowo menu, skoro możemy generację “wrzucić” do komponentu, a w szablonach, w których potrzebujemy tego menu, po prostu wywołać działanie kompomentu.

Ale wracając do tematu. Nazewnictwo komponentów jest podobne jak w przypadku części szablonów zwanych”partial” o których również za chwilkę będzie. Nazwę szablonu dla komponentu zaczynamy od znaku “_” a następnie zaczynając małą literą piszemy nazwę naszej metody (oczywiście bez słowa “execute”).

Dla porównania komponentu i szablonu pozwolę zacytować sobie tabelkę z książki o FW Symfony porównującą akcje i komponenty:

Konwencja	Akcje	Komponenty
Plik z funkcjami	actions.class.php	components.class.php
Bazowa klasa	sfActions	sfComponents
Konwencja nazewnictwa funkcji	executeMyAction()	executeMyComponent()
Konwencja nazewnictwa szablonów	myActionSuccess.php	_myComponent.php

Komponenty są o tyle ciekawym sposobem na wykorzystanie powtarzania tych samych czynności, ponieważ dają nam dostęp do tego samego na co pozwala nam akcja. Czyli mamy dostęp do bazy, uprawnień użytkowników, odpowiednich obiektów z symfony itp. Jednakże, jak zapewniają nas autorzy Symfony, komponenty są szybciej wykonywane niż akcje więc starajmy się ich nie unikać.

Partials

Skoro zacząłem o komponentach to nie ma możliwości przejścia obojętnie od jeszcze dwóch innych typów szablonów czyli: partial oraz slot. Szczerze powiedziawszy to nie mam jakiegoś polskiego słowa, które w miarę by odzwierciedlało o co tak naprawde chodzi więc posługiwać się będę oryginalnym angielskim nazewnictwiem.

Zacznijmy od szablonów partial. Co to takiego ? Są to częsci szablonów, które możemy wywoływać z wewnątrz innego szablonu ale nie mogące operować na żadnych danych, oprócz tych, przekazanych do nich przez wywołanei funkcji:

<?php include_partial(’nazwa_szablonu’, array()); ?>

Pierwszy parametr to nazwa, natomiast drugi parametr to opcjonalna lista zmiennych w postaci tablicy asocjacyjnej, do których będzie można się właśnie w tym partial’u odwołać. O ile drugi parametr nie wymaga zbytniego komentarza, o tyle warto na chwilkę przystanąć przy pierwszym. O ile w przypadku komponentów wiedzieliśmy do którego komponentu z którego modułu się odwołujemu. O tyle tytaj musimy zastosować pewien wybieg a raczej zastosować się do rozwiązania zaproponowanego przez twórców Symfony. Otóż, do partial’i możemy odwoływać się na kilka sposobów:

• wywołując funkcję <?php include_partial(’mojKawalek’); ?> odwołujemy się do pliku _mojKawalek.php który znajduje się w katalogu “templates” modułu z którego uruchamiamy ww. polecenie,
• wywołując funkcję <?php include_partial(’innyModul/mojKawalek’); ?>odwołujemy się do tego samego pliku ale z katalogu “templates” modułu “innyModul”
• z kolei wywołując funkcję <?php include_partial(’global/mojKawalek’); ?> plik który wykonujemy znajduje się w podkatalogu “templates” katalogu głównego naszej aplikacji.

Partial’e są dobre do wykorzystania gdy często musimy wyświetlić np. skomplikowany fragment szablonu, w którym zmienia się tylko i wyłącznie treść. Tą treść przekażemy jako parametr i już nie musimy się martwić, że przepisując po raz kolejny kod gdzieś popełnimy pomyłkę.

Slot

No i dochodzimy do momentu, kiedy każdy poczatkujący, zapoznający się z dokumentacją do warstwy widoku, dociera do typu szablonów - slot. Na początek sprawia trudność ale po zaznajomieniu się nie jest już taki straszny. O co właściwie w nim chodzi ? Najlepiej odpowiedzieć na przykładzie. Załóżmy że projektujemy główny layout dla strony i chcielibyśmy aby w jednej z części menu, pojawiały się inne opcje dla osoby zalogowanej, a inne dla osób nie zarejestrowanych w serwisie. W tym momencie “do akcji wkracza” slot. Definiujemy do stosownie do zapotrzebowania w pliku głównym layout’u:

<?php if(has_slot(’nazwa_slotu’): ?>
<?php include_slot(’nazwa_slotu’); ?>
<?php else:? >
<div class=”unregistered”>Jesteś użytkownikiem niezalogowanym</div>
<?php endif; ?>

W tym momencie, jeżeli będzie przetwarzany główny layout strony (a jest on przetwarzany na końcu) i znajdzie się w którymś z szablonów zdefiniowany slot:

<?php slot(’nazwa_slotu’) ?>
<ul>
<li>Twoje konto ma: 12938 punktów</li>
<li>Aktywny od 1985 roku</li>
</ul>
<?php end_slot(); ?>

to zostanie ta cześć szablonu głownego zamieniona z tą zdefiniowaną w innym szablonie. Sloty oczywiście możemy definiować w dowolnym miejscu co daje nam dość duże pole do popisu. I znowu cytując manual: “Wypełniając slot to tak jak przypisać wartość do zmiennej” (mam nadzieje że nie pokręciłem cytatu i że dość prosto napisałem o co chodzi ze slotami ponieważ sam mam wątpliwości czy jest to zrozumiałe).

Najciekawsze…

…są oczywiście helpery i myślę, że skoro wiecie jak nazwać pliki szablonów, skorzystać z komponentów, partiali czy też inych slotów to możecie na dokładkę poczytać o funkcjach, które z założenia i z nazwy mają nam pomóc w szybkim budowaniu szablonów.

Istnieje kilka grup helperów zdefiniowanych w Symfony. Jest ich naprawdę dużo więc zajmę się tymi, które są najczęściej wykorzystywane:

• AssetHelper - funkcje do obsługi załączania różnych plików do strony (Javascript, CSS, obrazki) oraz do załączania np. tagów <meta>
• FormHelper - generowanie formularzy
• JavascriptHelper - generowanie wszystkiego co ma związek z Javascriptem
• UrlHelper - generowanie poprawnych linków do akcji i modułów w FW
• PartialHelper - funkcje do wczytywania komponentów, partiali, slotów itp.
• HelperHelper - zawiera tylko jedną funkcję use_helper() która dodaje do szablonu możliwość wykorzystywania w nim funkcji zawartych w innych helperach.

Oczywiście jest jeszcze kilka innych ale co ze mnie by nie był za wykładowca jeżeli nic bym nie zadał jako czynność do wykonania własnoręcznie :).

Pierwsze z funkcji z rodziny helperów opisałem już zupełnie przypadkowo przy omawianiu slotów, partiali i komponentów i nie będe powrótnie ich opisywał. Przypomnię tylko, że są to:

• include_component(),
• include_slot(),
• include_partial(),
• slot(),
• has_slot(),
• end_slot()

i pochodzą one z PartialHelper. Służą jak już wpomniałem do załączania jednych szablonów do innych, z pominięciem lub bez wykonywania jakichkolwiek instrukcji PHP.

Przejdźmy do następnej rodziny funkcji UrlHelper. Pomagają nam one w zarządzaniu linkami na stronie, tak aby były poprawne i zawsze prowadziły w to samo miejsce, niezależnie od środowiska uruchomieniowego. I tak wyliczając najczęściej stosowane:

• link_to(’text odnośnika’, ‘modul/akcja?nazwa1=wartosc1&nazwa2=wartosc2′, array()) - funkcja zwraca tag <a>, czyli odnośnik z odpowiednio przeformatowanym na potrzeby symfony URLem. pierwszy parametr do tekst który ma się ukazać jako odnośnik, drugi to tzw. internalURI, natomiast trzeci to tablica opcji dla tagu <a>
• url_for(’modul/akcja?….’, $absolute) - funkcja zwraca przeformatowany na potrzeby symfony adres URL. Parametrami są: internalURI oraz wartość true/false mówiąca o tym czy ma to być link absolutny czy nie.
• mail_to(’adres@email.com’, ‘text do podstawienia’, array()) - funkcja która robi to samo co link_to() z tą różnicą, iż tworzy link do otwarcia domyślnego programu pocztowego aby wysłać wiadomość pocztą elektroniczną do podanego adresata
• button_to(’text na buttonie’, ‘modul/akcja?nazwa=wartosc’, array()) - i znowu efektem działania funkcji jest odnośnik, tylko tym razem w formie przycisku

Reszta funkcji jest stosowana (przynajmniej prze ze mnie - na razie) dość rzadko, tak więc po cały opis funkcji z rodziny UrlHelper odsyłam tutaj.

Kolejną rodziną funkcji jest JavascriptHelper. Rodzina ta zawiera funkcje zwracające elementy oddziałujące na pozostałe cześci strony za pomocą języka JavaScript. Co więcej, Symfony domyślnie stosuje framework dostępny dla tego języka - script.aculo.us co owocuje tym, że rodzina tych funkcji zawiera odwołania do niektórych możliwości tego frameworka. W tej rodzinie znajdziemy także funkcje, dające nam możliwości oddziaływania na stronę poprzez technologię AJAX. Niestety funkcji jest dość dużo, że zdecydowałem się na osobny artykuł dotyczący właśnie Javascriptu i AJAX’a w Symfony. Mam nadzieje, że będzie to już nastepny z planowanych wpisów :) a tymczasem jeżeli jesteście niecierpliwi możecie zaglądnąć do dokumentacji.

Bardzo ciekawą i często wykorzystywaną rodziną funkcji jest FormHelper. Jak sama nazwa wskazuje, ma ona pomagać nam w budowaniu formularzy znajdujących się na stronach. Podadto, powiązana jest ona z mechanizmem walidacji tychże formularzy i zawiera również funkcje, pokazujące błędy zwrócone w fazie spawdzania poprawności wpisanych danych. Tutaj mamy dość duże pole do popisu ponieważ większość z istniejących elementów formularzy została “przerobiona” na funkcje i przykładowy formularz może wyglądać tak:

<?php echo form_tag(’/email/formSend’)); ?>
<?php echo input_hidden_tag(’send’, $sf_request->getParameter(’isset’, false)); ?>
<h4><?php echo $title; ?></h4>
<div id=”emailFormItems”>

<?php echo form_error(’email’); ?>
<?php echo label_for(’email’, ‘Adres email:’); ?>
<?php echo input_tag(’email’, $sf_request->getParameter(’email’, ”)); ?><br/>

<?php echo form_error(’temat’); ?>
<?php echo label_for(’temat’, ‘Temat zgłoszenia:’); ?>
<?php echo input_tag(’temat’, $sf_request->getParameter(’temat’, ”)); ?>

<?php echo form_error(’tresc’); ?>
<?php echo label_for(’tresc’, ‘Treść:’, array(’style’=>’vertical-align:top;’)); ?>
<?php echo textarea_tag(’tresc’, $sf_request->getParameter(’tresc’, ”), array(’rows’=>’10′, ‘wrap’=>’virtual’)); ?><br/>

<center><?php echo submit_tag(’Wyślij wiadomość’); ?></center>
</div>
</form>

Jak widać, nie skorzystaliśmy z żadnego tagu obsługującego formularz (no może za wyjątkiem zamknięcia formularza :)). Ale przeanalizujmy:

• form_tag() jest funkcją, która generuje nam początkowy tag <form>; jako pierwszy parametr podajemy miejsce, do którego jest wysyłany formularz, w naszym przypadku jest to moduł email i akcja jego formSend; drugim parametrem jest tablica asocjacyjna opcji dla tagu <form>; warto dodać iż jeżeli chcemy mieć formularz, który będzie przesyłał pliki na serwer to w opcjach należy ustawić “multipart”=>”true”;
• funkcja input_hidden_tag() zwraca tag <input> z opcją type ustawioną na hidden; czyli po prostu, pole ukryte formularza; pierwszy parametr to nazwa pola, drugi wartość, trzeci to tablica opcji
• form_error(’nazwa_pola’) - jest to funkcja, która w powiązaniu z ustawieniami w settings.yml oraz walidatorami, wyświetla odpowiednio sformatowany komunikat błędu zwrócony przez walidator;
• label_for() - zwraca tag <label> dla pola podanego jako pierwszy parametr o watości parametru drugiego;
• input_tag() - podobnie jak funkcja input_hidden_tag() zwraca tag <input> ale parametr type ma ustawiony na text, tak więc wykorzystujemy ją dla pól tekstowych;
• textarea_tag() - zwraca znacznik <textarea> o określonej nazwie i wartości.

Oprócz użytych tutaj funkcji mamy dostęp do kilku udogodnień oferowanych przez Symfony:

• select_language_tag(’nazwa_pola’,…) zwraca tag <select> w którym możemy wybrać jeden z prawie wszystkich języków dostępnych na naszym świecie :)
• select_country_tag(’nazwa_pola’,…) zwraca tag <select> w którym możemy wybrać jeden z prawie wszystkich krajów na świecie :)
• input_date_tag() wyświetla grupę tagów odpowiedzialną za wybranie daty
• input_date_range_tag() wyświetla grupę tagów odpowiedzialną za wybranie dwóch dat określających jakiś zakres czasu (polecam wywołać powyższe dwie funkcje z opcją ‘rich’ ustawioną na ‘true’)

Oprócz tego jest wiele funkcji, które odpowiadają za generowanie pól typu ‘password’, ‘image’, ’submit’,’ reset’ czy jeszcze innych elementów formularza. Warto się z tym zapoznać, gdyż bardzo ułatwiają pracę. Obszerny opis znajdziecie tutaj.

Ostatnią rodziną wymienioną przeze mnie jest AssetHelper. Warto wiedzieć, że niektóre funkcje pochodzą właśnie z tej grupy helperów ponieważ nie chcielibyście spędzić kilku godzin na przeszukiwanie dokumentacji na temat jakiejś funkcji z pliku np. domyślnie instalowanego layout.php. Grupa AssetHelperów pomaga dołączać zewnętrze źródła danych jakim są pliku Javascriptu, CSS a także obrazki. Na pewno wykorzystaną przez Was funkcją będzie image_tag(). Ale po szczegóły znowu muszę odesłać do dokumentacji.

Oprócz tych wszystkich wbudowanych opcji, symfony daje nam możliwość stworzenia własnego helpera. Jak ? Jest to bardzo proste. W katalogu lib naszej aplikacji tworzymy podkatalog helper. W nim umieszczamy plik o nazwie grupy helperów (plus obowiązkowa końcówka: Helper.php), które mamy zamiar wykorzystywać. Ja na potrzeby przykładu stworzyłem plik o nazwie mojePomocnikiHelper.php. W nim umieszczamy funkcje, ktore mają nam coś zwrócić, czyli mój plik ma postać:

<?php
function a_tag($name, $link, $title = null) {
return ‘<a href=”‘.url_for($link).’” title=”‘.$title.’”>’.$name.’</a>’;
}
?>

Teraz wystaczy w szablonie wpisać:

<?php use_helper(’mojePomocniki’); ?>
<?php echo a_tag(’wejdż tutaj’, ‘modul/akcja?parametr=wartosc’, ‘tytuł odnośnika’); ?>

i już możemy cieszyć się z odanego stworzenia czegoś, co może nam bardzo ułatwić i przyśpieszyć pisanie. Jednak pamiętajce. Wiele jest funkcji wbudowanych i czasami nie warto wyważać otwartych drzwi.

Słowem końca

Mam nadzieję, że zbytnio nie przynudziłem i będziecie polecać mój wpis początkującym w Symfony. Wiem, że to co tutaj staralem się napisać, nie jest dokładnym opisem wszystkich możliwości Symfony w cześci widoku ale jeżeli starałbym się to wszystko opisać to przy 29 stronie moglibyście zasnąć, oczywiście jeżeli wpis ten by sie w ogóle pojawił w jakimś sensownym czasie. Tak więc oficjalnie zamykam pierwszą część wpisów o MVC z Symfony i do przeczytania.

PS. Jeżeli macie jakiś temat, który byście z większą chęcią chcieli przeczytać to piszcie. W planach są bazy danych, generatory, AJAX i pluginy. Tak więc długa droga przede mną… :)