Comments 48
UFO just landed and posted this here
В решениях от фреймворках массив правил создаётся динамически, в моём решении массив правил создаётся лишь 1 раз при парсинге, после чего используется сериализованные данные.
Вроде везде можно закешировать ;)
В моё решение тоже несложно будет встроить кэш, что не уступит в производительности решений от фреймворков.
В первую очередь писал данный класс, для варианта без использования кэша памяти.
В первую очередь писал данный класс, для варианта без использования кэша памяти.
На сколько я вижу, у вас и так используется кеш — файл с сериализованными данными. Да и не важно где его хранить — в файле или памяти, с точки зрения бизнес логики. Хоть делать var_export в файл. Вот мы и говорим, что закешировать вроде то все можно (помимо Вашего примера).
Не кажется ли Вам, что на производительность роутера нужно смотреть не в самом начале? А если и смотрите, то нужен ли он вообще? Считаю, что сам контроллер будет требовать гораздо больше ресурсов, чем роутер. Так что роутер было бы хорошо написать что бы было быстро, понятно и приятно его использовать.
Не кажется ли Вам, что на производительность роутера нужно смотреть не в самом начале? А если и смотрите, то нужен ли он вообще? Считаю, что сам контроллер будет требовать гораздо больше ресурсов, чем роутер. Так что роутер было бы хорошо написать что бы было быстро, понятно и приятно его использовать.
в symfony2 нет.
А в чем преимущество? Как по мне, так удобнее и читабельнее править именно что-то вида:
$route->addRule(
'/news/{id}/',
array(
'controler' = 'news',
'action' = 'showOne'
)
);
Простите, повздорил с парсером:
$route->addRule(
'/news/{id}/',
array(
'controler' = 'news',
'action' = 'showOne'
)
);Именно на такой вариант я хотел перейти изначально, мне же он не подошёл по следующим причинам:
1. Хотелось хранить правила роутинга в 1 файле и чтобы вид был стандартизирован, лично по-моим критерями php-код выглядит для настроек неудачно
2. Людям которые будут работать с кодом в дальнейшем (в том числе не программистам), будет проще просмотреть файл конфигов в xml
3. Гораздо лучше видно дерево правил, пример:
1. Хотелось хранить правила роутинга в 1 файле и чтобы вид был стандартизирован, лично по-моим критерями php-код выглядит для настроек неудачно
2. Людям которые будут работать с кодом в дальнейшем (в том числе не программистам), будет проще просмотреть файл конфигов в xml
3. Гораздо лучше видно дерево правил, пример:
<route match="user" controller="user" action="list">
<route controller="user" action="user" match="id{user_id|num}">
<route match="comments" controller="user" action="comments" />
<route match="wall" controller="user" action="wall" />
</route>
<route controller="user" action="user" match="{login}">
<route match="comments" controller="user" action="comments" />
<route match="wall" controller="user" action="wall" />
</route>
</route>
Не программистам может потребоваться влезать в настройки правил роутинга? :)
Вы рассматриваете крупные компании, иногда сайт делаю всего пару человек и не всегда оба — программисты.
Нечего не программистам делать сайты. Непонятно каким образм не-программисты будут лучше читать XML, нежели правила прописанные в исходнике.
> 1. Хотелось хранить правила роутинга в 1 файле и чтобы вид был стандартизирован
Вы можете хранить правила роутинга в одном php-файле, а без стандартизации не обойдется в принципе.
> 2. Людям которые будут работать с кодом в дальнейшем (в том числе не программистам), будет проще просмотреть файл конфигов в xml
Ваш XML-конфиг в 3 раза более нагроможденный, чем правила роутинга в PHP, не думаю, что не-программистам в нем легче будет разобраться.
> 3. Гораздо лучше видно дерево правил
В XML видно дерево правил? Кому? Операторам матрицы? Уверяю вас, человек не-программист (а вы под этих людей затачиваете свой файл-конфиг роутинга), никакого дерева там не видит.
Если вы ищите решение для не-программистов, сделайте админку с удобным редактированием правил роутинга.
> 1. Хотелось хранить правила роутинга в 1 файле и чтобы вид был стандартизирован
Вы можете хранить правила роутинга в одном php-файле, а без стандартизации не обойдется в принципе.
> 2. Людям которые будут работать с кодом в дальнейшем (в том числе не программистам), будет проще просмотреть файл конфигов в xml
Ваш XML-конфиг в 3 раза более нагроможденный, чем правила роутинга в PHP, не думаю, что не-программистам в нем легче будет разобраться.
> 3. Гораздо лучше видно дерево правил
В XML видно дерево правил? Кому? Операторам матрицы? Уверяю вас, человек не-программист (а вы под этих людей затачиваете свой файл-конфиг роутинга), никакого дерева там не видит.
Если вы ищите решение для не-программистов, сделайте админку с удобным редактированием правил роутинга.
Не убедили, вижу только лишние заморочки. Хотя это дело вкуса — кому xml, кому массивы)
Хотелось хранить правила роутинга в 1 файле и чтобы вид был стандартизирован
Вы наверно шутите? Храниние всех ройтингов в одном файле приведет к нечитаемому монолиту.
Мне же хотелось большей гибкости в настройке роутинга и в конечном итоге решил использовать XML для хранения правил, а после парсинга файла и создания массива правил сериализовывать его в файл (в дальнейшем используя его для получения настроек)
Подскажите, в дальнейшем — значит на протяжении одного запроса, либо это кэш для последующих запросов? Если это кэш, то как вы его обновляйте?
Гораздо лучше видно дерево правил
Объясните про дерево правил, не очень понял.
>Объясните про дерево правил, не очень понял.
<page>
<subpage>
</page>
Так это роутинг или навигация? Зачем дерево?
Это роутинг,
а дерево затем, что subpage может вызывать совершенно другой контроллер, нежели page/
а дерево затем, что subpage может вызывать совершенно другой контроллер, нежели page/
Соответственно в случае, если совпадения по правилам роутинга найдены не будут, вернётся 404 ошибка, в случае пустого урл — его index значение
Я правильно понимаю, что дерево нужно ТОЛЬКО для этого?
нет, боюсь вы не видите плюсов деревьев.
Объясните пожалуйста
На основе примера:
Если перейти по урлу /user/ — отобразится список пользователей
/user/testik/ — отобразится информация об этом пользователе
/user/testik/comments/ — отобразятся его комментарии.
А в XML видно, кто чьим потомком является , лично мне удобно использовать этот плюс, но я никого не заставляю переходить на это решение.
<root>
<routes>
<route match="user" controller="user" action="list">
<route controller="user" action="user" match="{login}">
<route match="comments" controller="user" action="comments" />
<route match="wall" controller="user" action="wall" />
</route>
</route>
</routes>
</root>
Если перейти по урлу /user/ — отобразится список пользователей
/user/testik/ — отобразится информация об этом пользователе
/user/testik/comments/ — отобразятся его комментарии.
А в XML видно, кто чьим потомком является , лично мне удобно использовать этот плюс, но я никого не заставляю переходить на это решение.
Ясно вы вкладывайте роуты друго в друга, тем самым сокращая запись правила матчинга.
Ответьте, пожалуйста, также на 2 вопроса из моего первого комментария
Ответьте, пожалуйста, также на 2 вопроса из моего первого комментария
интересует как будет выглядеть правило в указанном выше примере, если у меня в контроллере юзера добавляется экшен profile котороый должен отобразить инфу залогиненого пользователя и следовательно адрес получается вида
/user/profile
/user/profile
>Вы наверно шутите? Храниние всех ройтингов в одном файле приведет к нечитаемому монолиту.
Если хранить роутинг в разных страницах, при больших объёмах можно просто забыть где и что лежит, свой вариант считаю вполне удобным.
>Подскажите, в дальнейшем — значит на протяжении одного запроса, либо это кэш для последующих запросов? Если это кэш, то как вы его обновляйте?
В дальнейшем, при последующих запросах разумеется, обновляется путём удаление файла *.dat
Роутинг обновляется очень редко, не хотел каждый раз проверять время изменения файла.
Если хранить роутинг в разных страницах, при больших объёмах можно просто забыть где и что лежит, свой вариант считаю вполне удобным.
>Подскажите, в дальнейшем — значит на протяжении одного запроса, либо это кэш для последующих запросов? Если это кэш, то как вы его обновляйте?
В дальнейшем, при последующих запросах разумеется, обновляется путём удаление файла *.dat
Роутинг обновляется очень редко, не хотел каждый раз проверять время изменения файла.
Если хранить роутинг в разных страницах, при больших объёмах можно просто забыть где и что лежит, свой вариант считаю вполне удобным.
Когда кол-во роутов возрастет до 500, вам по-прежнему будет удобно?
В дальнейшем, при последующих запросах разумеется, обновляется путём удаление файла *.dat
Роутинг обновляется очень редко, не хотел каждый раз проверять время изменения файла.
Вы моежете быть уверены, что ни один программист из команды, работающий над проектом никогда не забудет обновить файл *.dat?
В тему «не программистам будет проще» — ооочень спорно.
Одно время работал как раз в такой ситуации, и моим «не программистам» XML было очень сложно понять (по сравнению, с тем же json и даже рнр).
Одно время работал как раз в такой ситуации, и моим «не программистам» XML было очень сложно понять (по сравнению, с тем же json и даже рнр).
Еще один, достаточно типичный, зато родной, роутинг на PHP с использованием XML как хранилища и сериализованного массива в файле в качестве «кэша».
Не в обиду, но я не нашел ничего выдающегося.
Кстати, есть предположение, что буферизация в .php файле через var_export() окажется более по вкусу оп-кэшеру.
Не в обиду, но я не нашел ничего выдающегося.
Кстати, есть предположение, что буферизация в .php файле через var_export() окажется более по вкусу оп-кэшеру.
>Не в обиду, но я не нашел ничего выдающегося.
«Дьявол в мелочах»
>Кстати, есть предположение, что буферизация в .php файле через var_export() окажется более по вкусу оп-кэшеру
Есть такая вероятность, чуть позже проверю
«Дьявол в мелочах»
>Кстати, есть предположение, что буферизация в .php файле через var_export() окажется более по вкусу оп-кэшеру
Есть такая вероятность, чуть позже проверю
Тоже так подумал, и да, можно задавать роутинг вообще из пхп-массива и не придется ничего парсить, ну и во всех вменямых фреймворках сей файл все равно кешится в пхп-массив, да и более интересгая частт это матч роутинга, а не то, в каком виде его хранить.
В Symfony 2 то же самое, или я что-то путаю?
«Изобрел» роутинг, напиши об это на хабре.
По итогу ничего нового, нет никаких преимуществ вашего роутинга перед другими. Да и кеширование довольно странное, наряду с использованием xml.
По итогу ничего нового, нет никаких преимуществ вашего роутинга перед другими. Да и кеширование довольно странное, наряду с использованием xml.
Быстрый? Вы бы тогда сравнили скорость работы вашего варианта и хотя бы $route->addRule(), чтобы не о сферической быстроте говорить. Мне кажется конкретные результаты показали бы, что отличия в скорости не очень существенны.
Можно ещё понять танцы с xml, если по какой-то причине у вас все конфиги в xml, в противном случае просто непонятно зачем это нужно.
Можно ещё понять танцы с xml, если по какой-то причине у вас все конфиги в xml, в противном случае просто непонятно зачем это нужно.
TROODON вариант хранения маршрутов в БД не рассматривался? А что если, например, необходимо будет разграничить права доступа пользователей к ресурсу в плоскости маршрутов (страниц с точки зрения пользователя)? Мне кажется, такие связи будет проще реализовать если хранить все в БД, или я ошибаюсь?
Разграничением прав должен заниматься контроллер, имхо.
С одной стороны да, с другой стороны — какой именно контроллер должен заниматься разграничением прав? :)
Если разграничения по страницам (маршрутам) достаточно, то на мой взгляд оптимальным будет разместить всю систему в одном контроллере, ослабив тем самым связи с другими контроллерами. В таком варианте это имеет непосредственное отношение к роутингу.
Если разграничения по страницам (маршрутам) достаточно, то на мой взгляд оптимальным будет разместить всю систему в одном контроллере, ослабив тем самым связи с другими контроллерами. В таком варианте это имеет непосредственное отношение к роутингу.
В случае ini-файлов (формата .htaccess — LIKE) роутер может выглядеть так:
/users/ users#index
; роутинг сразу на класс, метод определится из url
/users/ users#
/pages/ pages#index
/pages/about pages#about
/users/:id/comments commets#list_by_user
/users/ users#index
; роутинг сразу на класс, метод определится из url
/users/ users#
/pages/ pages#index
/pages/about pages#about
/users/:id/comments commets#list_by_user
UFO just landed and posted this here
А чем зендовский не устроил? Там и различные форматы (php, ini, xml, yaml), и свою стратегию добавить можно, и кеширование…
Всегда было интересно: чем не устраивает роутинг средствами .htaccess на dev, и nginx на продакшене?
Один файл это очень хорошо, но что будет в ситуации если этот, с вашего позволения, движок надо будет скопировать другому клиенту. А потом появится новый модуль в сайте третьего клиента и будет идея всем десяти его добавить? Роутинг для одного модуля прописывать всем? Не с проста спрашиваю, сталкивался.
Sign up to leave a comment.
Быстрый роутинг на PHP