Elastyczne rozszerzanie domyślnych helperów w CakePHP

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.:

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

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

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

<?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.:

class PostsController extends AppController {
 
    public $name = 'Posts';
    public $helpers = array('Html', 'Rss');
 
    public function index() {
    }
 
}

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:

class AppController extends Controller {
 
    public $helpers = array('Session', 'Form');
 
}

Teraz mała zagadka – jakie helpery zostaną załadowane w widoku akcji index() w PostsController? Prawidłowa odpowiedź: Session, Form, Html, Rss – dzieje 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:

class PostsController extends AppController {
 
    public $name = 'Posts';
    public $helpers = array('Html', 'Rss');
 
    public function index() {
        $this->helpers[] = 'Time';
    }
 
}

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:

class AppController extends Controller {
 
    public $helpers = array('Session', 'Form');
 
    protected function _loadHelpers($helpers = array()) {
        foreach ($helpers as $helper) {
            if (
             !in_array($helper, $this->helpers) &&
             !array_key_exists($helper, $this->helpers)
            ) {
                $this->helpers[] = $helper;
            }
        }
    }
 
}

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

Złe rozwiązanie

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:

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

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:

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

<?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:

<?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:

<?php
class AppController extends Controller {
 
    public function beforeRender() {
        $this->_overloadCoreHelpers();
    }
 
    protected function _overloadCoreHelpers() {
        foreach ($this->helpers as $helper) {
            $helperFilename = HELPERS . Inflector::underscore('Custom' . $helper) . '.php';
            if (file_exists($helperFilename)) {
                unset($this->helpers[array_search($helper, $this->helpers)]);
                $this->helpers[] = 'Custom' . $helper;
            }
        }
        $this->helpers = array_values($this->helpers);
    }
 
}
?>

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:

<?php
class AppHelper extends Helper {
 
     public function beforeRender() {
 
        $View = ClassRegistry::getObject('view');;
 
        foreach ($View->helpers as $helper) {
            if (preg_match('/^Custom/', $helper)) {
                $View->{str_replace('Custom', '', $helper)} = $View->{$helper};
            }
        }
 
    }
 
}
?>

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/

kminek.pl