MVC - карта маршрутизации

[AmdY]

Вот сравнивая кусок какахи из поста ТС и симфони, вы действительно думаете что 10 МБ это проблема? ТС просил пример, их набросали, если сможет сделать лучше-удобнее-быстрее - будет здорово, если будет хуже, то плевать на 10 метров. ТС ещё плавает в понимании того, что ему НАДО, плавает в понимании проблемы роутинга, так что сейчас лучше учиться на готовых решениях, прежде чем писать своё.

 

[ksnk]

Вот сравнивая кусок какахи из поста ТС и симфони, вы действительно думаете что 10 МБ это проблема?

Нет, конечно. это будет решать топикстартер когда и если дочитает посюда
Для меня это было бы проблемой. Когда меня заставили в админке использовать tinymice вместо niceditor я очень сильно сопротивлялся. Но речь не об этом.
Проблему я вижу в том, что на вопрос TC'а показать свои конфиги роутера откликнулся только я. Все остальные предпочли просто послать юзера глубоко-глубоко в мануал читать про незнакомую ему cms.

 

[Andkorol]

Проблему я вижу в том, что на вопрос TC'а показать свои конфиги роутера откликнулся только я.

Извините.

 

[hell0w0rd]

Рыцарь на белом коне! ТС попросил показать как усовершенствовать его вариант и почему его вариант не работает. Не работает он потому что видимо не правильно состовляет регулярки, а усовершенствовать - посмотреть существующие варианты. Из зависимостей компонент ничего вообще не тянет, только в случае если вам это действительно нужно.
Компонент роутинга весит 351кб из которых половина - тесты. Какое вообще значение имеет вес кода? По весу можно оценить качество? Оверхед от использования этого кода?
Почти все в симфони можно подменить (даже внутри компонента) наследуясь, или реализуя интерфейс - это чрезвычайно удобно.
Чтобы понять как это удобно использовать - посмотрите роутинг в silex, например.

С другой стороны с пол пинка понять код в компоненте роутинга симфони не получится, так что для начала можно например осилить slim - там банально меньше кода.

 

[AmdY]

ksnk
он просил примеры. ему их дали, там и примеры и решения, а твой пример с ругулярками только путает и отпугивает от роутинга, тем более не собедрит реализации и тем самым является бесполезным.

 

[fixxxer]

предлагаю банить тех, кто называет фреймворки cms

 

[ksnk]

fixxxer Постараюсь исправится

 

[fixxxer]

Да как угодно, начиная с тупого вызова нужного контроллера и экшена в колбэке. В «архитектуре» ТС я вижу только маппинг сегмента на список параметров непонятно чего (причем два ключа catalog с разными значениями слегка доставляют).

Ну можно простить, он же только начал. Усовершенствовать до чего-то вроде

[
   'catalog' => '/detail/{int:id}/{string:title}',
   'catalog.index' => '/index/{int:id}/{string:title}',
]

научиться компилировать в регулярки для поиска роута и строить урлы по controller+action - и уже нормально.

А вот это вот изобретение с вложенными колбэками - это switch ($action) в index.php только новомодно записанное. Отказать.
Роутинг должен быть декларативным, иначе обслуживание чего-то сложнее бложика превратится в ад.

С предложением посмотреть симфони согласен - но смотреть общую архитектуру, а не реализацию. Реализацию будет сложновато пока что, а написать свою, попроще, с оглядкой на симфони - хорошая задача, годная.

 

[AmdY]

А вот это вот изобретение с вложенными колбэками - это switch ($action) в index.php только новомодно записанное. Отказать.
Роутинг должен быть декларативным, иначе обслуживание чего-то сложнее бложика превратится в ад.

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

Router::add('/{controller}/{action?}', function($route) {
    (new $route->get('controller'))->{$route->get('action', 'index')}
});

Выносить это в бутстрап и там разруливать?

Router::add('/{controller}/{action?}', '\\Bootstrap\\ControllerAction');
Router::add('/{module}/{controller}/{action}', '\\Bootstrap\\ModuleControllerAction');

 

[ksnk]

Вот не знаю как быть с этими кэллбэками,..

А в чем глобальная польза построчной сборки конфига роутера в рантайме? В том, что модули можно свободно включать-выключать? Больше ни в чем?
Если да, то вероятно лучше собирать конфиг роутера на событии "включения модуля в систему". Он сбрасывает свои правила в общий конфиг, конфиг транслируется и это уже не надо будет делать на каждый чих сервера. Каждое такое правило помечается и при отключении модуля выкидывается с перетрансляцией конфига.
Останется только заменить колбяки на их "текстовое представление". Вероятно, будет разумно в сложных случаях завести статический метод у самого модуля и вызывать его.

 

[AmdY]

Если да, то вероятно лучше собирать конфиг роутера на событии "включения модуля в систему".

ага, это как с регулярками. была одна проблема, а сейчас становится две. в данном случаем нам придётся ещё отслеживать момент включения. момент выключения, перезагрузку роута другим модулем, ну и реализоваться саму жёсткую систему модулей.....
это никак не KISS

 

[ksnk]

Ну, вроде как экономия на кэшировании и трансляции, как бы на лицо. Есть за что бороться. Эффективность, разве, не стоит небольшого усложнения? Чтобы не заставлять разработчиков в аварийном порядке переписывать модули - нужно будет поддерживать обе возможности. останется "новая" схема и параллельно "старая" с колбяками и построчной сборкой. По большому счету изменений в модулях не так и много- новое событие в админке, возможно даже только одно, с очисткой конфига. Правила роутинга откочевывают в специальный метод.Так можно спокойно отладить схему без ледниковых периодов в разработке

Ну и в догонку еще "умный мысль". Натуральный коллбяк можно заменить на его строковое изображение. Второй параметр функции create_function. И кэшируется как строка и исполняется когда надо. Это, конечно, не тру-пхп5.4++, зато вполне себе тру-пхп. Разве что акселератор будет против...

 

[hell0w0rd]

если хочется экономить - можно писать без классов, а лучше сразу на плюсах/си)

 

[fixxxer]

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

Router::add('/{controller}/{action?}', function($route) {
    (new $route->get('controller'))->{$route->get('action', 'index')}
});

Выносить это в бутстрап и там разруливать?

Router::add('/{controller}/{action?}', '\\Bootstrap\\ControllerAction');
Router::add('/{module}/{controller}/{action}', '\\Bootstrap\\ModuleControllerAction');

А че так сложно?

$router = new Router($route_map);
$router->route($request);
///////////////////
route($request) {
    $route = $this->find($request->getUri());
    $controller = IOC::factory($route->controller);
    $controller->dispatch($route->action, $route->arguments);
}

 

[ksnk]

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