Комментарии 59
Ну так во многих современных и успешных проектах используется вид example.org/users/#USER_ID#.
Тут я думаю чисто дело вкуса..
Тут я думаю чисто дело вкуса..
Забыли про очень нехилую поисковую оптимизацию, когда тысячи "сайтов" юзеров ссылаются на тебя.
С поддоменами ето просто естетично и красиво, пользователям на радость что у них есть своя страница со своим доменом, особено малопродвинутым, не взиярая на то что и с ограничеными правами, темболее такой подход чаще используетса для блогов или профилей пользователей, не обезательно пользователя всегда держать на его странице для глобальных сервисов можно его перенаправлять и на основной домен и я не думаю что пользователи от етого получат некое неудобство
Очепятка: patch -> path
Для поисков лучше когда разнесено по поддоменах. Они просто в этом не признаються.
Для поисков лучше когда разнесено по поддоменах. Они просто в этом не признаються.
НЛО прилетело и опубликовало эту надпись здесь
2. Если поддомен есть, то не зависит. Может у вас конечно и открывается один и тот же файл по адресу user.domain.com/pic.gif и domain.com/pic.gif, но надо ли посетителю сайта грузить файл несколько раз?
3. Ну попросите аналитикс, посмотрим что получится.
4. Ха-ха
5. Вот уже и хреновая иерархия.
6. Пользователь как догадается, если ссылку не увидит?
7. В path ограничений почти нет, разве что слеш нельзя и ? с &.
Количество минусов не уменьшить никак. Придется с ними мириться, если необходимо вынести пользователя в поддомен.
3. Ну попросите аналитикс, посмотрим что получится.
4. Ха-ха
5. Вот уже и хреновая иерархия.
6. Пользователь как догадается, если ссылку не увидит?
7. В path ограничений почти нет, разве что слеш нельзя и ? с &.
Количество минусов не уменьшить никак. Придется с ними мириться, если необходимо вынести пользователя в поддомен.
Поддерживаю. От себя:
1, 2 (относительные пути): Есть такой тэг - <BASE> - должен помочь.
4 (объяснить новичку): Это скорее проблема юзабилити сайта :-) На хорошем ресурсе все должно быть очевидно, если это невозможно – необходима удобная справка со скриншотами.
6. (список всех пользователей): Мне при структуре %username%.domain.com логика подсказала бы искать список юзеров (или ссылку на список юзеров) по адресу domain.com.
7. (запрещенные символы): Я не думаю что отсутствие подчеркивания более фатально для ника, чем отсутствие пробела. А если с отсутствием пробела юзеру придется мирится в любом случае, то какая разница, заменит он его дефисом или подчеркиванием? То же самое, мне кажется, можно отнести и к другим запрещенным символам.
1, 2 (относительные пути): Есть такой тэг - <BASE> - должен помочь.
4 (объяснить новичку): Это скорее проблема юзабилити сайта :-) На хорошем ресурсе все должно быть очевидно, если это невозможно – необходима удобная справка со скриншотами.
6. (список всех пользователей): Мне при структуре %username%.domain.com логика подсказала бы искать список юзеров (или ссылку на список юзеров) по адресу domain.com.
7. (запрещенные символы): Я не думаю что отсутствие подчеркивания более фатально для ника, чем отсутствие пробела. А если с отсутствием пробела юзеру придется мирится в любом случае, то какая разница, заменит он его дефисом или подчеркиванием? То же самое, мне кажется, можно отнести и к другим запрещенным символам.
Зачем мириться с отсутствием пробела? По-моему, это что-то идеологическое запрещать использовать пробелы в именах аккаунтов. MediaWiki, например, ничего не имеет против. Я тоже. Понятное дело, что поддоменом или почтовым адресом такой аккаунт быть не может, но это уже другая история.
livejournal разрешает писать подчёркивание в имени домена: http://doctor_livsy.livejournal.com/ (правда, потом перенаправляет на doctor_livsy.livejournal.com)
livejournal разрешает писать подчёркивание в имени домена: http://doctor_livsy.livejournal.com/ (правда, потом перенаправляет на doctor_livsy.livejournal.com)
Основную часть плюсов можно описать одной фразой - психологическая привлекательность. Людям нравится иметь персональный сайт, и убеждать их в том, что это ничуть не рациональнее каталогов – пустая трата времени.
Мне кажется разумным использовать сабдомены там, где на страничку каждого юзера люди будут заходить извне. Портфолио на фриланс.ру просматривают в основном люди, пришедшие по внутренней ссылке - они даже саму ссылку, как правило, не видят. В то же время адрес своей страницы в МоемКруге люди часто публикуют в личных блогах, комментариях, своих юзер-дитейлах в icq. И в этом случае адрес персонального сайта выглядит солиднее и логичнее папки на портале.
Мне кажется разумным использовать сабдомены там, где на страничку каждого юзера люди будут заходить извне. Портфолио на фриланс.ру просматривают в основном люди, пришедшие по внутренней ссылке - они даже саму ссылку, как правило, не видят. В то же время адрес своей страницы в МоемКруге люди часто публикуют в личных блогах, комментариях, своих юзер-дитейлах в icq. И в этом случае адрес персонального сайта выглядит солиднее и логичнее папки на портале.
из плюсов - поддержка OpenId
в п.7 не очень хороший пример. хорошим примером было бы: "А что если на сайте разрешены кириллические логины?"
Будущее уже наступило - на правильных сайтах логины должны быть в UTF-8 :)
вот и я не вижу смысла ограничивать пользователя латиницей.
для кириллических логинов есть ответ - кириллические домены =)
какова будет юзабельность домена "http://вася.habrahabr.ru"? :)
В частности по сабжу: не вижу какой-либо проблемы в данной ситуации. И тот, и другой подход имеет свои плюсы и минусы, все зависит от проекта, от его скажем так - "направленности", структуры, архитектуры. Большая часть минусов часто перекрывается перекрывается при правильном выборе того или иного метода...
Непонятно зачем на хабре так сделано. Может а-ля ЖЖ... Я бы лучше разнёс не юзеров, а допустим
gallery.site.com
forum.site.com
users.site.com
images.site.com
news.site.com
На компьюленте разделение идет по рубрикам. На большинстве ресурсов вынесен форум на поддомен. Где-то для распределения запросов - картинки, но вот зачем каждому юзеру создавать свой поддомен, я не понимаю(если это только не блогохостинг).
gallery.site.com
forum.site.com
users.site.com
images.site.com
news.site.com
На компьюленте разделение идет по рубрикам. На большинстве ресурсов вынесен форум на поддомен. Где-то для распределения запросов - картинки, но вот зачем каждому юзеру создавать свой поддомен, я не понимаю(если это только не блогохостинг).
не совсем соглашусь, все пользуются тем что сейчас есть. И судя по отсутствию каких-то публичных жалоб мало кого это напрягает, тут правильно это подано конечному потребителю. Имхо конечно, вообще фиг с ним как все организовано, мне глаза не мозолит. На другом проекте может быть другое представление и тоже будет все "работать".
ЖЖ первым разнес аккаунты по поддоментам из-за того, что там в своих журналах
разрешено прописывать любой css-код, который в свою очередь может
украсть куки через expression в IE или -moz-bindins в Firefox.
http://www.davidpashley.com/blog/computing/livejournal-mozilla-bug.html
На хабре видимо только для красоты пользовательские поддомены используются.
разрешено прописывать любой css-код, который в свою очередь может
украсть куки через expression в IE или -moz-bindins в Firefox.
http://www.davidpashley.com/blog/computing/livejournal-mozilla-bug.html
На хабре видимо только для красоты пользовательские поддомены используются.
Минус №1? "/путь" - работает со всеми поддоменами.
если на сайте example.com есть поддомен user.example.com, то путь / будет вести в корень именно этого поддомена, а не основного example.com. Т.е. он будет от корня, но в пределах поддомена. Поэтому пользователь будет тянуть картинки и скрипты, если пройдется по поддоменам пользователей, например, много раз, что не есть разумно.
w20? Впервые такое сокращение Web 2.0 вижу. Неудачное.
Очевидные плюси и сомнительные (читай: выдуманные) минусы.
Так напишите как каждый минус обойти/решить. Делов то!
> 1. Все адреса на сайте должны быть прописаны абсолютно (к картинкам, скриптам).
Это минус? O_o Я вообще всегда прописываю абсолютные адреса.
> 2. Все ссылки должны ставиться абсолютно (%username%.domain.com/ и domain.com/ — разные адреса, просто href="/" не напишешь).
См. п.1.
> 3. Сторонние скрипты завалят вас куками (посмотрите, например, сколько у вас хабровских кук от гугл-аналитикса).
Это плохо?)
> 4. Если какая-то приват-зона располагается на поддомене (%username%.domain.com/settings), то для того чтобы новичку что-то объяснить, то просто свою ссылку уже не дашь (много раз сталкивался).
Почему не дашь? Новичок сообщает тебе свой username и то даешь ему ссылку. А вообще, если новичок не может разобраться в вашем проекте, то значит либо вы прогадали еще на стадии проектирования, либо он попал сюда случайно и ему здесь делать нечего.
> 5. Не будет хорошей иерархии, если владельцу ресурса понадобится хотя бы один поддомен в своих целях (www, mail etc).
Ввести список зарезервированных слов и не разрешать заводить соответствующие профили.
> 6. Как увидеть список всех пользователей? При структуре domain.com/users/%username% решение очевидно — domain.com/users/, а при %username%.domain.com/ где искать такую страницу?
См п.1 и п.2.
> 7. В имени домена список запрещенных символов куда как больше, чем в path. Например если логин vasya_pupkin можно смело писать в path как имя директории, то при выносе на поддомен придется менять на vasya-pupkin.
Признаю, это наименее сомнительный минус из всех. :)
Но: vasya-pupkin красивее, нежели vasya_pupkin. Я сам достаточно давно полностью перешел на тире во всех ссылках. Смотрится отлично.
Это минус? O_o Я вообще всегда прописываю абсолютные адреса.
> 2. Все ссылки должны ставиться абсолютно (%username%.domain.com/ и domain.com/ — разные адреса, просто href="/" не напишешь).
См. п.1.
> 3. Сторонние скрипты завалят вас куками (посмотрите, например, сколько у вас хабровских кук от гугл-аналитикса).
Это плохо?)
> 4. Если какая-то приват-зона располагается на поддомене (%username%.domain.com/settings), то для того чтобы новичку что-то объяснить, то просто свою ссылку уже не дашь (много раз сталкивался).
Почему не дашь? Новичок сообщает тебе свой username и то даешь ему ссылку. А вообще, если новичок не может разобраться в вашем проекте, то значит либо вы прогадали еще на стадии проектирования, либо он попал сюда случайно и ему здесь делать нечего.
> 5. Не будет хорошей иерархии, если владельцу ресурса понадобится хотя бы один поддомен в своих целях (www, mail etc).
Ввести список зарезервированных слов и не разрешать заводить соответствующие профили.
> 6. Как увидеть список всех пользователей? При структуре domain.com/users/%username% решение очевидно — domain.com/users/, а при %username%.domain.com/ где искать такую страницу?
См п.1 и п.2.
> 7. В имени домена список запрещенных символов куда как больше, чем в path. Например если логин vasya_pupkin можно смело писать в path как имя директории, то при выносе на поддомен придется менять на vasya-pupkin.
Признаю, это наименее сомнительный минус из всех. :)
Но: vasya-pupkin красивее, нежели vasya_pupkin. Я сам достаточно давно полностью перешел на тире во всех ссылках. Смотрится отлично.
Не знаю, тут все дело привычек, наверное.
Решение непосредственное и сам автор в топике привел по каждому пункту.
Но для меня, например, написание абсолютных путей - это неудобство, так как я все время пишу их от корня.
Ну так же и по остальным пунктам, хотя обилие тех же кук мне тоже реально пофиг.
То как не разрешить пользователям регистрировать служебные домены это понятно, автор говорил об самой иерархии страниц на сайте.
Я с вами согласен с тем, что они не критичны, но некоторый дискомфорт все же могут вызвать.
Решение непосредственное и сам автор в топике привел по каждому пункту.
Но для меня, например, написание абсолютных путей - это неудобство, так как я все время пишу их от корня.
Ну так же и по остальным пунктам, хотя обилие тех же кук мне тоже реально пофиг.
То как не разрешить пользователям регистрировать служебные домены это понятно, автор говорил об самой иерархии страниц на сайте.
Я с вами согласен с тем, что они не критичны, но некоторый дискомфорт все же могут вызвать.
(почти по теме) жаль урлы не такие:
com.megasite/user/page.html
Быть может кто-то читает:
А насколько это корректно делать адреса вида test.ru/nikita/ и
насколько это хуже, чем test.ru/people/nikita/?
Понятно, что придеться отслеживать совпадение имен с служебными каталогами.
Еще какие то минусы?
А насколько это корректно делать адреса вида test.ru/nikita/ и
насколько это хуже, чем test.ru/people/nikita/?
Понятно, что придеться отслеживать совпадение имен с служебными каталогами.
Еще какие то минусы?
Если служебных каталогов нет, то вы можете поступить любым способом.
Если они есть, то вы, как минимум, ограничиваете пользователя в выборе ника.
Если они есть, то вы, как минимум, ограничиваете пользователя в выборе ника.
test.ru/user/nikita/ лучше по-моему
но о вкусах не спорят
но о вкусах не спорят
Да технически я согласен /people/ /user/ лучше…
Но допустим, как пользователь мне удобнее, говорить ссылку прямую например,
yandex.ru/nikita/, чем рассказывать о том, что ищите меня, yandex.ru users nikita,
как бы сказать мой статус принижается, когда я вставляю приставку users…
PS: Да кстати среди написания тоже миллион вариантов
/user/ /users/ /people/ и.т.д. я склоняюсь к people так как он наиболее человечный, юзеры, как-то скользко.
Но допустим, как пользователь мне удобнее, говорить ссылку прямую например,
yandex.ru/nikita/, чем рассказывать о том, что ищите меня, yandex.ru users nikita,
как бы сказать мой статус принижается, когда я вставляю приставку users…
PS: Да кстати среди написания тоже миллион вариантов
/user/ /users/ /people/ и.т.д. я склоняюсь к people так как он наиболее человечный, юзеры, как-то скользко.
user == пользователь, зарегистрированный человек, если есть регистрация. Скорее всего будет /users/login
people == просто человек. Не говорит ни о чем. Возможно очередной посетитель /people/65372
Вероятно правильнее всего будет users, т.к. оно соответсвует логике вложенности в подпапки. У вас же не один пользователь в директории.
people == просто человек. Не говорит ни о чем. Возможно очередной посетитель /people/65372
Вероятно правильнее всего будет users, т.к. оно соответсвует логике вложенности в подпапки. У вас же не один пользователь в директории.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Проблемы пользовательских поддоменов