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]

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

Jak wszystko (IMG:style_emoticons/default/smile.gif) 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ć.