В продолжение цикла постов по фреймворку Kohana задену вопрос, который довольно быстро встаёт перед разработчиками, а именно ограничение стандартного URI.

Например пишете вы простой сайт-визитку. В нем будет-то всего 5-7 страниц. Первое что приходит в голову – создать контроллер (например article), в котором написать функцию (например get), которая в качестве аргумента будет получать ID статьи и отображать её.

В итоге полный URL статей будет выглядеть примерно так:

http://мойсайт/article/get/1

http://мойсайт/article/get/2

…

http://мойсайт/article/get/N

Понятно что вместо числового ID можно указывать некий строковый идентификатор, но это не так важно

Но ведь у сайта страниц всего ничего, и все они вызываются этим контроллером. Складывается ощущение, что указание контроллера и метода – лишнее. Хочется видеть URL по-проще например:

http://мойсайт/about

http://мойсайт/contacts

http://мойсайт/news

http://мойсайт/product

И так далее. Можно конечно тупо написать отдельный контроллер под каждый случай. Можно даже каждый такой контроллер наслодовать от некоего главного, но это всё равно приводит к созданию лишних сущностей, а это плохо.

Так вот! Такая задача в Kohana стандартно решается с помощью роутинга. Для начала мы должны на бумаге чётко расписать, какие переадресации мы хотим.

Например мы хотим, чтобы при вызове URL http://мойсайт/about вызывался http://мойсайт/article/get/1.

Реализация в Kohana3

Заходим в application/bootstrap.php, и добавляем свой роутинг:

// Мои роуты

Route::set('my_route_about', 'about')

->defaults(array( 'controller' => 'article',

'action' => 'get',

'id' => '1',

));

где:

• my_route_about – это название роутинга,
• about – URI до роутинга
• article, get, 1 – контроллер, функция и аргумент после роутинга.

Это простейшее правило для роутинга. Таких правил можно добавить несколько, по одному для каждого случая.

Правила могут быть сложнее, могут содержать регулярные выражения. Правила могут охватывать больше или меньше вариантов URI. Кстати правила могут пересекаться, и то правило актуальнее, которое окажется ближе к началу. Поэтому рекомендуется более частные правила ставить в начале, а более общие ближе к концу. Говоря о нашем примере нужно как раз заметить, что правило default, нужно поставить после нашего правила.