Pull to refresh

Comments 42

Хочу добавить что очень удобно роутинг хранить в отдельном ini файле. К примеру:
routes.admin-login.route = "/admin/login"
routes.admin-login.defaults.controller = "index"
routes.admin-login.defaults.action = "login"

И сетить:
$front = Zend_Controller_Front::getInstance();
$router = $front->getRouter();
$config = new Zend_Config_Ini(APPLICATION_PATH . '/configs/routes.ini', 'production');
$router->addConfig($config,'routes');
А еще полезнее хранить в несокльких файлах, у меня в application/configs есть папка routes и в ней по-модульно хранятся ini-файлы роутов (routes/%modulename%.ini), спасает от большого кол-ва роутов.
Использовать много файлов конфигов надо тогда как минимум с кэшированием в памяти, иначе потеря в производительности обеспечена.
Лучше тогда хранить в одном всё application.ini файле или module.ini в зависимости от структуры приложения, там всё довольно таки структурировано. Добавляем комментарии через; и можно потом быстро разобраться что к чему.
Так и есть, xcache-ом кешируются конфиги
А почему нельзя в основном это хранить и больше никакого php кода не писать для подключения других конфигов?
Можно и в 'application.ini' положить все. Но лично мне приятней когда разделен конфиг приложения, роутинга и кеша и все конфиги кешируються. Тут каждый делает кому как удобней.
А я никогда не понимал зачем использовать ini-файл для роутинга. В routes.php И синтаксис привычнее, да и вообще объём меньше получается. И более понятны пути, имхо.
А еще удобней хранить роуты в yaml/xml файлах.
Написать свой ресурс, кот парсит yaml/xml файлы и добавляет роуты в Zend_Controller_Router_Rewrite (лучше всего проюзать Zend_Application_Resource_Router, например унаследовавшись от него).
Не забудем, что этот объект можно хранить в кэше и сбрасывать кэш по требованию из консоли.

И, да, в application.ini останется дописать лишь вызов нашего ресурса, например так:
resources.Router.config_dir = APPLICATION_PATH "/routes"

config_dir — директория, где лежать yaml/xml файлы с нашими роутами.

Пример xml файла:
<?xml version="1.0" encoding="utf-8"?>
<configdata>
    <routes>
        <AdminHelpIndex>
            <type>Zend_Controller_Router_Route</type>
            <route>admin/help.html</route>
            <defaults>
                <module>admin</module>
                <controller>help</controller>
                <action>index</action>
            </defaults>
        </AdminHelpIndex>
    </routes>
</configdata>
Смотрится еще страшнее чем ini-файл. Зачем всё усложнять, а?
Это не может смотреться страшнее, т.к. xml поддерживает вложенность напрямую.
Еще меньше кода — yaml

Строго говоря, можно и php кодом в виде вложенных массивов оформить — главное разделить данные и код.
Ну, по-моему, плюсов от того подхода меньше, чем минусов.
Такого подхода по сравнению с какаим?
Мне кажется по сравнению с любым. Хотя бы исходя из времени на парсинг.
Кэш это круто, да) Но я вообще не люблю подходы, которые в итоге сводятся к стандартным, но требуют «допиливания»
На хабре была хорошая статья по производительности конфигов. ini-файлы парсятся быстрее всех.
Там было без учета кеша, с кешированием разницы, можно считать, нет.
а кеш с конфигами как храните?
Можно хранить сериализованный объект Zend_Controller_Router_Rewrite

Бэкенд любой на выбор: file, apc, etc
Ну в моем случае в память (xcahce) загоняется сериализированный объект Zend_Config_Ini, но на всё воля аллаха программиста, кешировать можно чем угодно:)
Не столь важно как быстро парсится тот или иной конфиг, кэширование все решает.
Еще удобнее хранить описание маршрутов в базе данных
Не всегда, если это что-то типа CMS, где нужна динамическая маршрутизация то да, иначе смысла нет, удобнее в файлах.
Если второй пример — просто демонстрация использования Zend_Registry, то еще ладно. А вообще есть $this->getInvokeArg('bootstrap')->getOption('constants') для этого, зачем для этого два раза открывать конфиг
Это из учебников по зенду, они все так делают :)))
а потом рассказывают что зенд тормозит и синтаксис многословный
$page = $this->getRequest()->getParam('page');

Можно ещё через хелпер, так:
$page = $this->_getParam('page', 'default');

второй параметр устанавливает значение по умолчанию, если оно не задано.
Согласен с вами, через хелпер намного проще, всегда так и делаю.
По поводу роутинга — ничего нового, всё это уже есть в мануале.

По поводу констант — не смотрел на эту тему мануалы, т.к не юзал никогда, но спасибо за описание интересной возможности, буду использовать
Роутер для субдоменов:
$front = Zend_Controller_Front::getInstance();
$router = $front->getRouter();
$hostnameRoute = new Zend_Controller_Router_Route_Hostname(
':username.site.ru',
array(
'module' => 'users',
'controller' => 'show',
'action' => 'index'
)
);
$plainPathRoute = new Zend_Controller_Router_Route_Static('');
$router->addRoute('users', $hostnameRoute->chain($plainPathRoute));
ещё .htaccess или конфиг для nginx добавить не мешало бы, сам по себе субдоменный роутинг не будет работать :)
htaccess стандартный, но в некоторых случая, подозреваю, что-то такое:
RewriteRule ^(.*)$ %{HTTP_HOST}/$1
RewriteRule ^(.*)\.mysite\.ru(.*) /subdomains/$1$2

Для nginx — не подскажу, а вот под апач:
ServerAlias *.domen.com
Просто, многие хостеры не дают ServerAlias прописывать через htaccess.
Спасибо за дополнение, жаль плюсануть не могу
Никакие хостеры не дают прописывать ServerAlias в .htaccess. Потому что это директива только
для блока VirtualHost.
UFO just landed and posted this here
А может всё таки не стоит сравнивать фреймворки для разных языков программирования? Кому то PHP нравится больше, чем Ruby. Либо кто-то не знает Ruby вовсе.
UFO just landed and posted this here
Ну тут да, не спорю, Ruby более компактен. Но, всё таки большинство проектов, по прежнему, пишут на PHP и никуда от этого не деться
Маршрутизация в Zend Framework — это очень обширная тема, а тут — два абзаца. Жаль, что автор скачет по верхам. Было бы неплохо рассказать также о цепочках маршрутов, о таких частых применениях, как многоязычность, поддомены (уже есть в комментах)
Хотел уточнить. Вот тут вот:

[a href="<?php $this->url(array('page'=>'about'), 'test'); ?>"]О проекте[/a]

не должно ли быть вместо «test» cлово «static» (применительно к примеру в статье)?
Проще всего держать роутинг в ресурсах конфига (дефолтный appplication.ini например) где он будет цепляться автоматически (без сета в контроллере/бутстраппере)
resources.router.routes.pages.type = «Zend_Controller_Router_Route_Regex»
resources.router.routes.pages.reverse = «pages/%s»
resources.router.routes.pages.route = «pages/(.*)»
resources.router.routes.pages.defaults.controller = Pages
resources.router.routes.pages.defaults.action = page
resources.router.routes.pages.map.1 = page
Sign up to leave a comment.

Articles