Pull to refresh

Мой персональный взгляд на Friendly URL и автоматизацию работы с ним

Reading time 4 min
Views 3.9K
Здравствуйте.

Хотел поделиться с широким читателем информацией о реализации 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/) расскажу лишь о собственной концепции:

  1. Если языковых версий на проекте несколько, язык выносится как первый компонент URL (site.com/ru/, site.com/en/). Возможно, конечно, разбитие языковых версий по доменам (site.ru, site.ua, site.kz), но мне кажется это больше подходит для определения региональных представительств некого проекта, чем языковой принадлежности.
  2. Если основное содержимое страницы являет собой список неких объектов, на которые возможен переход, представляем URL этой страницы как директорию (site.ru/news/, site.ru/users/, site.ru/catalog/auto/trucks/used/). Важно отметить, что если страница является списком элементов, на которые нет перехода (к примеру список адресов диллеров), то не стоит представлять её URL как директорию. Это конечная страница в иерархии. Также отмечу, что не стоит вставлять слеши там, где нет промежуточных списков, то есть если от данного URL отрезать с конца компоненты до ближайшего слеша, всегда должна существовать страница, соответствующая полученному URL.
  3. Если основное содержимое страницы представляет собой конечную ступень некой иерархии или просто независимую страницу, резонно заканчивать её URL в виде имени некоего файла. Я предпочитаю .html, хотя почему бы и не .php, просто путаницы меньше. Примеры: /about.html, users/anufry.html, /news/olimpia-2011.html, /catalog/auto/trucks/used/438829.html.
  4. Для крупных проектов разделы сайта есть смысл разбивать на поддомены, как например вынести блоги на отдельный поддомен. Мне кажется это красивым и оправданным, особенно если при этом для блогов предусмотрен изменённый дизайн и своя структура страниц. Быть может кто-нибудь скажет «А почему не на отдельный домен?». Ну я отвечу — чтоб не мучиться с куками, не создавать ощущения перехода по рекламной ссылке.
  5. В связи с пунктами 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.
  6. Формы. Если Вы используете MVC-архитектуру, где все формы обрабатывает тот же контроллер, что и построил форму, оптимально указывать атрибут action="" (пусто). Это подразумевает, что независимо от того, как Вы меняете Friendly URL для данной формы, данные уйдут куда надо, соответственно меньше правок в шаблонах и т.п.


Раутер

Поскольку построением URL занимается зачастую не разработчик, возникает вопрос удобного средства для создания правил человеком, с минимумом знаний об устройстве системы и списке допустимых параметров.
Для этого я использую так называемый Раутер. С точки зрения пользователя — это конструктор правил, с понятным и удобным интерфейсом. Он представляет собой таблицу с input и select полями, у каждой из строк которой есть следующие параметры:

  1. Поддомен — Собственно домен третего уровня, если он нам нужен. Обычно он пустой.
  2. Правило — Правило, для поиска совпадения. В правилах я допускаю введение переменных, ктороые соответсвуют следующим шаблонам в регулярном выражении:
    • {abc} => [A-Za-z]+
    • {123} => [0-9]+
    • {word} => [A-Za-z0-9_-.]+
    • {lang} => [a-z]{2}
    • {chars} => .*

    Каждая из переменных запоминается и может быть подставлена в поле «Переменные» в виде $1, $2, $3 и так далее в порядке следования в правиле.
  3. Каркас или Тема — Селектовый список. Определяет какая графическая тема будет применена на данной странице. Обычно это каркас по-умолчанию
  4. Плагин — Селектовый список. В моей системе плагины — это MVC-структуры, поэтому по сути, это указание контроллера, который примет на себя работу.
  5. Событие — Селектовый список. Метод в контроллере, который будет вызван.
  6. Переменные — Несколько инпутов, вида «имя переменной = ________». Допустимые переменные в данном событии (методе). Информация о допустимых переменных хранится в конфигурационном файле, поэтому человек создающий правило может указать значения только для допустимых переменных.


В результате, мы возлагаем на пользователя Раутера лишь следующие обязанности
  • Придумать уникальное и логичное правило
  • Правильно разместить его в списке, чтобы его не перекрыло другое правило
  • Не перепутать порядок значений переменных из правила при подстановки в колонку «Переменные»
  • Знание английского языка (я считаю, что URL пока что должны быть на английском, а не на транслите и не на русском/албанском, но это сугубо моё мнение)


Спасибо за внимание, надеюсь кому-то мой опыт помог, а кого-то натолкнул на новые идеи.
Tags:
Hubs:
+6
Comments 24
Comments Comments 24

Articles