Kanał ATOM
Autor wpisu: batman, dodany: 02.03.2011 08:00, tagi: zend_framework
Kilka dni temu otrzymałem maila z zapytaniem dotyczącym helperów widoku w Zend Frameworku. Nie zagłębiając się w szczegóły, chodziło o mechanizm, który w zależności od pewnych warunków wstawi do layoutu stosowną treść. Podczas wymiany maili padło zdanie będące przyczynkiem dzisiejszego wpisu: nigdzie nie znalazłem konkretnego tutka nt view_helperów. Od dnia dzisiejszego powyższe stwierdzenie przestaje być prawdziwe.
Co to jest helper widoku?
Helperem widoku w kontekście Zend Frameworka nazywamy powtarzalny fragment kodu, który oprócz warstwy prezentacyjnej, posiada własną logikę. Za przykład niech posłuży typowy element większości stron – mały formularz logowania – idealne miejsce do szybkiego zalogowania się do serwisu. Ale co ma się stać z formularzem, gdy użytkownik jest już zalogowany? Najczęściej w jego miejscu pojawiają się link do konta użytkownika oraz link pozwalający na wylogowanie się z serwisu. W minimalistycznej wersji formularz po prostu znika. Oczywistym jest, że dodanie, nawet najprostszego, warunku przez osobę pracującą tylko z warstwą prezentacji może stanowić problem. Poza tym naszpikowanie layoutu dziesiątkami if-ów nie jest najlepszym pomysłem. Tutaj właśnie z pomocą przychodzą helpery widoku. Zamykają one problematycznego if-a w osobnym bycie i pozwalają skupić się na layoucie jako całości, a nie na sieczce instrukcji warunkowych.
Oczywiście helpery nie służą tylko jako pojemnik na instrukcje warunkowe. Każda złożona funkcjonalność, która wymaga wymieszania kodu PHP z HTML powinna znaleźć się helperze.
Jak tworzyć helpery widoku?
Helper widoku jest klasą dziedziczącą po klasie Zend_View_Helper_Abstract. Domyślną lokalizacją helperów jest katalog application/views/helpers. Nazwa klasy helpera musi składać się z przestrzeni nazw oraz nazwy helpera. W praktyce będzie to Zend_View_Helper_MojHelper, gdzie MojHelper jest nazwą helpera oraz nazwą pliku, w którym klasa musi zostać zapisana. Ostatnim wymogiem stawianym przed helperem widoku jest nazwa głównej metody. Musi się ona nazywać tak samo jak helper, przy czym ma rozpoczynać się małą literą oraz być metodą publiczną. Przykładowy helper będzie więc miał postać:
class Zend_View_Helper_MojHelper extends Zend_View_Helper_Abstract
{
public function mojHelper()
{
}
}
Ważne jest aby pamiętać, że helper widoku ma zwrócić zawartość, a nie ją wyświetlić.
Do helpera można przekazywać argumenty. Nie różni się to niczym od przekazywania argumentów do standardowej metody znajdującej się w klasie.
class Zend_View_Helper_MojHelper extends Zend_View_Helper_Abstract
{
public function mojHelper(array $arg1, $arg2 = null)
{
}
}
Jak wywoływać helpery widoku?
Z helperów korzysta się w taki sam sposób, jak ze zwykłych metod obiektu widoku. Uczulam tutaj na stwierdzenie “obiektu widoku”. Helpery powinny być wywoływane tylko i wyłącznie w plikach layoutu oraz widoku. To, że można je wywołać w innym miejscu, nie oznacza, że powinno się to robić.
Wywołanie przykładowego helpera będzie wyglądało następująco.
// wersja bez argumentów
echo $this->mojHelper();
// wersja z argumentami
echo $this->mojHelper(array('123', '234'), 'abc');
Zwracanie zawartości przez helpery
Wspomniałem, że helper nie powinien “echować” treści, tylko ją zwracać. Ale co zrobić w przypadku, gdy kod HTML zwracany przez helper jest sporych rozmiarów, przez co babranie się w escape’owanie (nigdy nie wiem jak to poprawnie zapisać – jakieś sugestie na przyszłość ?) znaczników i argumentów powoduje ból głowy?
Rozwiązania są dwa. Możemy zwrócić treść poprzez wyrenderowanie pliku widoku lub skorzystanie z partiala. Pierwszy sposób nie różni się niczym od standardowego renderowania widoku kontrolerze. Ewentualne zmienne zapisujemy do widoku, a następnie renderujemy plik widoku
.