Создание простого доступа к ресурсам из ZF контроллера

[YaroslavVorozhko]

Небольшой оффтопик.
Как сохранить отступы в статье?
Весь код помечен тегом «code», но отступы не сохранились, отсюда код получился практически не читаемый.

[TuiKiken]

Пользуйтесь подсветкой

[serkys]

Используйте Source Code Highlighter

[YaroslavVorozhko]

Спасибо TuiKiken и serkys за совет с подсветкой кода.

[YaroslavVorozhko]

И еще один вопрос по офрмлению.
Хотел опубликовать топик как перевод, но ссылка на создание перевода в моем акк. скрыта.
Кто может сказать почему?
Есть только ссылка «опубликовать топик», раньше можно было создать перевод, ссылку или топик.

[bondbig]

всё так просто…

[YaroslavVorozhko]

Это сарказм такой?
Если, что то непонятно спросите, я лично отвечу на все ваши вопросы по статье.

[bondbig]

Что такое ZF контроллер?

[YaroslavVorozhko]

Читаем про паттерн MVC ru.wikipedia.org/wiki/Model-View-Controller.
И про Zend Controller в частности framework.zend.com/manual/en/zend.controller.html.
Вообще вопрос считаю странным, если вы занимаетесь программирование веб сайтов, а тем более интересуетесь ZF.
MVC «практически всегда» является основой каждого веб проекта, и не только веб.

[bondbig]

нет, я не занимаюсь программированием. Совсем. Никаким.
По названию топика показалось, что речь про железку идет какую-то.

[Yeah]

Одно только непонятно, зачем фигачить модель во view? Может, нужно передавать что-то конкретное?
Да, я знаю, что есть такая штука, как толстая модель, но..! При создании сайтов а-ля CMS может понадобиться кастомизация шаблонов пользователем и в этом случае он теоретически получает доступ к БД из шаблона.

[YaroslavVorozhko]

Контроллер получает доступ к моделям, не view.
Это не толстый контролер, все зависит о того как ваши модели организованы, это как один из вариантов.
Контроллеру не всегда надо знать какие ресурсы будут испльзованы в модели, но иногда общий ресурс требуется в спецефической модели, которая не наследует указатель на ресурс, например navigation ничего не знает о «DB» ресурсе, пока мы сами не скажем ей откуда его взять, вот тут и пригодится доступ к ресурсам из контроллера приложений.

[Yeah]

Да, но в коде стоит такое:

    $model = $this->getModel();
    $model->setDbAdapter($this->db);
    $this->view->assign(
      'model'   => $this->model,
      'navigation' => $this->navigation,
    );

То есть во view передана model. Если это просто для примера, тогда ладно, но если это рабочий код, то, на мой взгляд, это плохо.

[Kupyc]

На мой взгляд это плохая практика. Композиция классов — хорошо, ладно. Изменение контекста объекта — в большинстве случаев очень плохо. Наследник Zend_Controller_Action аля Base_Controller_Action с магическим методом __get() делегирующим обращения определенного вида к Zend_Controller_Action::getInvokeArg('bootstrap')::getResource() и всего делов — имеем нужное представление ресурсов без переопределения контекста. А то не дай бог их еще вылавливать.

[chEbba]

losohome.wordpress.com/2010/01/22/integrating-symfony-dependency-injection-service-container-with-zend-framework/
А вот более правильный порыв (что касается инъекции в контроллеры), со своими недостатками, конечно, но все же…

[alxsad]

1. зачем переписывать (унаследовываться) класс Zend_Controller_Action, если для этого созданы плагины и хелперы?
2. как писал человек выше, лучше использовать Zend_Controller_Action::getInvokeArg('bootstrap')::getResource()

[YaroslavVorozhko]

1. Zend_Controller_Action не переписывается, все сделано в виде Action Helper
2. Чем это Zend_Controller_Action::getInvokeArg('bootstrap')::getResource('db), лучше этого $this->db?

[alxsad]

1. сорри, я не заметил, но примите к сведению=)
2. сравните объем вашего кода и моего (не проверял на работоспособность, но главное суть)

helper
— $bootstrap = $this->getFrontController()->getParam('bootstrap');
if ($bootstrap->hasResource($resource)) {
throw new Zend_Exception('Resource not found.');
}
return $bootstrap->getResource($name);

action
— $db = $this->_helper->resource('db');
$db->getConfig();

или

$this->_helper->resource('db')->getConfig();

Если следовать вашей логике $this->db (минимализм кода), то лучше вообще создать статический класс и юзать так
Core::get('db') в любом месте.

Извиняюсь за критику, это мое личное мнение и я никому ничего не навязываю=)

[YaroslavVorozhko]

Описанный мною хелпер поддерживает зависимости контроллера к ресурсам, через переменную $_dependencies,
public $dependencies = array(
'db',
'layout',
'navigation',
);

Т.е. он загрузит те ресурсы, которые контроллер будет использовать.

А, также поддерживает возможность загрузить некоторые ресурсы для всех контроллеров, указава их в bootstrap классе:
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initResourceInjector()
{
Zend_Controller_Action_HelperBroker::addHelper(
new My_ResourceInjector(array('db','navigation'));
);
}
}


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

Вместо Core::get('db'), можно использовать Zend_Register::get('db') предварительно положив ссылку на $db в регистр.