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

[in5ane]

Ani Twój przykład z postu, ani nic na githubi'e nie obrazuje mi dokładnie działania tego. Pokaż jakiś trochę większy szablon. Nie widzę potrzeby tworzyć html'a z poziomu PHP i zapamiętywać składnię Twojego modułu.

[slawooo]

[PHP] pobierz, plaintext 
class Component_List extends Tag_Block
{
    /**
     * @var Model_Abstract_Entity
     */
    protected $_entities;
 
    /**
     * @var string
     */
    protected $_noResultsInfo = 'Brak wyników do wyświetlenia.';
 
    /**
     * @param Model_Abstract_Entity $entities
     */
    public function __construct(Model_Abstract_Entity $entities)
    {
        parent::__construct();
 
        $this->_entities = $entities;
    }
 
    /**
     * @param Model_Abstract_Entity $entity
     * @return Tag_HyperLink
     */
    protected function _getListItem(Model_Abstract_Entity $entity)
    {
        return new Tag_HyperLink($entity->name, $entity->getURL());
    }
 
    /**
     * @return string
     */
    protected function _render()
    {
        $entityList = $this->_entities->findAll();
 
        if ($entityList->count() === 0)
        {
            $info = new Tag_Paragraph($this->_noResultsInfo);
            $info->addCSSClass('light');
            $this->add($info);
        }
        else
        {
            $list = new Tag_List();
            $list->addCSSClass('light');
            $this->add($list);
 
            foreach ($entityList as $entity)
            {
                $link = $this->_getListItem($entity);
                $list->add($link);
            }
        }
 
        return parent::_render();
    }
}
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
class Component_ListWithPhotosSmall extends Component_List
{
    /**
     * @param Model_Abstract_Entity $entities
     */
    public function __construct(Model_Abstract_Entity $entities)
    {
        parent::__construct($entities);
 
        $this->addCSSClass('smallphoto_list');
 
        Helper_Includer::addCSS('media/mod/photos/css/main.css');
    }
 
    /**
     * @param Model_Abstract_Entity $entity
     * @return Tag_HyperLink
     */
    protected function _getListItem(Model_Abstract_Entity $entity)
    {
        $tile = new Component_Photo_TileSmall($entity->main_photo);
        $name = new Tag_HyperLink(Text::limit_chars($entity->name,45), $entity->getURL());
        $name->addCSSClass('name');
 
        $result = new Tag_Block();
        $result->add($tile);
        $result->add($name);
 
        return $result;
    }
}
[PHP] pobierz, plaintext 

Przykład komponentu zawierającego listę elementów. Komponent występuje w dwóch wersjach:
1) lista zawiera odnośniki tekstowe (klasa Component_List)
2) lista zawiera odnośniki graficzne (klasa Component_ListWithPhotosSmall)

Druga klasa dziedziczy po pierwszej całą logikę tworzenia i wyświetlania listy, nadpisując jedynie metodę wyświetlającą pojedynczy element listy.

[phpion]

Jak dla mnie to przerost formy nad treścią. Jeśli jednak w Twoich projektach się sprawdza to ok. Domyślam się, że idea jest analogiczna do komponentów z Symfony 1 - widoki posiadające własną logikę (np. pobieranie danych z bazy). W tym przypadku jednak sam widok to był zwykły szablon, a nie element ze składanego w klasie HTMLa.

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

[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
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

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 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ć

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?

[lukaskolista]

1. Masz oczywiście rację, choć przestrzenie nazw w PHP są nieco niedopracowane... (https://pornel.net/phpns/pl)

Jak wszystko jednak w PHP 7 ten problem został już rozwiązany, miejmy nadzieję, że termin 25 listopada jako termin wydania RTM będzie ostateczny.

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 smile.gif

Wszystkie sensowne IDE mają nawigację po strukturze klas, jak ktoś korzysta z notepad++ jako IDE, to sory, ale nie należy się nim przejmować.

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.

Tutaj mamy inne podejście, ale uargumentowałeś swoje i przyjmuję te argumenty, chociaż dalej mi się to nie podoba (intuicja).

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ć smile.gif

Innym programistom tym bardziej się nie będzie chciało, większość jak na dzień dobry dostanie exception, to się do niej zrazi.

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?

Dobrze mnie zrozumiałeś, właśnie o to mi chodzi. Nie, nie będzie to sztuka dla sztuki. Nawet abstrakcyjna klasa jest już jakąś implementacją. Jedynie interface jest bytem pozbawionym jakiejkolwiek cechy danej implementacji. Co w przypadku, gdy mój komponent ma zupełnie inną logikę, niż klasa abstrakcyjna Component? Ok, mógłbym nadpisać metody, ale były by puste, bo przecież moja logika jest zupełnie inna i to jest bez sensu. Cechą elastycznego kodu jest wykorzystanie interface'ów. Weźmy takiego Doctrine'a (mega kombajn, a działa znakomicie). Jak sobie popatrzysz w jego kod, to tam wszędzie są interface'y. Nawet konkretna implementacja, jaką jest Doctrine ORM (implementacja mapowania na obiekty dla relacyjnych baz dancych) nigdy nie wymaga żadnej abstrakcji, a zawsze interface (np. EntityManagerInterface) dzieki czemu mogę napisać sobie swój manager encji bazujący np. na plikach o ile dorobię do tego logikę zapytań SQL.

Nie umiem tego lepiej wytłumaczyć, to trzeba poczuć.