Каков канонический способ хранения «глобальной» информации в Layout and Controller?

Question

У меня есть приложение на основе Zend Framework, которому требуется множество информации, доступной на нескольких контроллерах и в одной глобальной компоновке.

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

Я не хочу наследовать от какого-то базового контроллера.Мои мысли уходят в сторону Action Helpers или Plugins.Я мог бы хранить всю информацию, которая мне нужна, в макете и считывать ее из представления / макета в контроллерах, которые нуждаются в этой информации.Но опять же, я не нахожу это решение очень элегантным.

Есть какие-нибудь мысли или намеки, как это сделать чистым способом?

Answer 1

Для данных, которые необходимо внедрить в общую область макета, но к которым нет доступа в действии / скрипте вида (боковая панель; ссылки аутентификации, такие как вход, выход из системы, регистрация, профиль и т. Д.), Я бы, вероятно, использовал плагин фронт-контроллера.

Однако, если вам нужны эти данные только внутри некоторых действий контроллера / скриптов вида, тогда Я бы пошел с помощниками действий с хуком preDispatch(), который вычисляет / хранит ваши данные. Убедитесь, что вы зарегистрировали / создали экземпляр этого помощника действий при начальной загрузке, чтобы он существовал при последующем срабатывании сигнала preDispatch().

Тогда в вашем контроллере тяжелая работа уже выполнена: извлеките данные из помощника действий и используйте их в действии или передайте их в ваши скрипты вида.

Просто мысли вслух ...

Answer 2

Похоже, использование Реестра - это хороший подход для того, что вы хотите.

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

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