Zend_Layout w przykładach oraz nowe helpery widoku
Wszyscy długo czekali na pojawianie się komponentu odpowiedzialnego za tworzenie i zarządzanie layoutami. Jest to kolejny plus dla Zend Frameworka i uderzenie w tych którzy płakali - jaki to ZF nie jest beee, bo nawet nie ma zaimplementowanego systemu layoutów. Jak widać Zend szybko nadgania. Faktycznie przedtem trzeba było się trochę nagimnastykować żeby to wszystko miało ręce i nogi, tworząc pomocne pluginy, lub inne udziwnienia.
Przejdźmy do sedna. Tak naprawdę to w manualu wszystko jest cacy opisane, ale czytając niektóre wypowiedzi na różnych forach wydaje się że ludzie nie bardzo rozumieją samą idee.
Zaczynamy. W pierwszej kolejności definiujemy wszystkie potrzebne parametry dla widoku. Możemy to zrobić np w bootstrapie.
$layout = new Zend_Layout(array(
'layoutPath' => dirname(__FILE__) . '/app/views/layouts',
'layout' => 'default',
'viewSuffix' => 'tpl'
), true);
$view->doctype()->setDoctype('XHTML1_TRANSITIONAL');
$view->headTitle($config->app->title)
->setSeparator(' / ');
$view->headMeta()->appendHttpEquiv('Content-Type', 'text/html; charset=utf-8')
->appendHttpEquiv('pragma', 'no-cache')
->appendHttpEquiv('Cache-Control', 'no-cache');
$view->headLink()->appendStylesheet('/media/css/style.css')
->headLink(array('rel' => 'favicon', 'href' => '/media/img/favicon.ico'), 'PREPEND');
Następnie tworzymy odpowiedni layout:
<?= $this->doctype() ?>
<html lang="pl">
<head>
<?= $this->headTitle() ?>
<?= $this->headMeta() ?>
<?= $this->headLink() ?>
<?= $this->headScript() ?>
</head>
<body>
<?= $this->render('header.phtml') ?>
layout()->content ?>
<?= $this->action('widgets', 'forum', null, array('limit' => 10)) ?>
<?= $this->render('footer.phtml') ?>
</body>
</html>
Jak widać w obecnej chwili mamy wszystko funkcjonalnie poukładane. Sekcja <head> zostanie wygenerowana z podanych wcześniej parametrów. Jest to bardzo wygodne ponieważ, w specyficznych akcjach możemy pododawać np odpowiednie pliki JS potrzebne tylko i wyłącznie w danej akcji. Nie musimy od razu ustalać na sztywno wszystkich wymaganych skryptów obciążających niepotrzebnie naszą stronę.
public function someAction()
{
$this->view->headScript()->appendFile('/media/js/jquery.js')
->appendFile('/media/js/jquery.form.js')
->appendFile('/media/js/ajax.form.js');
$this->view->headTitle('test action');
}
Podobną możliwość mamy w szablonach. Przy niektórych potrzebujemy załączyć odpowiedni CSS:
<?= $this->headStyle()->appendStyle('somestyle.css'); ?>
Umiejscowieniem dolączanych plików możemy sterować za pomocą prefixów append/prepend.
HeadTitle daje mam bardzo proste w użyciu narzędzie do tworzenia odpowiedniego tytułu strony. Dzięki setSeparator() możemy ustawić odpowiedni separator, a następnie w kontrolerach w metodzie init() lub/i konkretnych akcjach nasz tytuł. Niestety w chwili obecnej przy wywoływaniu zawsze zwraca nam tytuł w tagu <title> co uniemożliwia użycie go do np wyświetlenia nawigacji w innej części naszej strony. Moim zdaniem jest to lekkie utrudnienie. Można to oczywiście obejść, ale nie jest to już takie ładne rozwiązanie. Jeśli ktoś myśli podobnie do mnie, może zagłosować w trackerze za wprowadzeniem opisanej funkcjonalności.
W layoucie odwołujemy się do helpera 'action'. Może być on pomocny w tworzeniu tak zwanych widgetów/komponentów strony. Dzięki niemu mamy możliwość odwołania się do określonej akcji która może przetworzyć odpowiednie informacje i zwrócić je do widoku. Jest to pomocne w przypadku tworzenia niezależnych komponentów strony takich jak: ostatnie tematy z forum, lista bestsellerów w sklepie, promocje, koszyk, logowanie itp. które są umieszczane w wielu widokach. Oczywiście wywoływana akcja korzysta również z struktury szablonów, pozwalając nam utrzymać wymagany porządek w aplikacji. Jeśli to potrzebne możemy się również zabezpieczyć przed bezpośrednim wywoływaniem naszych widgetów sprawdzając w nich z jakiego kontrolera pochodzi request:
public function widgetAction()
{
if( Zend_Controller_Front::getInstance()->getRequest()->getControllerName() == $this->getRequest()->getControllerName() )
{
/* wywal wyjątek, przekieruj... */
}
}
Kolejny 'pomagacz' to parial oraz partialLoop. Niektóre ze swego rodzaju pariali opisałem już parę akapitów wyżej- np. headTitle(). Dokładnie podobnie działają inne. Ułatwiają nam miedzy innymi zarządzanie samodzielnymi blokami szablonów. Dzięki partialLoop możemy np wyświetlić newsy/komentarze i inne dane pobrane z modelu, a szablony do nich możemy trzymać w osobnych plikach. Jest to na pewno przyjemniejsze rozwiązanie niż użycie zwykłej pętli.
To tyle na ten raz. Może to wszystko trochę chaotycznie poopisywałem, ale mam nadzieje że da się z tego coś wartościowego wyciągnąć.
Genialne. Brakowało mi tej funkcjonalności. ZF staje się bezkonkurencyjny.
Artykuł fajny i na pewno przydatny. PS. warto było by poprawić wyświetlające się w kodzie, w miejscu cudzysłowów, encje 8217.
Masz racje, jednak nie mogę znaleźć porządnego silnika do kolorowania składni. Może na tym będzie trochę lepiej.
Heh, muszę kiedyś się przesiąść na Zend_Layout ze Smartów...
Nie trafiłeś. :) Dalej nie rozumiesz idei. Zend_Layout nie ma nic do smartów. To tylko logika konstruowania szablonów. Ja w swoich projektach korzystam właśnie z Zend_Layoutu i Zend_View rozszerzonego o smarty.
No może nie do końca nie trafiłem :-) Chciałbym się przesiąść z e Smartów na Zend_Layout + Zend_View. Smarty chcę odstawić całkiem w odstawkę i trzymać się strikte zend framework (+Propel). Niestety, ale ludzie są przyzwyczajeni do Smartów, więc pewnie przyjdzie mi przez długi czas pracować tak samo, tj.: Zend_View + Smarty. Napewno layout chciałbym trzymać 'gdzieś wyżej', bo teraz mam w smartach stworzoną podobną funkcjonalność jak Zend_Layout - poprostu jest to teraz przemieszane i przez to nie tak proste w utrzymaniu jak powinno być.
Szczerze, nie widzę tu nic innowacyjnego. Mój (krytykowany) framework, który pisałem dla siebie miał to zaimplementowane już grubo ponad półtora roku temu :) No ale liczy się marka.
Symfony też miał, jeszcze wcześniej i co z tego? Poza tym jak jakoś ostatnio widziałem jakiś Twój wpis o swoim FW to 90% przypominał ZF :P
Tak, ale tylko nazewnictwem. To jest wg mnie bardzo dobre. Przypomina też w różnych częściach stary Vframe, Rapide, Zenda, SF i CI. Biorę to co najlepsze, bo o to w tym chodzi. Zcustomizowane pode mnie :)
Nie podoba mi się fragment z
'layoutPath' => dirname(__FILE__) . '/app/views/layouts'
Dziwne trochę, że nie potrafi odnaleźć ścieżki sam :|
Co to znaczy sam? ZF charakteryzuje się tym że wszystko można umieszczać gdzie się podoba, więc jakoś tą ścieżkę trzeba zdefiniować. Można oczywiście zastosować konfigi, żeby było jeszcze łatwiej - to tylko przykład.
Ludzie, ludzie proszę was bo mi się nóż w kieszeni otwiera! Jakich do jasnej cholery "smartów"? Co to jest do licha? Jest TEN Smarty (na upartego TO Smarty) ale nie żadne TE Smarty! Od czego to? Gdzie jest JEDEN Smart że wam wychodzi KILKA Smartów?
Bo co? Kończy się na -Y? No to grat...
* System szablonów [o nazwie] Smarty
* Używam [tego] Smarty na swojej stronie
* Zamierzam przerzucić się z [tego] Smarty na Zend_View
* Smarty _jest_ systemem szablonów
* Instalowanie Smarty
* Artykuł o Smarty
Ewentualnie można się pokusić o pewną dozę odmiany np "Artykuł o Smarty" ale nie jestem językoznawcą by rozstrzygać jak to konkretnie ma być. Ale NA PEWNO nie żadne "smartów"...
Ile jeszcze trzeba podać przykładów by sobie to wbić do głowy?
Smart to jest taki samochód ale nie system szablonów!
Czytając Twoje kolejne artykuły o użyciu ZF odnoszę wrażenie, że trochę zbyt mocno zaczynasz koloryzować. W końcu Zend_layout jest to nowa rzecz. W dokumentacji ZF jest wszystko opisane jak i gdzie zainicjować poprawnie Zend_Layout i go skonfigurować. U Ciebie wygląda to trochę dziwnie? Nieprawdą jest że przedtem trzeba się było nagimnastykować aby używać szablony bo były dostępne gotowe rozwiązania (dodatki) które pozwalały przenosić wręcz żywcem szablony w systemie Smarty. Wrzucenie całej konfiguracji szablonów do bootstrap jest zbyt dużym skrótem. Nawet jeżeli to jest przykład.