Предопределение путей к экшенам, и еще один момент
Было бы здорово до релиза, пока еще не заверстан новый дизайн, предопределить пути константами. Движок можно конфигурировать под разные задачи и типы сайтов, однако немного не хватает гибкости с путями. Варианты переименования — за слешами.
В темплейтах конструкция "/blog/" встречается довольно часто, можно пройтись и везде поменять пути вручную, но тогда обновление частей движка через SVN — приведет к ошибкам.
Второй момент: использование ".html" в окончании топиков. Я поверхностно пробежался по движку, по сайту, и пока не нашел обоснований использования этого. Возможно, для указания ID топика, при неоднородной структуре (а такое уже есть?). В этом случае (обязательной идентификации ID топика в пути) предлагаю для этой самой идентификации — использовать предопределенный паттерн, чтобы иметь возможность, к примеру, использовать такие пути: /blog/bla/t-1212
Да, это можно сделать вручную, но тем самым лишив себя возможности быстро обновляться.
В темплейтах конструкция "/blog/" встречается довольно часто, можно пройтись и везде поменять пути вручную, но тогда обновление частей движка через SVN — приведет к ошибкам.
define('LSPATH_PROFILE','profile'); //e.g. user
define('LSPATH_PEOPLE','people'); //e.g. users
define('LSPATH_BLOG','blog'); //e.g. community
define('LSPATH_LOG','log'); //e.g. blog
define('LSPATH_MY','my'); //e.g. blog
define('LSPATH_PAGE','page'); //e.g. static
return array(
'page' => array(
LSPATH_PROFILE => 'ActionProfile',
LSPATH_BLOG => 'ActionBlog',
LSPATH_PEOPLE => 'ActionPeople',
)
);
Второй момент: использование ".html" в окончании топиков. Я поверхностно пробежался по движку, по сайту, и пока не нашел обоснований использования этого. Возможно, для указания ID топика, при неоднородной структуре (а такое уже есть?). В этом случае (обязательной идентификации ID топика в пути) предлагаю для этой самой идентификации — использовать предопределенный паттерн, чтобы иметь возможность, к примеру, использовать такие пути: /blog/bla/t-1212
Да, это можно сделать вручную, но тем самым лишив себя возможности быстро обновляться.
31 комментарий
Со второй частью не понял чего не нравится…
Я обоими руками за nazvanie_topika_translitom.html
А не нравится «.html» — рудимент прошлого. Куда более красивее пути типа /blog/bla/324
насколько я знаю, html лучше «читается» поисковиками…
Ну а то, что html лучше «читается» поисковиками — перестало быть актуально еще задолго до появления Хабра.
сколько людей, столько мнений…
путь с .html или с /postId — это ЧПУ, а путь с топик-тайтлом транслитом в УРЛе — это уже нифига не человеко-понятный УРЛ, т.к. глупо надеяться, что пользователь будет запоминать таблицу транслитерации сайта и плюс точное название топика
по-моему \blogs\topik-pro-krasivyh-koshek.html более понятен чем \blogs\11
Когда мне по аське кидают ссылу с названием топика я ее могу открыть, когда кидают просто номер я спрошу что это.
Кстати, хочу напомнить что в ие7 до сих пор в выпадающем списке строки адреса до сих пор не подписывается тайтл страницы. И там-то как раз только по УРЛу можно определить куда он ведет.
Хотя и правда каждому приятнее свое…
Можно айдишниками обойтись)
«Ужасно» — субъективное понятие… Напр. для меня айди поста «Ужасно неинформативно».
Касательно производительности — в сети полно примеров ссылок с тайтлами. Как-то это реализуется.
В общем всё зависит от нужд конечно же…
а если на этой куче сайтов на говнодвижке типа ДЛЕ используются ссылки с заголовками, то это ничего не значит…
если на той же самой куче сайтов используются рекламные попапы или DIV-ы с рекламой поверх всего контента и всегда в центре страницы+при «закрытии» этого дива открывается порносайт или рекламные блоки на 2/3 площади страницы, то это значит что мы все тоже такой треш должны у себя устраивать? и в «правильные» движки встраивать чтобы всякие разные пипл-ы с желанием создать говносайт за 5 минут и зарабатывать на нем дофига денег жили спокойно далее и не напрягались?
Посмотрите на Хабр. на главной почти нет рекламы, в УРЛах никаких заголовков, но тем не менее при минимальной релевантности запроса к хабру, ссылка на него является первой в поисковиках
Я к ним отношусь точно так же как и Вы.
Не совсем понятно, почему была поднята тема с той кучей левых сайтов…
Касательно харбра — сам по себе ресурс имеет огромную базу статей и часто цитируется. Это не показатель…
Я думаю нам не стоит спорить, а можно:
1. Найти SEOшника и узнать, действительно ли линки с тайтлом эффективнее в продвижении, или это и правда «рудимент».
2. Согласиться что для каждого удобнее тот или иной вид ссылок («аккуратный» либо «информативный»)
Но топик совсем не об этом.
по 269 можно без проблем все индексировать, а 'puti-k-ekshenam' с .html или без это каждый выберет для себя сам :) в плане реализации идеи как лучше сделать? отдельную таблицу prefix_url с полями tid,url или добавить в таблицу prefix_topic еще одно поле url?
А насчет мифа о «лучшем индексировании с .html» — стоит просто задать себе вопрос: правда ли, что страница /blog/wishlist/269.html лучше проиндексирована, чем страница /blog/wishlist/? И после этого перестать забивать голову подобным.
Еще одним важным плюсом осутсвия .html — увеличение глубины в структуре. К примеру, /blog/wishlist/269/comment/12121
Гооврить о пользе этого — смысла нет, это просто пример, но где это может пригодиться — вариантов множество.
/blog/wishlist/269/comment/12121 очень уж глубокая и поисковики такие не любят… я ошибался?
Во-первых, это не обязательно для поисковиков — это важно.
Во-вторых, глубина для поисковиков — это доступность, начиная с главной. Т.е., если эта ссылка будет, к примеру, на главной — она вполне даже доступна, и считается вторым уровнем.
В-третьих, Яндекс и Гугл прекрасно индексируют страницы, доступность которых более ста кликов. Даже для сайтов с нулевым PR и иЦ — могут быть проиндексированы в течение месяца. И это я не на ходу придумываю :)
денормализация :-)
таки парадокс — в теории баз данных, необходимо максимально нормализировать структуру, исключить хранение дублирующих данных, все связи осуществлять по уникальным ключам.
на практике же, с повышением нагрузки на базу приходится все больше и больше денормализировать структуру, даже на таком молодом движке, как ЖУ, это уже заметно — разнесение текста топиков и прочей служебной информации по разным таблицам и тп.
При использованпии ключевых слов в адресации — это совсем даже не «дублирующие даные», ключ же остается прежним — ID, а URL — просто ячейка, информация из которой будет задействована при большинстве (если ни при всех) запросов к строке.
Мы же говорим о варианте «/blog/wishlist/269/puti-k-ekshenam», а не о «/blog/wishlist/puti-k-ekshenam»?