Особо не пишу про технические штуки, но вот проняло. Во всех своих проектах, которые планирую модифицировать, стараюсь юзать урлы вида:
/тип-страницы/айди/херня для человека
Или
/<айди>/<херня для человека>
Например:
/article/1034/how-to-cook-potato/
/03/рахат-лукум.html
Чё тут такого? А вот чё: в CMS все урлы /<тип-страницы>/<айди>/* равны, и делают 301 редирект на текущий урл вида /<тип-страницы>/<айди>/<херня для человека>. То бишь:
/article/1034/ ->301-> /article/1034/how-to-cook-potato/
/article/1034/как_готовить_картоху.html ->301-> /article/1034/how-to-cook-potato/
Таким образом, над частью «херня для человека» мы можем извращаться как угодно. Для всяких там САП это не проканает, а вот для людей и поисковиков схема идеальная. Других вариантов обычно два: либо наплевать на то, что урл может измениться (превед, Вордпресс!), либо хранить все старые урлы в базе и редиректить с них (дарова, Друпал!). И оба эти варианта — порочны.
а в коде этой самой страницы с каким угодно окончанием — указываешь канонический урл? если нет — надо бы, чтобы гугл знал, какая страница на самом деле основная и дубли не плодил.
Плохо прочитал, везде 301 редирект на основной урл. Никаких дублей и быть не может. Как только мы переделываем это окончание (допустим, переименовываем) — редирект пойдёт на новое.
Вот те пример: http://wikimapia.org/1818798/Angeles-City — как раз я там вводил эту мою патентованную систему :) Поперебирай окончания.
Э, а зачем? Может просто сразу делать url для человека, а тип и id уже по базе или роутингом определять? /news-by-atlantic-city.html?id=18
Невозможно ничего изменить без затрат. Точка!
Допустим, узнал ты, что такой-то символ не канает, как пробел (для многих это неприятный сюрпрайз, но «_» до сих пор не пробел для Гугла). И чо будешь делать? :)
Или, как в Викимапии: пользователи иногда переименовывают тайтл, по которому строится slug. Что тут прикажешь делать? Оставить старый? А если там опечатка, а стало лучше? По-другому делать — я описал варианты.
И быть уверенным, что такого не будет — практически невозможно.
Ваще почему я написал: щас вот хрен переделаешь на блоге все трансличеные урлы в кириллические. Это тоже пример.
Ну переименовал, со старого просто поставил 301 редирект на новый адрес и всё. Получается связь одного уникального ID ко многим алиасам, среди которых 1 текущий, а остальные прошлые варианты с редиректом.
Ну и если придерживать твоей схемы, то тип излишним тоже будет, пусть только ID будет, он уникальный на всё и по нему же можно узнать тип к примеру.
Я написал про твой вариант в конце поста :) Читай внимательно. Надо будет хранить старый адрес. Если глобально тебе взбредёт поменять принцип именования слагов — то слегка многовато будет хранить чего. Если часто переименовывают (пример: Викимапия) — то на каждый пост десятки будут записей в базе. Зачем это всё? :) Тут ты ваще ничего не хранишь. Думать ваще не надо. Хоть /id/ только пиши в урле — это будет работать на все 100%.
А тип нужен, если сложный проект. Ты, похоже, фреймворк юзаешь какой-то? В джанге это зовётся аппы. В остальных — как-нить ещё. Для основного аппа, конечно, урл можно вынести без префикса.
ЗЫ: кстати — единственное, когда схема сильно будет сосать — это в случае тегов. Я, и какие-нить ещё гики, наверное, привыкли вбивать tag/.
Схема сама по себе избыточная, раз достаточно только ID, да и мелочи хронить uri строки в сравнении например с файлами и текстами контента расхода больше будет, экономить на этом я бы не стал.
App в Django как я понимаю, это собранные в один application набор контроллеров, библиотек, моделей и вьюшек. Если так, то видимо обычно их два бывает в рабочем приложении, frontend и backend, думаю в последнем нам такие url бесполезные и не заботит, то для frontend’а роутинг вполне мог бы и определять, что это цифровой id и значит это наш такой-то app и т.п.
Схема конечно имеет право на жизнь. Например в одном из моих новых проектов я использовал схожий принцип.
Только у меня uri строится по дереву
/news/about/id.12.title.16.html
/news/about — это дерево
id.12.title.hello-world — это параметры id=>12, title=>hello-world
Вот например
http://sampostroyu.ru/catalogue/product.426.sayding-d4-5d-karamel.html
здесь например sayding-d4… нафиг не нужный параметр, лишь для сео и делает автоматом транслитерацией (ибо позиций много и грузятся из 1С), то его можно стереть или написать что угодно
http://sampostroyu.ru/catalogue/product.426.html будет работать, это основа
Так же есть разумеется бэкэнд и фронтэнд, но и то и другое всё завязано на дереве адресов, потому на самом деле роутинга от фреймворка и каких-либо ушей application не видно
С тэгами да, есть неувязка, но я привык считать тэги параметром, а не как ресурсом uri, потому /bog/posts?tag=траляля саме то имхо
MpaK, ты SE не занимаешься, чтоль? :) Эти слаги ваще нах не нужны, кроме как для поисковиков щас.
Ага, не дочитал, вижу — занимаешься :)
Не, не бекенд-фронтенд. Апп в Жанго — это логически собранный кусок приложения. Например, «статьи», «блог», «форум».
Ну СЕО это так, по просьбе заказчика, как говориться за деньги клиента любой его каприз, хоть шрифты в 42em :)
С app понял, а-ля пакеты где собраны контроллеры с его моделями, библиотеками и вьюшками. У меня в CMS это HMVC модули.
Отличный способ. Всё гениальное просто. :)
А мне нравится схема /год/месяц/число/херня-для-человека. Тогда можно стирать до слеша и получать записи за число, месяц, год соответственно. В этом хоть смысл есть, а кому нафиг нужен числовой ID?
Компьютеру. Я не про юзабилити онли. А про комфорт между тем и другим.
/год/месяц/число/ мне кажется избыточным (если только речь не о новостном сайте/разделе сайта), поскольку это тоже по сути «херня для человека». Тогда лучше /ид/херня-для-человека-вместе-с-датой-если-надо
Тормоз, ну это для новостей логично и удобно. Для например каталога товаров ну совсем не в тему или например в разделе История — О компании, Сотрудники и т.п. года жеж не нужны :)
Потому и все нормальные фреймворки дают в руки правила роутинга
Ну да, согласен, конечно. Смотря где. Но для блога точно отлично подходит структура с датами, как я выше показал. А вот реплику Samlowry про необходимость ID компьютеру не понял. Нафиг он ему? ID внутри машины и так существует, зачем это показывать наружу?
Понял? Мрак дело говорит! А ты и не знал…
Тормоз, ну это не то чтобы компьютеру, скрипт блога, сайта, cms должен как-то однозначно реагировать на адресную строку. Потому желательно иметь уникальный URI, таким может выступать уникальный ID например, чтобы точно знать, что на
100 — надо показать пост в блоге с номером 100 и шаблоном красный
а например на 200 показать контактные данные в шаблоне зеленого цвета :)
ID не всегда просто может быть числовой, это может быть например уникальное название или уникальное название из вложенных в друг-друга папочек и т.д.
Нет, честно — не понял :) Уникальный URI может быть без числового ID.
@Тормоз:
Что непонятного-то?
Что будет со входящими ссылками, если ты решишь у записи сменить URL? 404 будет.
Поэтому URL логически делится на две части: числовой ID, необходимый CMS для распознавания URL, и человекочитаемая-хрень, необходимая только для SEO и повышения юзабилити. Вторую часть можно хоть как менять, при этом все прежние ссылки на запись будут оставаться валидными (редиректиться на канонический вариант).
Тормоз просто слишком опирается на юзабилити. Не, когда-то, когда компьютеры станут очень большими, а сохранение всех старых урлов будет стандартной частью любого фреймворка — это будет пох. Может быть, тогда и id страницы будет не цифрой, а текстовым полем, в котором будет лежать урл — так будет нагляднее при программировании :)
Тормоз, на примерах всё проще
вот адресная строка
/about/
/contacts/
они должны однозначно показывать, первый текст о компании, второй схему проезда
не желательно, чтобы при заходе на about у тебя то текст показался, то не показался или хуже еще что-то иное покажет :) /about/ можно считать тем же уникальным ID (соблюдать уникальность надо нам) по которому мы точно можем сказать какая страница будет показана.
вложенные это например /about/russia/ можно считать это тоже уникальным ID, можно считать это иерархией уникальных ID и т.п.
Clr, про смену URLа не подумал. По идее, их менять нафиг не надо, но это иногда случается, да :)
Благородный дон Тормоз, я, может, плохо объяснил, но идея крутилась вокруг возможности смены урлов и только неё.
Да наверно просто я непонятливый. Однако, всё равно решение с запоминанием старых URL было бы красивей, человекоприятней. Машина с памятью, вот пусть она и запоминает.
Тормоз, ну с идей, которую предлагает samlowry даже запонимать старые URI не надо, но у неё другой момент — излишество параметров и не совсем ясно с построением иерархии объектов
Кстати, про сохранение версий URL. Смотрите какую классную цитату Раскина сегодня вспомнил сотрудник A1 у меня в комментариях — http://brokenbrake.biz/2010/11/24/ugly-A1Pay#c015115
Бесценные данные? :))) Ну не, я отказываюсь, сохранять постоянный навоз из кучи спама, розовощеких блондинок и смачно пердящих юнцов с прыщами на всяких форумах школоты
Ты вообще сути не понял.
«Ты вообще сути не понял.» такие фразы без продолжения мысли принято записывать в «губошлество» еще это называют «бла-бла-бла» :)))
А куда принято записывать за выдранные из контекста пару слов и развитие их до пердящих юнцов?
Сотрудники A1 читали Раскина — удивительное рядом.