Спор между оптимизаторами и программистами.

Хитро, возьму на вооружение. Спасибо )

Может, может.

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

так показывают-же по разному. Для категории один метод со своими построениями, для страницы - другой.

Совершенно не обязательно. Доступность по нескольким адресам - это уже ошибка роутинга. А вот как вы реализуете произвольное количество категорий с произвольным уровнем вложенности? На каждую категорию создавать правило рерайта? И на подкатегорию в категории? ну не вручную же?

В общем, долго уже спорим.. правда не по теме уже. В общем, моя точка зрения такова, что категория и страница - это разные объекты, отличающиеся как минимум параметром типа и соответствующими этому типу обработчиками. Вы можете не соглашаться с этим - структуры данных разные бывают. Просто я считаю эту (описанную выше) более "привычной", "понятной", "традиционной" и вполне логичной. Что, замечу, никак не отрицает вашей схемы хранения и схемы иерархии объектов данных.

Алексей, у тебя завтра конфа с утра, не забыл? Время то уже не детское :)

уровни вложенности лишние, вы просто не сможете даже придумать такой структуры где она была бы возможна и невозможна прямая :)

так это-то как раз вообще не проблема - дополнительное свойство у страницы с ссылкой на родителя (т.е. у страницы может быть много родителей - страница техники, страница производителей, страница отзывов, страница цвета, ...)

так к задачи цмс рерайт ну ни как не относится - может в этом проблема? :)

---------- Добавлено 12.10.2012 в 00:01 ----------

Ворожцов Виктор, помню, презенташку доделываю, думаю как в 30 минут уложиться и хоть что-то интересное показать, не залезая при этом в дебри

P.S. я раньше 4 не ложусь :)

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

Видимо, основная мысль в том, что "структура URL" и тип отображаемой страницы не обязательно должны быть связаны видимой "снаружи" (для посетителя, оптимизатора) закономерностью.. Для программистов.. А как именно выводить страницу, которая имеет определённый URL должно определяться "внутри" (будет ли это список или массив в файле вроде URI->тип страницы, таблица в БД аналогичной структуры).

Т.е. вложенность вроде audio/headphones, наличие "спецслов" вроде category или product

И поисковики (не все?) умеют определять вложенность страницы (хлебные крошки в выдаче) не по вложенности URL-ов.

В таких ситуациях спорный вопрос.. а что же выводить в хлебных крошках..

Тут по соседству обсуждение было.. :)

А как к этому произволу отнесутся ПС?

Ну так может тогда про восприятие ПС этой логичности домен/раздел/страница?лишний-Параметр

А криворуких ... так получается, что вот просто везде они.

И создатели серверов (из лучших побуждений) подготовили условия для возникновения дублей http://company.yandex.ru/?гавно☻контора 200 OK

На самом деле нет, не необходимы. "Привычность" схемы это зачастую залог хорошего юзабилити само по себе. Юзер которому надо втыкать "как тут на сайте все экзотно устроено" зачастую просто покидает сайт не разобравшись что и как или свинчивает при первом удобном случае на "такой же, но привычный". Это разумеется если Вы сайт для юзеров делаете, а не для поисковиков:)

богоносец, с аргументом, "чем короче, тем лучше" я не спорю - безаппеляционно признаю.

Что-то я заговорился :) имел в виду rewriterule в .htaccess, которые необходимы для корректной навигации для каждой подкатегории.Да нет... тут как раз все банально - обыкновенные каталоги, реализованные на страничном функционале. Сплошь и рядом. Просто пользователю не объяснить, что нельзя создавать две страница с одним и тем же адресом - например, две contacts.html .. но когда мы реализуем дополнительный уровень, то эта проблема сама собой отпадает. Не полностью, конечно, ибо неисповедимы пути юзеров, но перестает быть критичной. Например: partners/contacts.html - и как бы все счастливы. И с правилами rewriterule все становится определенно просто, так как в адресе уже зашита иерархия. Но для справедливости соглашусь - без проблем можно реализовать даже самые сложные иерархии не выходя за рамки адресов... эммм, как бы не ошибиться в терминологии - не выходя за рамки адресов первого уровня. Но это актуально, когда ты сам делаешь сайт от и до. Однако, как правило, все неимоверные навороты начинаются уже после первичного наполнения и сдачи сайта заказчику.

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

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

Ну и так, в качестве флейма, так как спор на этом можно завершить :)

По поводу множественности родителей... уфф.. такая шляпа с этим. Я однажды фотогаллерею делал с множественными родителями - там такая морока с тем, чтобы построить дерево разделов! Или чтобы удалить какую-то группу фотографий, приходится делать 101у проверку, а не является ли вложенная в группу картинка зеркалом? и так далее... мороки много.. и когда я наконец реализовал всю задумку в полной мере, то оказалось, что все пожелания заказчика ну оооочень просто можно реализовать самой обычной галереей без множественности родителей, с линейной иерархией. В общем, забил я на это дело. Так и лежит тот модуль единожды опробованным.

Плохо. Согласен.

Не-не, про ?лишний=параметр я не говорил. Это мы помним, блюдем и стараемся избегать.

На счет иерархии в самом адресе - с точки зрения программиста это вполне логично. С точки зрения SEOшника - это беспредел, особенно когда речь за ходит о третьем и больше уровне вложенности. Тут, как бы.. у каждого своя правда. Но, выше я согласился, правильнее будет встать на сторону SEO ибо, в конечном итоге, именно для продвижения и рекламы (содержимого сайта) и создается сам сайт (коммерческий сайт).

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

Вот-вот. Вы меня понимаете)

Кстати, да.. умеют.. просто вложенность по адресу, скорее, не для поисковиков, а для пользователя..

Кстати, давайте еще немного пофлеймим (не совсем по теме).

Сейчас планируется архитектура другого специфичного движка. И, скорее всего, с учетом всех ваших аргументов, я откажусь от иерархии в адресе. Постараюсь все адреса делать первого уровня вложенности. Но тут неизбежно возникает загвоздка - повторение адресов. Движок будет что-то вроде форумного. ЧПУ является обязательным. Следовательно, адрес имеет смысл формировать по теме топика (транслитерировать). Но даже в этом случае адреса страниц могут повторяться, так как могут повторяться названия топиков. И есть такая мысль, которую я предлагаю обсудить - в случае неуникальности адреса страницы приписывать в конец адреса какую-то фразу из словаря... или, возможно, не просто из словаря, а из списка ключевых слов по сайту.. или не по сайту, а свойственных текущему разделу "типа форума".. как вам такая мысль? burunduk, что скажете?

Он тут щас, завтра будет :)