kminek.pl

Elastyczne rozszerzanie domyślnych helperów w CakePHP Grzegorz Wójcik

27 Mar, 2010  |  Artykuły, PHP

Bawiąc się frameworkiem [1] CakePHP (wersja 1.3) natrafiłem ostatnio na pewien problem: wyobraźmy sobie całkiem sporą aplikację opartą o Cake z dziesiątkami widoków. W każdym z tych widoków, co najmniej parę razy korzystamy z metody link() Cake-owego HtmlHelpera np.:

  1. <?php echo $this->Html->link('Strona główna', '/'); ?>

metoda domyślnie wygeneruje następujący mark-up:

  1. <a href="/">Strona główna</a>

tymczasem potrzebowałem, aby zwracany mark-up miał taką postać:

  1. <a href="/"><span>Strona główna</span></a>

Aby tego dokonać, konieczne jest wywołanie metody link() w ten sposób:

  1. <?php echo $this->Html->link('<span>Strona głowna</span>', '/', array('escape' => 'false')); ?>

Jak widać, aby osiągnąć pożądany mark-up, należy wyłączyć domyślny „escaping” tytułu linku w metodzie link(). Wszystko fajnie – tylko co jeśli chciałbym, aby linki w całej aplikacji miały element span w środku? Przecież nikt przy zdrowych zmysłach nie będzie przeczesywał kilkudziesięciu widoków i zmieniał parametrów wywołań metody link(). Jak ugryźć ten problem? Zanim przedstawię rozwiązanie, przytoczę parę istotnych informacji o helperach w CakePHP.

Helpery w CakePHP

Generalnie w Cake nie ma czegoś takiego jak automatyczne ładowanie helperów w momencie pierwszego użycia w widoku (przynajmniej na chwilę obecną). To, z jakich helperów chcemy korzystać w widoku, określamy za pomocą atrybutu $helpers w kontrolerze np.:

  1. class PostsController extends AppController {
  2.  
  3. public $name = 'Posts';
  4. public $helpers = array('Html', 'Rss');
  5.  
  6. public function index() {
  7. }
  8.  
  9. }

Dzięki powyższej konstrukcji, w widoku każdej akcji kontrolera Posts mamy dostęp do HtmlHelpera i RssHelpera. Atrybutu $helpers możemy użyć także w AppController, czyli „kontrolerze wszystkich kontrolerów” – w ten sposób dany helper zostanie załadowany globalnie dla wszystkich widoków w naszej aplikacji:

  1. class AppController extends Controller {
  2.  
  3. public $helpers = array('Session', 'Form');
  4.  
  5. }

Teraz mała zagadka – jakie helpery zostaną załadowane w widoku akcji index() w PostsController? Prawidłowa odpowiedź: Session, Form, Html, Rssdzieje się tak, ponieważ tablica $helpers z AppController jest łączona z tablicą $helpers danego kontrolera (w naszym przypadku PostsController).

W tym momencie rodzi się pytanie: co zrobić, jeżeli z danego helpera chcemy skorzystać tylko w jednej akcji danego kontrolera i nie chcemy ładować go dla innych akcji bo np. mamy na względzie oszczędność zasobów serwera? Nic bardziej prostszego:

  1. class PostsController extends AppController {
  2.  
  3. public $name = 'Posts';
  4. public $helpers = array('Html', 'Rss');
  5.  
  6. public function index() {
  7. $this->helpers[] = 'Time';
  8. }
  9.  
  10. }

Dzieki temu zabiegowi, trzymając się naszego przykładu, w widoku dla akcji index() mamy dostęp do 5 helperów: Session, Form, Html, Rss, Time. W taki sposób np. metoda paginate() kontrolera ładuje PaginatorHelper, jeśli nie został on jawnie określony w kontrolerze przez użytkownika. Czyli mamy coś na kształt ładowania helperów na żądanie. Dobrą praktyką jest napisanie prostej funkcji pomocniczej do ładowania helperów, którą umieszczamy w AppController, by mieć do niej dostęp z wnętrza każdej akcji każdego kontrolera:

  1. class AppController extends Controller {
  2.  
  3. public $helpers = array('Session', 'Form');
  4.  
  5. protected function _loadHelpers($helpers = array()) {
  6. foreach ($helpers as $helper) {
  7. if (
  8. !in_array($helper, $this->helpers) &&
  9. !array_key_exists($helper, $this->helpers)
  10. ) {
  11. $this->helpers[] = $helper;
  12. }
  13. }
  14. }
  15.  
  16. }

Uzbrojeni w te informacje, prześledźmy rozwiązanie problemu z początku tego wpisu.

