Хм, прикольно. Уже понятнее.

Насколько я понял, сам список маршрутов - это не просто адреса, а связки адресов с контроллерами и их методами, плюс, видимо, регулярки. Я правильно понимаю?
Но пока как-то не особо понятно как осуществляется такая привязка, ибо должна же быть динамика, иначе мы получим жесткую связку и далее все та же проблема со сменой имени контроллера.

Правильно. Можно привязать любой обработчик любому маршруту. Зависит, конечно, от конкретной реализации системы роутинга, коих хватает. Но задача сделать проект как можно более прозрачным, поэтому контроллеры чаще всего совпадают с элементами URL. Иногда и методы, но значительно реже.

Динамика восновном достигается разбиением на методы, например, по типу переданного параметра, в том числе и через регурярные выражения. Повторюсь, метод в URL указывается далеко не всегда. То есть ссылки типа

http://example.com/goods/231

где маска маршрута будет несложно догадаться какая. =) Что-нибудь вида /goods/{int} => goods->show($param)

А вот на поиск товаров: /goods/{string} => goods->search($param)

В целом, конечно, ты отчасти прав: подход не является панацеей. Но делает работу с проектом значительно удобнее. При грамотном составлении маршрутов, разделении на методы, правильном выделении элементов в динамику. Правильное значит не изменяющееся со временем. Действительно, метод search, скорее всего, при любых обстоятельсвах, будет принимать на вход строку, а не ID-шник. Хотя могут быть исключения, не будем фантазировать, сейчас главное принцип. =)

Есть еще разделение по HTTP методам. Как минимум везде присутствует деление на GET и POST, во всех роутерах что я видел. =) Тоже очень мощный инструмент разбивки по разным обработчикам.

В конце-концов, если нам предстоит исправить даже 100 строк в одном месте, это совсем не тоже самое, как в 100-а различных файлах - темплейтах. Где ссылки разбросаны по HTML, бывает в конструкциях логики отображения, да в каждом файле встречаются по несколько раз.

Ну может и не исключительно, я бы рассматривал имя роута, как своеобразную ссылку на объект. Или переменную в крайнем случае.

Немножко не так. Мы будем прогонять каким-то образом весь URL до тех пор, пока он не совпадет по маске (или точно), с одним из наших правил. А уж какой контроллер и метод будет с ним, с правилом, ассоциирован дело десятое. То есть нормальный роутер должен состоять из механизма парсинга как правил так и URL-ов, поиска совпадений URL с заданными роутами, и механизма вызова обработчика. Часто его называют диспетчером.

Another Reality, не стоит создавать свои роутеры, нет никакого смысла, их написано великое множество. Лучше посмотреть в сторону AltoRouter, он очень простой по реализации, но в то же время интересный и достаточно мощный. Причем вызовов обработчиков (диспетчера) в нем нет. Колбэки не считаются. =) Хорошее поле для велосипедов!

И да, регулярки в построении роутеров, мягко говоря, играют далеко не последнюю роль. Как и любых других кастомных механизмах парсинга.

Как раз парсером называется такой механизм. С элементами лексера. Если интересны методологические подходы, как это делается в серьезных проектах, стоит почитать про теорию создания языков программирования. Мозги прочищает прекрасно, не хуже паттернов ООП.

Ну вроде понятно.

Я хочу сделать исключительно ради хорошео понимания. Собственно данная тема появилась вследствие того, что я решил написать микро-фреймворк. Ясный пеерц, что я не пытаюсь сделать альтернативу Laravel, Symfony и так далее. Чисто ради практики и лучшего понимания.

Супер, полистаю!

Спасибо!

Я набросаю примитивный механизм роутинга с маршрутами и выложу сюда. Если тебя не затруднит, сможешь глянуть ? Хотелось бы по факту фидбек получить )

А зачем? Их тоже великое множество от Slim до перечисленных тобой. Не трать время, честное слово, не стоит оно того. Гораздо больше опыта получишь разбирая уже готовые решения от умных дядек.

