Сразу оговорюсь - представленная реализация наверняка не самая лучшая и имеет множество изъянов, да и некоторые моменты у меня самого вызывают вопросы (просто когда понадобилось перенести все крон скрипты на зенд времени на детальное рассмотрение небыло совершенно). Поэтому буду рад всем фидбеками и замечаниям по коду =)
Итак, для начала нам понадобится аналог фронтендового index.php для всех cron-скриптов. Назовём его zfcli.php. Поскольку внешний доступ к нему нам важно ограничить - я кладу его внутрь привычного APPLICATION_PATH, рядом с Bootstrap.php.
Листинг zfcli.php
Copy Source | Copy HTML
- <?php
- define('APPLICATION_ENV','cli');
- define('APPLICATION_PATH', realpath(dirname(__FILE__)));
- define('ZEND_PATH', realpath(dirname(__FILE__) . '/../../Zend'));
- define('WWW_PATH', realpath(dirname(__FILE__) . '/../www') );
- set_include_path(implode(PATH_SEPARATOR, array(
- ZEND_PATH,
- get_include_path()
- )));
- // Zend_Application
- require_once 'Zend/Application.php';
- $application = new Zend_Application(
- APPLICATION_ENV,
- APPLICATION_PATH . '/configs/application.ini'
- );
- try
- {
- $opts = new Zend_Console_Getopt(
- array(
- 'help|h' => 'Displays this information.',
- 'action|a=s' => 'onlinestat | csv | scavenger',
- )
- );
- $opts->parse();
- }catch (Zend_Console_Getopt_Exception $e) {
- exit($e->getMessage() ."\n\n". $e->getUsageMessage());
- }
- if(isset($opts->h))
- exit($opts->getUsageMessage());
- require_once realpath(APPLICATION_PATH.'/lib/MyCliRouter.php');
- switch ($opts->a)
- {
- //сборщик мусора и ротатор статистики
- case 'scavenger':
- $request = new Zend_Controller_Request_Simple('scavenger','cli');
- break;
- //сбор статистики по онлайну
- case 'onlinestat':
- $request = new Zend_Controller_Request_Simple('onlinestat','cli');
- break;
- //обновление собственных csv
- case 'csv':
- $request = new Zend_Controller_Request_Simple('csv','cli');
- break;
- }
- if(!isset($request))
- exit('Запрос не составлен (Cli error)');
- $front = $application->getBootstrap()
- ->bootstrap('frontController')
- ->getResource('frontController');
- $front->setRequest($request)
- ->setResponse(new Zend_Controller_Response_Cli())
- ->setRouter(new MyCliRouter())
- ->throwExceptions(true);
- $application->bootstrap()
- ->run();
В целом код очень напоминает обычный фронтконтроллер зенда (index.php), за некоторыми необходимыми правками.
В самом начале константе APPLICATION_ENV присваивается значение cli. Это сделано для отделения всех настроек приложения, необходимых для cron скриптов, в отдельную секцию application.ini и просто для удобства.
Далее мы задаём настройки Zend_Console_Getopt и тут же пытаемся их распарсить, попутно обрабатывая ошибки. Подробно останавливаться на этой части я не буду, поскольку официальная документация по данному компоненту отвечает на большинство возникающих вопросов. Если в кратце - скрипт будет требовать один обязательный параметр --action (или -a для краткости) обозначающий имя запускаемого действия (onlinestat, csv или scavenger) нашего Cli контроллера (будет рассмотрен далее).
Если было запрошено одно из доступных действий создаётся объект одиночного запроса, представленного в зенде классом Zend_Controller_Request_Simple (тут снова посыл в доку =) ), и созданный объект указывается как входящий для фронтконтроллера.
С фронтконтроллером связано ещё несколько действий, который и вызывают больше всего вопросов:
- В качестве объекта ответа мы берём Zend_Controller_Response_Cli. Это отнюдь не обязательно для работы, но рекомендуется многими не глупыми людьми, поэтому я решил не удалять эту строку.
- В качестве роутера необходимо указать заглушку, в нашем случае это объект класса MyCliRouter (будет рассмотрен далее). Эта заглушка призвана реализовывать стандартный интерфейс роутера и отмалчиваться на все запросы, поскольку мы берём диспетчеризацию на себя.
Ну а дальше следует обычный бутстрап и запуск приложения.
Листинг MyCliRouter
Copy Source | Copy HTML
- <?php
- class MyCliRouter
- extends Zend_Controller_Router_Abstract
- implements Zend_Controller_Router_Interface
- {
- public function assemble($userParams, $name = null, $reset = false, $encode = true)
- {}
- public function route(Zend_Controller_Request_Abstract $dispatcher)
- {}
- }
Как видите, задача заглушки просто "глушить" запросы нескольких методов роутера.
Теперь рассмотрим упомянутый выше CliController. В целом это обычный контроллер зендовского приложения, отличается он разве что проверкой на доступ в Cli контексте (помните указанное в самом начале zfcli значение константы APPLICATION_ENV?).
Листинг CliController
Copy Source | Copy HTML
- <?php
- class CliController extends Zend_Controller_Action
- {
- public function init()
- {
- if ( APPLICATION_ENV != 'cli' )
- throw new Exception('Access denied');
- }
- public function scavengerAction()
- {
- echo "scavenger";
- }
- public function onlinestatAction()
- {
- echo "onlinestat";
- }
- public function csvAction()
- {
- echo "csv";
- }
- }
Вот и всё =) Теперь вы можете заполнить действия логикой своих cron-скриптов и использовать в них все плюшки зенда.
Несколько примеров использования:
Вывести мануал
php /var/www/dseye/app/zfcli.php -h
Запустить действие csv
php /var/www/dseye/app/zfcli.php -a csv
Тоже самое без кратких аргументов
php /var/www/dseye/app/zfcli.php --action=csv
PS: В данном посте я не привёл содержимое упомянутой секции Cli в нашем application.ini. Это сделано потому, что содержимое (да и само наличие) данной секции очень сильно зависит от используемых вами ресурсов. Могу только посоветовать не наследовать cli от production, а, если необходимо, наследовать оные от базовой секции. Ещё посоветую создать для Cli отдельный бутстрап, который и указать через application.ini.
Комментариев нет:
Отправить комментарий