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

[lukaskolista]

Pozwolę sobie zwrócić uwagę na kilka rzeczy:
1. Przestrzenie nazw - ich brak w moim odczuciu dyskwalifikuje Twój projekt. Wiem, w kohanie ich nie ma, znam ten framework jak własną kieszeń i też dlatego go porzuciłem (na rzecz symfony)
2. Prywatne właściwości i obiekty zaczynające się od _ - kompletnie nie ogarniam tej praktyki (może ktoś mi wyjaśni skąd się to wzięło), jak będziesz chciał zmienić widoczność metody z np. chronionej na publiczną, to w całym projekcie będziesz zmieniał jej nazwę?
3. Brak interface'ów - czemu render jest protected?

[PHP] pobierz, plaintext 
abstract class Component
{
    protected $_cacheSettings = null;
 
    public function render()
    {
        if (empty($this->_cacheSettings))
        {
            $content = $this->_render();
        }
        ....
     }
[PHP] pobierz, plaintext 

Publiczna metoda render() wywołuje prywatną, kiepski pomysł, już na pierwszy rzut oka źle to wygląda. Na pewno słyszałeś o dziedziczeniu i konstrukcji

[PHP] pobierz, plaintext 
parent::method()
[PHP] pobierz, plaintext 

Wspominam o tym dlatego, że w publicznym render() korzystasz z cache'u. Co, jeżeli w jednym elemencie chcę używać cache'u, a w innym nie? Nie bardzo wiem, jak miałbym to osiągnąć. Do takich rzeczy, jak cache polecam aspekty (dosyć skomplikowany temat, bo wbrew pozorom stwarza kolejne problemy) lub dekoratory.

[PHP] pobierz, plaintext 
class Template extends Component
{
    ...
    if (defined('Kohana::DEBUG') AND Kohana::$environment == Kohana::DEBUG) {...}
    ....
}
[PHP] pobierz, plaintext 

Samo wystąpienie nazwy frameworka świadczy o tym, że Twoja biblioteka nie jest przenośna i w moim vendorze się nie znajdzie, bo nie będę specjalnie kohany dociągał.

Na sam koniec najważniejsze:

[PHP] pobierz, plaintext 
class Tag extends TagSingle {
    public function add(Component $component = null) {}
}
[PHP] pobierz, plaintext 

Powyższe to tylko przykład. Uzależniasz działanie praktycznie wszystkiego od konkretnej implementacji, co z zasady jest błędem. Powinieneś zastosować interface'y (wspomniałem o tym wcześniej, ale tutaj kontekst jest inny), np. ComponentInterface plus zostawić to, co jest jako powiedzmy natywna dla Twojej biblioteki, aczkolwiek niekonieczna warstwa abstrakcji.