Думаю каждый хороший программист прошел фазу "велорешений" но не все, оглядываясь назад, скажут, что потратили время с большой пользой. Я бы самому себе, вернувшись в прошлое, посоветовал поднажать на теорию, а не практику. И конечно же граздо больше времени уделить разбору чужих, в первую очередь признанных, решений. Велосипеды тоже нужны для тренировки мозгов, но маленькие и хитрые. Не такие:

http://alternathistory.com/files/users/use...0s28%20bike.jpg

Может это и верно. Я и сам думал над этим. Но часто вспоминаю фразу преподавателя: "Наши знания делятся на две группы, - понятые и пережитые. Просто понятые забудутся, пережитые - никогда!" И мой жизненный опыт подтвердил это.

В любом случае, я уже написал часть роутинга с маршрутами. Осталось сделать некоторые модификации и написать расширение к твигу чтобы ссылки делал правильные. По идее тоже не сложно. Так что выкладывать ничего не буду - нет смысла.

Что ты имеешь ввиду под "теорией" ? Алгоритмы, архитектуру ?

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

Абсолютно всё новое, что поможет стать более скиловым мастером в искусстве декомпозиции. Архитектурные вопросы при этом играют ключевую роль. Паттерны, антипаттерны, труды великих людей, таких как Роберт Мартин. Не стоит, также, недооценивать значимость кругозора. =)

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

Нет, это его изречение на жалобы по поводу сложных домашних заданий. Он давал ДЗ такие, чтобы человек "прочувствовал" новый материал по полной, чтобы отмучал его. Тогда запоминается навсегда

Это да, лично я больше склоняюсь к апостериори. Но да, в разрезе программирования без теории никуда.

Ну с учетом того, что я - не профессиональный программист, просто очень нравится. И приходя домой после работы я не укладываюсь отдыхать перед телеком, а изучаю программирование - мотивации у меня предостаточно.

Б**ть, как задумаюсь - тоскливо как-то стает. Дебильная ситуация получилась - работаю в совершенно другой отрасли, а выходные и вечера провожу за программированием...
Уже не раз задумывался над тем чтобы сменить род деятельности. Видимо надо таки принять волевое решение...

Как тогда прокомментируешь, например, Laravel`ный роутинг?

Route::get($uri, $callback);
Route::post($uri, $callback);
Route::put($uri, $callback);
Route::patch($uri, $callback);
Route::delete($uri, $callback);
Route::options($uri, $callback);

В смысле как? Я уже сказал своё мнение, что это излишний функционал.
Вот этого достаточно:

Route::add($uri, $callback);

Пользователь перешёл по адресу, к адресу (маршруту) может быть привязано от нуля до бесконечности обработчиков "callback", роутер нашёл маршрут, понял кого нужно дёрнуть.
А в конкретном $callback уже если нужно то читаешь POST или DELETE или что там в голову взбредёт, это уже не работа маршрутизатора, маршрут он нашёл, а что лежит в теле запроса его не волнует.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

То есть ты предлагаешь реализовать что-то вроде наблюдателя, а маршруты сделать, как бы, ивент триггерами? Как в JS, навесим на событие 10 обработчиков, каждый запустим, типа, кому "интересно" тот и отработает?

Проблема сразу же возникает, приоритезация - последовательность вызовов. В каком порядке, определенном роутом? То есть мы часть логики проекта описываем в роутах. Весьма странное и очень спорное архитектурное решение.

Я за ранее разделение, тем более вызовы должны обрабатываться разными методами контроллера. Особенно различные HTTP методы. Разные действия, разные обработчики, по-моему логично. Роутер как раз для этого и придумывался, для хорошего гибкого разделения ответственности между обработчиками.

Arh, жизнь заставляла работать на примитивнейших роутерах, когда требовались дополнительные проверки в обработчиках. И начиналось примерно вот это говнецо:

if (!empty($_POST)) {}
if ((int)$id !== 0) {} //проблемы с нулём, кстати.

if (preg_match('!expression!', $id[0])) {
    //код
} else {
    //Делегирование, вызов другого метода (обработчика). То чем должен роутер заниматься.
    //А на тот, делегируемый, метод так же ссылается другой роут. Получили 2 одинаковые страницы по разным URL-ам.
}

=)