Moduł do tworzenia elementów widoku Opcje

[slawooo]

Chciałbym zaprezentować i poddać Waszej ocenie moduł ułatwiający oprogramowanie warstwy prezentacji (widoku) w modelu MVC.

W odróżnieniu od tego jak to standardowo bywa w różnych frameworkach PHP, tutaj widok nie jest "gołym" szablonem, nakładki typu smarty czy twig też nie mają z moim pomysłem nic wspólnego. Główna idea opiera się na potraktowaniu warstwy widoku jako kodu w pełni obiektowego, a więc korzystającego ze wszystkich korzyści z niego płynących, takich jak dziedziczenie, enkapsulacja itp.

Cała koncepcja opiera się na obiektach, które nazwałem komponentami. Chodzi tu po prostu o pewne odrębne elementy interfejsu - "komponenty" wizualne, rozumiane zupełnie dowolnie, jak np. menu, okno logowania, komentarze, galeria zdjęć czy cokolwiek innego widocznego na ekranie. Każdy z takich komponentów może składać się z zagnieżdżonych innych komponentów, a na samym "dole" znajdują się gotowe komponenty będące zwykłymi tagami HTML (lub w wyjątkowych przypadkach mogą to być też klasyczne szablony). Dzięki takiemu podejściu, budowanie elementów interfejsu jest prostsze, nie prowadzi do duplikowania kodu, no i kod nie wygląda jak oparty na include z PHP 4.x ;]

Moduł powstał przy tworzeniu aplikacji zbudowanej na frameworku kohana, ale bez większych akrobacji można go dopasować do własnych zastosowań.

Link do źródeł: https://github.com/SlawomirOlchawa/components

Ciekawy jestem Waszych opinii odnośnie takiego rozwiązania, odnośnie samego kodu również.
Przy okazji, jeśli ktoś spotkał się z podobnym podejściem w jakimś z frameworków to chętnie dowiem się więcej na ten temat.

Dla lepszego zrozumienia, przykładowe fragmenty kodu:

Widok:

[PHP] pobierz, plaintext 
class Component_Category_Info extends Tag_Block
{
    /**
     * @var Model_Category
     */
    protected $_category;
 
    /**
     * @param Model_Category $category
     */
    public function __construct(Model_Category $category)
    {
        parent::__construct();
 
        $this->_category = $category;
        Helper_Includer::addCSS('media/app/css/category.css');
    }
 
    /**
     * @return string
     */
    protected function _render()
    {
        $this->addCSSClass('category_info');
 
        $descriptionBlock = new Tag_Block($this->_category->description);
        $descriptionBlock->addCSSClass('lightBg');
        $descriptionBlock->addCSSClass('description');
 
        $this->add($descriptionBlock);
 
        return parent::_render();
    }
}
[PHP] pobierz, plaintext 

Kontroler:

[PHP] pobierz, plaintext 
class Controller_Category extends Controller_Entity
{
    public function action_index()
    {
        $info = new Component_Category_Info($this->_entity);
        $info->cache($this->_entity->getURL().'/info');
        $this->layout->add($info);
    }
}
[PHP] pobierz, plaintext 

Ten post edytował slawooo 5.11.2015, 02:08:34

[slawooo]

Dzięki za konkretną odpowiedź.

1. Masz oczywiście rację, choć przestrzenie nazw w PHP są nieco niedopracowane... (https://pornel.net/phpns/pl)
Zresztą jakiś czas temu próbowałem przerobić cały większy projekt (składający się również z modułu z tego wątku) na przestrzenie nazw, ale nie wystarczyło mi cierpliwości (IMG:style_emoticons/default/smile.gif)
Dokładnie nie pamiętam, ale utknąłem gdzieś na styku frameworka właśnie. Poza tym kilkanaście linijek "use" na początku każdego pliku zniechęciło mnie dość skutecznie.

2. To taka zaszłość z C++ (gdzie "this" jest opcjonalne), W PHP faktycznie nie ma uzasadnienia.
Jedyny plus, to wg mnie lepsza czytelność no i jak zauważyłeś wymuszenie przemyślenia widoczności metod na początku (IMG:style_emoticons/default/smile.gif)

3. Co do render, to muszę dokładniej wyjaśnić, wg mnie wszystko jest ok. Metoda publiczna - "render" zawiera ogólny mechanizm renderowania, w tym również obsługę cache. Oczywiście można ją nadpisać/rozszerzyć i dodać jakieś nowe działanie, ale generalnie komponenty dziedziczą ją bez żadnych zmian. Jest wywoływana przy tworzeniu głównego szablonu (layoutu) w kontrolerze i dlatego właśnie jest publiczna.

Natomiast metoda chroniona - "_render" nie jest (i nie powinna być) wywoływana nigdzie na zewnątrz komponentu i dlatego właśnie jest chroniona (IMG:style_emoticons/default/smile.gif) Opisuje tworzenie danego komponentu, bez wnikania w ogólne sprawy takie jak cache (aby nie duplikować kodu cache w każdym komponencie) i bardzo często wykorzystuje dziedziczenie i konstrukcję "parent::_render()".

Dzięki temu rozbiciu właśnie użycie cache jest bardzo proste - aby włączyć cache dla danego elementu wystarczy użyć:

[PHP] pobierz, plaintext 
$element->cache($name)
[PHP] pobierz, plaintext 

(przykład jest w pierwszym poście). Domyślnie cache jest wyłączone i dla każdego elementu który ma być cacheowany trzeba użyć powyższej linijki.

Tak nawiasem mówiąc to konstrukcja z dwiema metodami (jedna publiczna, druga prywatna/chroniona) jest implementacją wzorca "metoda szablonowa" - https://pl.wikipedia.org/wiki/Metoda_szablo...zec_projektowy).

4. Faktycznie biblioteka nie jest przenośna i bez kohany nie ruszy, ale takich miejsc jest dosłownie kilka (i nie są to kluczowe fragmenty kodu) i łatwo można ją przerobić na potrzeby innego frameworka. Choć przyznam, że już mi się nie chciało za to zabierać (IMG:style_emoticons/default/smile.gif)

5. Możesz rozwinąć co masz tutaj na myśli mówiąc o interfejsach? "Component" jest klasą abstrakcyjną, a więc znacznie bliżej jej do interfejsu niż "konkretnej implementacji".
Teoretycznie mógłbym stworzyć interfejs dla komponentu i zawrzeć w nim metodę "render", a klasa "Component" by go implementowała, tylko czy nie byłaby to sztuka dla sztuki?