ZF. Выполнение кода для всех контроллеров

[korchasa]

Автор оригинала: AmdY
а я не понимаю зачем забивать неймспэйс сомнительными переменными, которые как и говорил triumvirat могут не понадобиться.

Да уж, $this->db сильно забивает неймспейс. Правда это неймспейс контроллера, а не экшена, но какая разница

Автор оригинала: AmdY
почему не делать

    public function indexAction(){ 
        $list = Zend_Registry::get('main_dbAdapter')->runMethod(); 
        $wall_table = new Wall();
    }

а лучше через наследование превратить Zend_Registry в Service_Locator с ленивой инициализацией.

Это как бы следующий шаг. Зачем насильно толкать людей вперед до того, как они поймут необходимость?

Автор оригинала: AmdY Любители 100% покрытия тестами могут начинать бросать камни

Если ты про 100%-ное покрытие unit-тестами, то таких не бывает. Очень быстро понимают бессмысленность занятия. Тестировать контроллеры unit-тестами вообще странно, ибо быстро меняются и текстура слишком большая.

 

[Sokil.Dmytro]

бутстрап не подойдет?

http://framework.zend.com/manual/en/zend.application.quick-start.html

 

[DiMA]

Автор оригинала: triumvirat
Когда мы в один базовый/суб класс пихаем какой-то код, например

class base 
{
    public function __construct(){
        $this->main = Zend_Registry::get('main_dbAdapter');
        $this->local = Zend_Registry::get('local_dbAdapter');
    }

то этот базовый класс становится базовым для всех контроллеров, в которых НУЖНЫ экземпляры $this->main, $this->local. Что будет, когда нам понадобится в другом классе ещё и экземпляр $this->other? Правильно, мы напишем класс с дублирующим кодом:

class base2 
{
    public function __construct(){
        $this->main = Zend_Registry::get('main_dbAdapter');
        $this->local = Zend_Registry::get('local_dbAdapter');
        [b]$this->other = Zend_Registry::get('Other');[/b]
    }

ценности от подобного кодинга - ноль. Ибо на практике все выльется в громоздкую конструкцию base-контроллеров.

Поэтому я ЗА компонентный подход.

Есть эффективное и элегантное решение этой проблемы - попросить Phemto подгрузить все параметры автоматом. И с тетированием все ок.

Изначально у нас так:
public function __construct(){}

Как только нужен main, делаем так:
public function __construct(IObjectMain $main){
$this->mai=$main;
}

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

Нужно лишь указать Phemto, что ему сделать, если контроллер ожидает некий объект аргументом: создать класс (новый) или использовать единственный общий. После ознакомления с Phemto всякие бояны с ленивой инициализацией и базовыми классами не нужны.

IObjectMain - необходимо каждому типу параметров создать интерфейс. Все же Phemto не телепат .-)

Как раз недели 2 на хабре выложили перевод этой библиотечки на русский.