Ну, lazy loading еще никто не отменял. Если они боятся, что их же код вдруг что-то вытащит из сессии — Zend_Session_Namespace в помощь.
App_Controller_Action::sendJsonResponse() — это уж точно работа ContextSwitch.
И если уж вы связываетесь с автором, то всякие App_Route, App_Translate и т.д. было бы неплохо убрать подальше :)
В терминологии ZF понятия модуля фронт-контроллера нет (есть помощники и плагины). Но это и неважно, суть в том, что такое разделение на «модули» никакого практического удобства не несет, а «модуль» api появился лишь от незнания ContextSwitch.
Не знаю, что такое модули фронт контроллера, но у ребят модули используются, чтобы разделить backend (админка) и frontend. + «модуль» api, который просто выводит todo-список в xml для экспорта. Модульность от этого не появилась.
Модульность это что-то типа: jazzslider.wordpress.com/2009/06/15/a-reusable-zend-framework-content-module/
На DevZone лежит аналогичная статья уже давно. В обеих статьях отсутствует информация, как научить Doctrine понимать при генерации модели рекомендуемую модульную структуру ZF. Например, сейчас все модели сваливаются в одну папку — MODELS_PATH, а хотелось бы, чтобы модель появлялась в папке соответствующего модуля. Кто-то такое реализовывал?
Вы говорите как делать, но не говорите почему выбрали именно этот способ. Такие Инструкции, на мой взгляд, понятны только тем, кто это все уже давно знает и применяет на практике.
App_Controller_Action::sendJsonResponse() — это уж точно работа ContextSwitch.
И если уж вы связываетесь с автором, то всякие App_Route, App_Translate и т.д. было бы неплохо убрать подальше :)
Модульность это что-то типа: jazzslider.wordpress.com/2009/06/15/a-reusable-zend-framework-content-module/