Как я мог настроить Zend_Tool для обеспечения моего собственного скелета/шаблона?

При необходимости вы можете расширить классы инструментов zend. Но я думаю, что лучше иметь, например, свой собственный класс Bootstrap в библиотеке и просто изменить сгенерированный класс Boostrap extends Zend_Application_Boostrap_Bootstrap до extends My_Bootstrap

Модули можно использовать для повторного использования кода на уровне проекта:

http://framework.zend.com/manual/en/zend.controller.modular.html

Если у вас есть новый проект, аналогичен по функциональности существующему, вы можете добавить новый модуль в существующий проект и включить / выключить определенные модули в файле application.ini. Инициализация, специфичная для модуля, может содержаться в их собственных Bootstraps.

Но это не совсем просто ...

Когда я пытался несколько месяцев назад, Zend_Tool имел проблемы с созданием структуры каталогов модуля, и мне пришлось ее создать рукой. Кроме того, некоторые функции, которые могут вам потребоваться (файлы конфигурации для конкретных модулей, объединенные определения навигации и / или определенные конфигурации развертывания), в настоящее время не встроены в Zend Framework и должны быть написаны.

Для моей установки у меня есть приложение. ini для каждого развертывания (application-foo.ini, application-bar.ini). Используя переменную среды (SetEnv APP_DEPLOYMENT foo), установленную в файле .htaccess, соответствующий ini-файл выбирается с помощью настраиваемой логики в начальной загрузке (index.php). Общая конфигурация модулей помещается в специфические для модуля файлы конфигурации, загружаемые через специальный подкласс Zend_Application_Resource_Modules.

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

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

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

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

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

Думаю, одним из решений было бы редактировать файлы в библиотеке / zend / Tool / Project / Context / Zf, которые, кажется, предоставляют содержимое / структуры, используемые для готового проекта.

Но это не похоже на правильное решение. Кроме того, в ходе текущего исследования я уже обнаружил, что инструмент (zf.bat или sh) сканирует все каталоги на php inculde_path на предмет «манифестов» и «поставщиков», которые, в свою очередь, обеспечивают функциональность инструмента.

Статья Zend_Tool for the Developer , написанная одним из разработчиков Zend, только что прояснила некоторые вещи.

Манифесты

могут использоваться для объединения и «загрузки» любого количества провайдеров.

Провайдеры

Провайдеры, в свою очередь, являются фактическими контейнерами для команд CLI, которые вы хотите использовать, и дизайн аналогичен дизайну «контроллер / действие». Вы можете вызвать метод (действие) определенного класса (контроллера) из командной строки, вызвав:

zf <method-name> <class-name>

, учитывая, что этот класс расширяет Zend_Tool_Project_Provider_Abstract

. Впоследствии я обнаружил, что манифест, который заставляет поставщиков, ответственных за настройку нестандартный макет находится в:

library \ Zend \ Tool \ Project \ Provider \ Manifest.php

В этом файле в инструмент возвращаются следующие Провайдеры: Я сообщу о проделанной работе!