Нужны ли комментарии для наследуемых методов?

[AmdY]

Тугай
ну вот и видно, что ТЫ не используешь элементарного наследования, чтобы вынести часто повторяющийся код в отдельные методы.

Вот как должен выглядеть этот код

class CategoryListBlock extends AbstractBlock
{
    public function render($category_id = 0)
    {
        return $this->getViewModel( 
            [
                'tree' => $this->getModel('Application\EntityManager\Category')->findTree($category_id)
            ],
            'application/block/category-list'
        );
    }
}

да и название шаблона лишнее, так как его можно легко резолвить на основании имени класса.

 

[Тугай]

AmdY
getModel() покороче конечно чем $this->getController()->getServiceLocator()->get('Application\EntityManager\Category');
Но это очень простой render, я не уверен стоит ли вводить такого рода сокращения. В более сложном мне наверняка понадобится сам $this->getController()->getServiceLocator(), так что выиграша не будет.
Я пробывал реализации с деревом - но они отстой, его сложнее формировать да и обходить во view. Структура может быть немного разной и универсальное дерево мне не нравится, а делать особые деревья и называть их по разному - я против, пусть они будут безымянными строками кода.
Каждый сам решает для себя, так что спорить сильно не буду.
Проект только обрастает кодом, может я приду к тому что ты написал.

WMix
AbstractEntityManager - ServiceManagerInterfaceAware
$this->getDB() - сокращение, ту я его применил. Достает адаптер из ServiceManager'а.
Применил наверно потому, что кроме бд, тут врядли, что-то пондобится еще от SMa.

class CategoryManager extends AbstractEntityManager
{
//   ...
   public function getListByParentId($parent_id, $offset = 0, $limit = 0)
    {
        $list = array();

        $sql = new Sql($this->getDB());
        $select = $sql->select()
            ->columns(array('categories_id', 'categories_image'))
            ->from(array('c' => 'categories'))
            ->join(
                array('cd' => 'categories_description'),
                'c.categories_id = cd.categories_id',
                array('categories_name'))
            ->where(array('c.categories_status' => 1, 'c.parent_id' => $parent_id))
            ->order('c.sort_order, cd.categories_name');
        if ($offset) {    
            $select->offset($offset);
        }
        if ($limit) {    
            $select->limit($limit);
        }
        $statement = $sql->prepareStatementForSqlObject($select);
        $result = $statement->execute();            
        foreach ($result as $row) {
            $list[] = array(
                'id' => $row['categories_id'], 
                'name' => $row['categories_name'],
                'image' => $row['categories_image'],
            );
        }

        return $list;
    }
  // ...
}

 

[Вурдалак]

А как насчёт протаскивать зависимости явно? Что за дебильная привычка таскать контейнер?

<?php

class CategoryListBlock extends AbstractBlock
{
	private $manager;

	public function __construct(\Application\EntityManager\Category $manager)
	{
		$this->manager = $manager;
	}
}

 

[Тугай]

Вурдалак
Это инкапасуляция. Контролер который занимается компановкой, не должен ничего знать, что блоку нужно. Он ему просто свой контекст передает.
Если занятся потдготовкой всего что нужно для каждого блока, то это придется делать в каждом контролере. Терятся смысл вообще HMVC.

 

[Вурдалак]

Это инкапасуляция. Контролер который занимается компановкой, не должен ничего знать, что блоку нужно.

Да что ты говоришь, так может нужно инстанс получать вот так:

$categoryListBlock = $this->getServiceLocator()->get('CategoryListBlock');

или даже так:

class CategoryController extends AbstractActionController
{
    private $categoryListBlock;

    public function __construct(
        CategoryListBlock $categoryListBlock
    )
    {
        $this->categoryListBlock = $categoryListBlock;
    }

    public function indexAction()
    {
        // ...
    }
}

 

[Тугай]

Вурдалак
Нет, я как раз такого и пытаюсь избежать. Это бессмысленная работа.
Блоку нечего делать в ServiceManagere. Тем более инжектить блоки через конструктор.
Ну и еще разным action - нужны в общем случае разные блоки.

 

[AmdY]

Тугай
смысл же в том, что сам ты пишешь монструозный лазанья код, при этом даже не пытался покрывать это дело тестами. при этом не стесняешься генерировать бред про ООП, который очень смахивает на твой же код.

Здесь виноваты не принципы ООП и его реализации в пыхе, а в том как лично ТЫ пользуешься тем. Что у тебя есть. Ты блин, даже не можешь определиться юзать локатор или хардкордить ModelView и *Nav. Adelf не зря просил показать код.

 

[WMix]

Вурдалак
я за сервис локатор и дробление на модули. конструктор нах, хотя упрощение на лицо.
Тугай
все далеко не плохо, намек был как сделать лучше, не комплексуй, мне к примеру очень даже интересно было послушать отзывы. где-то есть глубокий смысл.
чтоб я еще изменил, разделил бы селект и маппер на 2 метода, их разширил бы до обычных нужд ( в смыле переизбыток данных ->columns(array('categories_id', 'categories_image')) стремящейся к ->columns('*') )
AmdY
эх еслиб все писали как мы этого хотим, не ошибается тот кто не работает. тугай рубит, да есть над чем поработать, но это касается каждого из нас.

 

[Вурдалак]

я за сервис локатор <...> конструктор нах

И иметь зависимость от контейнера? И иметь проблемы с автокомплитом и грязным кодом? Чем же это лучше?

 

[WMix]

трудно угадать что хуже, мне подход очень понравился, хотя я понимаю что это по сути патерн registry только в профиль. (сервис локатор в смысле в модуле.пхп описать)

 

[AmdY]

WMix
а да, нормальный рабочий код, за исключением не тестабилити и с этим свзяаного. Но он прекрасно демонтирует. Что проблема не в теории и не в реализации ООП в пыхе, а в том, как мы этим пользуемся.

 

[WMix]

я тоже подумал об этом читая твой предыдущий пост, представив полностью переписанный метод ради теста, поэтому и предложил разделить выборку и математику

 

[Тугай]

Ты блин, даже не можешь определиться юзать локатор или хардкордить ModelView и *Nav.

Я то как раз определился, в этом то и есть весь смысл такой реализации HMVC в ZF2 и кода, что я привел. Получить легкие динамические расширения контроллера.
Все что предлагалось - только утяжеляет и на мой взгляд не добавляет ясности и чистоты. ZF2 - и так прегружен всякими всякостями.

То что для расширения(блока) контекст контроллера возможно сильно широкий и можно его сужать разными способами, я это принимаю, но не больше.

Если кто покажет, как у него собирается сложная страница, то можно будет сравнить. Ну или хватит офтопить, тема про коменты.

 

[SiZE]

По-моему, я замечательно ответил тут:

Да, бесспорно. Ты то написал как ты делаешь, я написал, а остальные в теорию ударились, будто никак этого не делают =) И вобще хотят видеть исходники бредогенератора

 

[AmdY]

Да, бесспорно. Ты то написал как ты делаешь, я написал, а остальные в теорию ударились, будто никак этого не делают =) И вобще хотят видеть исходники бредогенератора

вот именно, по хорошему нужно бы просто НЕ писать никакого дока в наследнике при переопределении, но phpStorm такое не понимает, поэтому приходится пользоваться костылём с inheritdoc. Это недоработка определённой java ide, а Тугай поднял волну на php, наследование интерфейсы, как я в твоей другой теме не дочитав топика кинул функцию ucfirst.