Zend + action helpers + application.ini

Action helpers иногда бывают очень полезны. В частности как замена плагинов фронт-контроллера с возможностью доступа к экземпляру конкретного контроллера действия. Примеры конфигурирования оных я и приведу.

Zend_Db set timeout in app.ini

В интернете не нашёл примера для указания таймаута ресурса Db в app.ini.

resources.db.params.driver_options.2 = 6000  ;PDO::ATTR_TIMEOUT

А всё потому, что в ini файле не исполнить PDO::ATTR_TIMEOUT =(

Zend_Db_Select + UNION + COUNT

Часто бывает нужно вывести часть данных и показать сколько ещё осталось. Сделать это можно разными способами, в данном случае я использую 2 отдельных запроса.
Весело становится когда запрос на выборку данных у нас составляется UNION-ами, к которому простой COUNT(*) не применить толком =)

Нашёл лаконичное решение через пагинатор.

Настройка VDS под dseye.ru

Решил переехать на более производительный тариф и заодно записать все типовые шаги в настройке (постоянно что нибудь да забуду).

Описание краткое, просто чтобы не забыть.

Zend_Paginator + Cache (memcached)

Столкнулся с проблемой при попытке прикрутить нативное кеширование к пагинатору (DbTableSelect адаптер)

бутстрап (производим кеш и скармливаем пагинатору)

Copy Source | Copy HTML

1. $backendOptions = array(
2.             'servers' => array( array(
3.                     'host' => '127.0.0.1',
4.                     'port' => (APPLICATION_ENV == 'production') ? 12245 : 11211,
5.                     'persistent' => true,
6.                     'weight' => 1,
7.                     'timeout' => 10,
8.                     'retry_interval' => 15,
9.                     'status' => true,
10.                     'failure_callback' => null ) ) );
11.  
12.         $frontendOptions = array(
13.             'lifetime' => 3600
14.             'automatic_serialization' => true,
15.             'caching' => (APPLICATION_ENV == 'production') ? true : true,
16.             'cache_id_prefix' => 'dseyeUP_',
17.             'ignore_user_abort' => true );
18.  
19.         $cache = Zend_Cache::factory(
20.                         'Core',
21.                         'Memcached',
22.                         $frontendOptions,
23.                         $backendOptions);
24.         Zend_Registry::set('upCoreMem', $cache);
25.  
26.         Zend_Paginator::setCache($cache);
27.  

контроллер

Copy Source | Copy HTML

1. $count = $this->_worlds->getPlayersCount($this->idW);
2. $this->view->paginator = $paginator = $this->_players->listWorldPlayers($this->idW, $page, $count);

По всем мануалам всё должно работать, но нет:
во первых ZFDebug показывает лишний коннект к БД перед запросом данных пагинатора
во вторых этот запрос не кешируется никогда

Долго гуглил и копал сорцы, но как то безуспешно =(

Нашёл пару багов, где у людей файловый кеш пагинатора не работал при включенном профилировании через фаербаг, но показалось что проблема не та.

Версия 1.11.0, но и на продакшене 1.11.3 тоже самое.

Сам кеш разумеется работает нормально, без проблем подцепился к метаданным DbTable, да и ручками много где используется =)

Как временно решение прикрутил ручками кеширование этого запроса по составному ключу из параметров.

Скрытая фишечка хeлпера FormRadio

Случайно наткнулся в сорцах ZF на возможность задавать атрибуты лейбла у радиобатонов.
Делается посредством конкатенации строки "label_" к имени атрибута.

Например:

Copy Source | Copy HTML

1. $this->formRadio('filter_alliance_mod',
2.                   isset($this->searchProp->filterAllianceMod) ? $this->searchProp->filterAllianceMod : 'only',
3.                   array('label_class' => 'text-top'),
4.                   array('only' => 'только', 'not' => 'исключая'),
5.                   ' ');

Стандартный роутер ZF или "будь бдителен!"

В zf, как известно, существует стандартный роутер по имени "default". Но есть и возможность описывать свои "человекоподобные" урлы.

Итак:
Есть пачка роутеров с параметрами. Параметров много, в роутерах задаются дефолтные значения и регулярки для валидации. Казалось бы - в контроллере эти переменные проверять ненадо, ведь если человек дошёл до контроллера, значит все проверки роутера выполнились. И тут (ВНЕЗАПНО!) я вспоминаю про стандартный роутер, без всех этих проверок.
Само собой ничего критичного там нет, да и prepared state дают защиту от SQL inject, но возможность вывести сразу все данные на одной странице (пагинация с изменяемым количеством итемов на странице) тоже может доставить хлопот.

Собственно вопрос: можно ли как то запретить переходить по стандартному роутеру для действий, к которым прописан кастомный роутер?

Доку пролистал вдоль и поперёк. Что нарыл:
1.Можно убить стандартный роутер вообще (ну или заменить на заведомо левый). Но этот вариант заставляет писать роутеры для всех страниц
2.Можно в критичных действиях проверять ($this->getFrontController()->getRouter()->getCurrentRouteName() == 'default' ). Достаточно гибкое решение, но генерирует слишком много повторного кода.
3. Зашить предыдущую проверку в плагин фронт контроллера и сочинить конфиг (для определения критичных действий). Тут уже можно разгуляться, но всё равно это смотрится костылём.