Как стать автором
Обновить

Комментарии 17

Отличная статья. После нее у меня не осталось вопросов по поводу роутинга в kohana.
Новый роутинг стал мощнее, но менее наглядный. Было бы лучше, если бы они оставили возможность использовать старый роутер для простых роутов, но, при этом, для сложных дали использовать новый.
А есть ли смысл? Зная как писать по новому, писать по старому.
Позволю себе несколько небольших дополнений:

1. Роутинг может быть откорректирован не только в bootstrap.php, но в принципе в любом месте приложения. В первую очередь это касается подключаемых модулей. Как мы помним, при подключении модуля ядро выполняет скрипт init.php, если он существует в папке модуля. ИМХО, тут самое место для специфических роутов данного модуля. Кроме того, модули подключаются раньше, чем выполняется дополнение дефолтного роута, так что они не будут им перекрыты (в отличие от роутов, указанных где-нибудь в контроллере).
2. Если какие-то контроллеры или методы должны быть скрыты от вызова в качестве основного УРЛ (как правило, это скрипты виджетов), существует очень простой способ проверки:
if ($this->request === Request::instance())
{
// это вызов из браузера (или из CLI)
}
else
{
// нас вызывали через HMVC
}
Немного обескураживает количество человек, которым статья не понравилась, что для технической статьи редкость. Не могу не спросить, что не так?
Возможно дело в последней приписке? По крайней мере для меня :)
Хотя уверен, автор ничего плохого не имел ввиду. Надо было выразиться поконкретнее (можно еще исправить)
Спасибо. Очень полезно.
Но както фраза «Огромная просьба к знатокам украинского языка, воздержитесь. Все уже в курсе.» звучит не толерантно, я вот таки не воздержался и выразил автору благодарность.

А еще минусанул :P
я вот таки не воздержался
На сколько я вижу, воздержались. Эта приписка для тех, кому кроме набившего оскомину баяна сказать нечего.
Спасибо за статью и модуль. А почему от системных наследуются классы в папке classes/exrequest, а уже от них классы в корне classes — это какой-то принцип модульности? Ведь получается лишний пустой уровень, почему бы не наследоваться сразу?
Это сделано, чтобы в приложении осталась возможность наследоваться от Exrequest_Request и Exrequest_Route, тем самым добавив свою функциональность и оставляя функциональность модуля.
скажите, а как в примере 1 сделать так чтобы «wiget» не было чувствительным к регистру?
НЛО прилетело и опубликовало эту надпись здесь
Отличная статья, спасибо большое автору. Еще хочется :)
Спасибо, как раз то что я искал.

А я пытался предопределять роуты в bootstrap и указывать флаг inner
Спасибо, как раз помогло разобраться.
Я конечно понимаю что пинать трупы не очень хорошо, всё-таки 2,5 года уже прошло со дня публикации, но всё-таки возможно автор поможет разобраться:
Написал роутинг под свои задачи, вот только с тестированием параметров не понял. Имеем:
Route::set('catalog', 'catalog(/(/))')
->defaults(array(
'controller' => 'catalog',
'action' => 'index',
), array(
'catalog_id' => '\d{1,5}',
'good_id' => '\d{1,5}',
));
Что по идее должно происходить если параметры catalog_id и good_id не проходят проверку — \d{1,5}? Просто я эти данные впоследствии использую для sql запроса, и естественно всякой гадости не хотелось бы, а пока туда попадает всё что передам. Может быть неправильно написал роут? Не попалось мне примеров что то, где бы дополнительные параметры шли вместе с дефолтными, возможно я со скобочками/запятыми намудрил, по тому и не работает?
регулярки для параметров пишутся не в defaults, а внутри команды set вторым параметром
Ну да, наоборот, долго гуглил, но нашёл :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.