Złe rozwiązanie

Przedstawia się następująco:

Powyższe rozwiązanie ssie z prostego powodu: za każdym razem, gdy wyjdzie nowa wersja frameworka, należy sprawdzić, czy czasem deweloperzy nie zmieniali czegoś w tej metodzie. Jeśli tak – znowu musimy wykonać proces kopiowania pliku i wprowadzania naszych poprawek.

Dobre rozwiązanie

Najlepszym wyjściem jest napisanie własnego helpera, który będzie rozszerzał domyślny HtmlHelper – nasz helper umieszczamy w pliku app/view/helpers/custom_html.php:

  1. App::import('Helper', 'Html');
  2. class CustomHtmlHelper extends HtmlHelper {
  3.  
  4. public function link($title, $url = null, $options = array(), $confirmMessage = false) {
  5. if (!isset($options['escape'])) $options['escape'] = false;
  6. $title = '<span>' . $title . '</span>';
  7. return parent::link($title, $url, $options, $confirmMessage);
  8. }
  9.  
  10. }

Jak widać w wierszu 7 wywołujemy oryginalną metodę link() z Cake-owego HtmlHelpera, jednak zanim to nastąpi wykonujemy czynności, które rozwiązują nasz problem z elementem span wewnątrz linku. Oczywiście to tylko przykład, jednak daje nam obraz jak elastycznie możemy wchodzić w interakcję z Cake-owym helperem i zmieniać np. domyślne wartości parametrów. Przy tym musimy wiedzieć tylko i wyłącznie jak wygląda prototyp przeciążanej metody – nie interesuje nas jej wewnętrzna logika.

Aby skorzystać z naszego nowego helpera dodajemy go do tablicy $helpers kontrolera:

  1. public $helpers = array('Session', 'Form', 'CustomHtml');

i już możemy wykorzystywać jego dobrodziejstwa w widoku:

  1. <?php echo $this->CustomHtml->link('Strona główna', '/'); ?>

Zaraz, zaraz – ale przecież nadal w całej aplikacji wywołania mają postać $this->Html->link() a nie $this->CustomHtml->link(). Okazuje się, że recepta na ten problem jest trywialna – wystarczy proste przypisanie w widoku:

  1. <?php $this->Html = $this->CustomHtml; ?>

To, że powyższy trick działa możemy wykorzystać do ładowania naszych helperów, które rozszerzają domyślne helpery CakePHP i co najważniejsze – odnosimy się do nich przez oryginalne „frameworkowe” nazwy. Zanim Cake załaduje helpery, możemy sprawdzić:

Idealnym miejscem realizacji dwóch pierwszych punktów z powyższej listy jest callback beforeFilter() w AppController:

  1. <?php
  2. class AppController extends Controller {
  3.  
  4. public function beforeRender() {
  5. $this->_overloadCoreHelpers();
  6. }
  7.  
  8. protected function _overloadCoreHelpers() {
  9. foreach ($this->helpers as $helper) {
  10. $helperFilename = HELPERS . Inflector::underscore('Custom' . $helper) . '.php';
  11. if (file_exists($helperFilename)) {
  12. unset($this->helpers[array_search($helper, $this->helpers)]);
  13. $this->helpers[] = 'Custom' . $helper;
  14. }
  15. }
  16. $this->helpers = array_values($this->helpers);
  17. }
  18.  
  19. }
  20. ?>

Oczywiście, jeśli np. w PostsController również korzystamy z callbacka beforeRender() musimy jawnie (najlepiej na końcu) wywołać callback z AppController: parent::beforeRender().

Mapowania naszych helperów na Cake-owe dokonujemy z kolei w callbacku beforeRender() w AppHelper:

  1. <?php
  2. class AppHelper extends Helper {
  3.  
  4. public function beforeRender() {
  5.  
  6. $View = ClassRegistry::getObject('view');;
  7.  
  8. foreach ($View->helpers as $helper) {
  9. if (preg_match('/^Custom/', $helper)) {
  10. $View->{str_replace('Custom', '', $helper)} = $View->{$helper};
  11. }
  12. }
  13.  
  14. }
  15.  
  16. }
  17. ?>

Być może komuś powyższe rozwiązanie okaże się pomocne :) Więcej ciekawych artykułów na temat CakePHP znajdziecie na blogu [2] Grzegorza Pawlika – webbricks.

-----

Wydrukowano z: https://www.kminek.pl/elastyczne-rozszerzanie-domyslnych-helperow-w-cakephp/

Lista adresów URL występujących w tekście:

© 2007-2019 kminek.pl