Здравствуйте.
Хотел поделиться с широким читателем информацией о реализации Friendly URL на своих проектах.
Рассуждение пойдёт об эргономике, синтаксических принципах, понятности и удобстве интерфейсов. Предупреждаю, со стороны программной реализации я эту тему развивать не буду, потому как все делают по-разному и найти правду тут довольно сложно. Кто-то может сравнивать полученный урл с кучей правил, кто-то может индексировать совпадения, кто-то если угодно, генерировать .htaccess файл с правилами. Не суть.
Первое о чём хотелось бы сказать, это об отличии проектов, работающих только через Friendly URL, и работающие как на прямых путях с параметрами, так и на Friendly URL.
Реализация второго варианта понятна. Если физически нет запрошенного файла, то отправить искать среди правил на предмет совпадения. Преимущество данного варианта в том, что он легко реализуем и может вводиться на проект кусками, там где это нужно.
Но возможен и второй вариант, когда прямая адресация к скриптам полностью запрещается. Она есть только, к примеру, для папки static/, которая хранит в себе скрипты и картинки. Доступ до всего остального возможен лишь через свод правил для данного проекта. Преимуществом является сокрытие реальной файловой структуры проекта и открытие лишь тех страниц, которые позволены.
Не буду спорить на тему того, «Как лучше», так как по этому поводу люди неоднократно голосовали на хабре (http://habrahabr.ru/blogs/searchengines/125103/, http://habrahabr.ru/blogs/personal/41602/, http://habrahabr.ru/blogs/personal/35599/) расскажу лишь о собственной концепции:
Поскольку построением URL занимается зачастую не разработчик, возникает вопрос удобного средства для создания правил человеком, с минимумом знаний об устройстве системы и списке допустимых параметров.
Для этого я использую так называемый Раутер. С точки зрения пользователя — это конструктор правил, с понятным и удобным интерфейсом. Он представляет собой таблицу с input и select полями, у каждой из строк которой есть следующие параметры:
В результате, мы возлагаем на пользователя Раутера лишь следующие обязанности
Спасибо за внимание, надеюсь кому-то мой опыт помог, а кого-то натолкнул на новые идеи.
Хотел поделиться с широким читателем информацией о реализации Friendly URL на своих проектах.
Рассуждение пойдёт об эргономике, синтаксических принципах, понятности и удобстве интерфейсов. Предупреждаю, со стороны программной реализации я эту тему развивать не буду, потому как все делают по-разному и найти правду тут довольно сложно. Кто-то может сравнивать полученный урл с кучей правил, кто-то может индексировать совпадения, кто-то если угодно, генерировать .htaccess файл с правилами. Не суть.
Типы подходов
Первое о чём хотелось бы сказать, это об отличии проектов, работающих только через Friendly URL, и работающие как на прямых путях с параметрами, так и на Friendly URL.
Реализация второго варианта понятна. Если физически нет запрошенного файла, то отправить искать среди правил на предмет совпадения. Преимущество данного варианта в том, что он легко реализуем и может вводиться на проект кусками, там где это нужно.
Но возможен и второй вариант, когда прямая адресация к скриптам полностью запрещается. Она есть только, к примеру, для папки static/, которая хранит в себе скрипты и картинки. Доступ до всего остального возможен лишь через свод правил для данного проекта. Преимуществом является сокрытие реальной файловой структуры проекта и открытие лишь тех страниц, которые позволены.
Синтаксис Человеко-Понятных URL
Не буду спорить на тему того, «Как лучше», так как по этому поводу люди неоднократно голосовали на хабре (http://habrahabr.ru/blogs/searchengines/125103/, http://habrahabr.ru/blogs/personal/41602/, http://habrahabr.ru/blogs/personal/35599/) расскажу лишь о собственной концепции:
- Если языковых версий на проекте несколько, язык выносится как первый компонент URL (site.com/ru/, site.com/en/). Возможно, конечно, разбитие языковых версий по доменам (site.ru, site.ua, site.kz), но мне кажется это больше подходит для определения региональных представительств некого проекта, чем языковой принадлежности.
- Если основное содержимое страницы являет собой список неких объектов, на которые возможен переход, представляем URL этой страницы как директорию (site.ru/news/, site.ru/users/, site.ru/catalog/auto/trucks/used/). Важно отметить, что если страница является списком элементов, на которые нет перехода (к примеру список адресов диллеров), то не стоит представлять её URL как директорию. Это конечная страница в иерархии. Также отмечу, что не стоит вставлять слеши там, где нет промежуточных списков, то есть если от данного URL отрезать с конца компоненты до ближайшего слеша, всегда должна существовать страница, соответствующая полученному URL.
- Если основное содержимое страницы представляет собой конечную ступень некой иерархии или просто независимую страницу, резонно заканчивать её URL в виде имени некоего файла. Я предпочитаю .html, хотя почему бы и не .php, просто путаницы меньше. Примеры: /about.html, users/anufry.html, /news/olimpia-2011.html, /catalog/auto/trucks/used/438829.html.
- Для крупных проектов разделы сайта есть смысл разбивать на поддомены, как например вынести блоги на отдельный поддомен. Мне кажется это красивым и оправданным, особенно если при этом для блогов предусмотрен изменённый дизайн и своя структура страниц. Быть может кто-нибудь скажет «А почему не на отдельный домен?». Ну я отвечу — чтоб не мучиться с куками, не создавать ощущения перехода по рекламной ссылке.
- В связи с пунктами 2 (директории) и 3 (конечные страницы), крайне нежелательно засовывать в путь такие параметры как order, limit, page, различные уточняющие параметры и прочее. URL вида /catalog/brushes/last_added/page3/new|red|classic/… создаёт пугающее ощущение того что вы зашли куда-то, откуда уже не выбраться. Пусть эти параметры будут там где им положено — в GET-запросе. /catalog/brushes/?order=last_added&page=3&specify[color]=red&specify[style]=classic. Это конечно длиннее, но зато явно видно, что содержимое страницы выведено не по-умолчанию, а согласно неким параметрам, и от них можно избавиться просто взяв путь из URL.
- Формы. Если Вы используете MVC-архитектуру, где все формы обрабатывает тот же контроллер, что и построил форму, оптимально указывать атрибут action="" (пусто). Это подразумевает, что независимо от того, как Вы меняете Friendly URL для данной формы, данные уйдут куда надо, соответственно меньше правок в шаблонах и т.п.
Раутер
Поскольку построением URL занимается зачастую не разработчик, возникает вопрос удобного средства для создания правил человеком, с минимумом знаний об устройстве системы и списке допустимых параметров.
Для этого я использую так называемый Раутер. С точки зрения пользователя — это конструктор правил, с понятным и удобным интерфейсом. Он представляет собой таблицу с input и select полями, у каждой из строк которой есть следующие параметры:
- Поддомен — Собственно домен третего уровня, если он нам нужен. Обычно он пустой.
- Правило — Правило, для поиска совпадения. В правилах я допускаю введение переменных, ктороые соответсвуют следующим шаблонам в регулярном выражении:
- {abc} => [A-Za-z]+
- {123} => [0-9]+
- {word} => [A-Za-z0-9_-.]+
- {lang} => [a-z]{2}
- {chars} => .*
Каждая из переменных запоминается и может быть подставлена в поле «Переменные» в виде $1, $2, $3 и так далее в порядке следования в правиле. - Каркас или Тема — Селектовый список. Определяет какая графическая тема будет применена на данной странице. Обычно это каркас по-умолчанию
- Плагин — Селектовый список. В моей системе плагины — это MVC-структуры, поэтому по сути, это указание контроллера, который примет на себя работу.
- Событие — Селектовый список. Метод в контроллере, который будет вызван.
- Переменные — Несколько инпутов, вида «имя переменной = ________». Допустимые переменные в данном событии (методе). Информация о допустимых переменных хранится в конфигурационном файле, поэтому человек создающий правило может указать значения только для допустимых переменных.
В результате, мы возлагаем на пользователя Раутера лишь следующие обязанности
- Придумать уникальное и логичное правило
- Правильно разместить его в списке, чтобы его не перекрыло другое правило
- Не перепутать порядок значений переменных из правила при подстановки в колонку «Переменные»
- Знание английского языка (я считаю, что URL пока что должны быть на английском, а не на транслите и не на русском/албанском, но это сугубо моё мнение)
Спасибо за внимание, надеюсь кому-то мой опыт помог, а кого-то натолкнул на новые идеи.