Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 148
Забавно =))))
с радостью бы посмотрел на еще больший список полезных привычек)
И даже не надо углубляться в объяснения. Вы сами все видите, стоит только намекнуть ;)
Вы тоже о пробелах, да?
print 'habits are published: ' + xxx;
print 'привычек опубликовано: ' + xxx;
PS: Скажите, а шаблонизаторы этой весной вышли из моды, да? Это по поводу мечтаний о всемироной популярности.
print 'привычек опубликовано: ' + xxx;
PS: Скажите, а шаблонизаторы этой весной вышли из моды, да? Это по поводу мечтаний о всемироной популярности.
вообще-то постепенно выходят заменяясь нативным php — это можно глянуть по многим фреймворкам, но это тема для отдельного холивара.
Не совсем так. Многие фреймворки используют views — те же самые шаблоны, но язык в них не какой-то сферический в вакууме, а php. Но сути не меняет, для разных языков вероятно будут разные шаблоны или разные участки кода.
Пример приведенный автором явно намекал на использование одного и того же вывода для разных языков.
Пример приведенный автором явно намекал на использование одного и того же вывода для разных языков.
по хорошему-то конечно такие вещи не в шаблонизатор засовывать надо, а в локализатор.
print t("@num habits are published", array('@num' => xxx));
print t("@num habits are published", array('@num' => xxx));
Шаблонизаторы — это система в системе. В пхп они точно не нужны. Не для холивора, просто я всегда так думал.
а отсутствие пробелов никого не смущает, да? :-)
Если вдруг кто не обратил внимание, то '2 привычки', но 5 'привычек', что в английском не учитывается, кстати.
Список страниц для постраничного вывода
Непонятно. Неаргументированно. Звучит как «не используйте зеленый цвет в дизайне сайта. Бойтесь и избегайте этого способов много».
1. хочется объяснения
2. хочется примеров. если много, то хотя бы три — не так сложно привести. и сказать, что есть еще.
О переводе на языки уже сказали, у вас фейл с разными окончаниями
Заголовок списка и список — едины
Так же непонятно
а также
зачем сравнивать с нулем? надо определить, является ли ID целым числом (чаще всего — большим нуля). хотя даже это не нужно. обычно достаточно что-то типа такого(грубый пример):
получаем ID извне — сравниваем с нулем;
зачем сравнивать с нулем? надо определить, является ли ID целым числом (чаще всего — большим нуля). хотя даже это не нужно. обычно достаточно что-то типа такого(грубый пример):
$query = "SELECT * FROM `items` WHERE `id` = " . ((int) $_GET['id']);
Хорошо, что подписали «грубый пример».
А так бы — Плохая, плохая привычка! на по рукам=)
А так бы — Плохая, плохая привычка! на по рукам=)
Вдруг не понятно =) И бахнут ещё в минус.
Вот у Вас перечислили ну 9 миллиардов денежных единиц. Ну ещё чего нить.
Вот у Вас перечислили ну 9 миллиардов денежных единиц. Ну ещё чего нить.
извиняюсь за парсер, похерил коммент. И так, пример — дубль 2
$integer= (int) 9223372522;
var_dump(integer);
$integer= (int) 9223372522;
var_dump(integer);
Используйте PHP x64, где PHP_INT_MAX 9223372036854775807.
Думайте пользователь не сможет передать такую цифру? :)
а если пользователь передал такую цифру, то это значит, что она корректна? скорее всего в таком случае понадобится или вернуть ексепшн или перейти на использование string'ов вместо int'ов…
Почему цифре быть не корректной? Количество спичек произведённое заводом за 1 год — вот такой у меня пример. =)
Такое количество спичек это приблизительно 1.844E+17 коробков, если один коробок стоит рубль, а за 30 рублей можно купить доллар, то это 6'150'000'000'000'000 $, что в 2700 раз больше, чем ВВП России. Покажите мне такой завод.
Практическая ситуации на предприятии, где PHP_INT_MAX недостаточно большое — невозможна. Если же такое таки случилось, то с вероятностю 99,99 % там используется язык отличный от php)
Практическая ситуации на предприятии, где PHP_INT_MAX недостаточно большое — невозможна. Если же такое таки случилось, то с вероятностю 99,99 % там используется язык отличный от php)
Оно будет заведомо неверное. Мы сейчас о чем говорим? Об ограничениях целочисленного типа (иначе тогда о чем был ваш комментарий) или о том, что пользователь может ввести буквы вместо цифр?
Чем руби нравится что там такого не будет) Автоматом сменит тип на BigNum и там уже числа любой длины)
кстати, а вы выбрали такое число случайно или преднамеренно?
9223372522 - ваше число
9223372036854775807 - PHP_INT_MAX я пользуюсь Квери Билдером, потому уже не думаю о экранизации переменных и, естественно, так, как сказано выше — не пишу. тем не менее, я не понял, зачем в статье сказано «получаем ID извне — сравниваем с нулем;»
Если не ноль — продолжаем иначе зачем продолжать :)
при чем тут «ноль»? если это автоинкремент-id, то, скорее всего, нам не надо продолжать если, например, меньше нуля.
ато получается, что «если в картинке нету синего цвета, то она — чернобелая». ведь в АйДи может стоять какой-нибудь «'», а не ноль
ато получается, что «если в картинке нету синего цвета, то она — чернобелая». ведь в АйДи может стоять какой-нибудь «'», а не ноль
$id = preg_replace("/\D/","",$_POST['id']);
На выходе получаем только цифры. Такое же можно написать и для любых символов.
На выходе получаем только цифры. Такое же можно написать и для любых символов.
в своем самом первом скрипте я так и сделал. сейчас же делаю что-то типа такого:
route('/topic/(\d+)/', function ($args) {
// output topic id # $args[1]
});
route(/* DEFAULT */ function ($args) {
// output 404
});
тогда /topic/a1h2u3y4v5a6m7/ не окажется ссылкой на топик 1234567, а будет вести на 404, что, имхо, логичнее.
route('/topic/(\d+)/', function ($args) {
// output topic id # $args[1]
});
route(/* DEFAULT */ function ($args) {
// output 404
});
тогда /topic/a1h2u3y4v5a6m7/ не окажется ссылкой на топик 1234567, а будет вести на 404, что, имхо, логичнее.
Коротко: 12.3 == 1.23?
А разве intval не работает в разы быстрее preg_replace?
Наверное то, что под многоточием должно скрываться более одного элемента. :)
Видимо то, что страниц всего 5, а «умный» пагинатор выводит(в данном случае) первые 3, потом символ многоточия(типа многа страниц), а потом последнюю(в данном случае 5) и получается, что под многоточием скрывается всего 1 страница, которую в данном случае было бы уместнее показывать. =)
print xxx + 'привычек в наличии'
(Велик и могуч русский язык, и не только русский кстати.)
(Велик и могуч русский язык, и не только русский кстати.)
Привычек в наличии: 2 или 5, или 100 :)
2 привычек в наличии?
А еще появляется русский компьютерный: все фразы составляются так, чтобы не нужно было склонять. Хорошо, что сейчас появляются сайты с нормальными фразами.
В Европе другая проблема: здесь чуть ли не каждый сайт по умолчанию создается на нескольких языках. И очень часто языки воспринимаются как некие одинаковые структуры в которых только буквы меняются.
Отсюда и появляются фразы «привычек в наличии — 10», вместо «опубликовано 10 привычек». Каждый европейский язык подвергается такому грамматическому изнасилованию. Порою даже английский.
Отсюда и появляются фразы «привычек в наличии — 10», вместо «опубликовано 10 привычек». Каждый европейский язык подвергается такому грамматическому изнасилованию. Порою даже английский.
Но с другой стороны ничего страшного лично я не вижу — вполне разумный вариант, читается нормально) Но если язык один — то конечно стоит сделать все правильно)
>Каждый европейский язык подвергается такому грамматическому изнасилованию. Порою даже английский.
да лучше их все изнасиловать и убить, чтобы наконец-то остался один, нормально парсящийся и любым человеком и компютером
да лучше их все изнасиловать и убить, чтобы наконец-то остался один, нормально парсящийся и любым человеком и компютером
Один раз пишется склонятор для наиболее часто употребляемых на сайте существительных, и дальше можно просто везде вставлять нужный вариант.
вот кто бы написал Опен-соурс склонятор с удобным API цены бы ему не было.
Добавлю:
Перед тем как считать средний процент успеваемости в средней школе, убедитесь, что в ней больше нуля учеников :)
Перед тем как считать средний процент успеваемости в средней школе, убедитесь, что в ней больше нуля учеников :)
Главное помнить, что вы создаете продукт для людей, а не для роботов, парсящих ваши страницы с помощью регулярных выражений.
Чем более человечнее будет ваш интерфейс — тем больше будет удовольствие от его использование.
Чем более человечнее будет ваш интерфейс — тем больше будет удовольствие от его использование.
Банально всё, за исключением пункта 1.
Пункт 2 реализуется всеми приличными пейджинаторами.
Пункт 3 — с большими оговорками — и именно там, где его нужно применять — реализуется всевозможными рендерерами форм.
Пункты 4 и 5 — результат банальной культуры верстки / программирования и продуманности макета. Можно точно так же приводить в пример людей, которые пишут комментарии на языках, отличных от английского, называют переменные словами типа «spisok_tovarov» (или еще хуже — «список_товаров») и имеют где-то неинтернационализируемые константы.
Пункт 2 реализуется всеми приличными пейджинаторами.
Пункт 3 — с большими оговорками — и именно там, где его нужно применять — реализуется всевозможными рендерерами форм.
Пункты 4 и 5 — результат банальной культуры верстки / программирования и продуманности макета. Можно точно так же приводить в пример людей, которые пишут комментарии на языках, отличных от английского, называют переменные словами типа «spisok_tovarov» (или еще хуже — «список_товаров») и имеют где-то неинтернационализируемые константы.
Беглое описание наиболее используемого алгоритма для вывода списка страниц:
Чаще всего на четвертом шаге применяют только одну проверку:
— если промежуточных страниц нет, то троеточие не выводим.
Тогда как добавление еще нескольких проверок позволит нам избежать нелепого случая описанного в статье:
стр1, стр2, стр3, ..., стр5
Где вместо троеточия, красиво бы вписалась стр4. А то и несколько промежуточных страниц, если их общее количество не помешает.
По поводу всего комментария в целом: в борьбе между объемом и намеками я выбрал последнее. Излишние рассуждения мешают. А вот намеки работают даже для вас: фейла с окончаниями вы в своих работах не допустите ;)
Хотя иллюстрации, конечно же, не помешали бы.
display pager
{
1 print current page
2 print current page +1
3 print current page +2
4 print '...' // для промежуточных страниц
5 print last page
}Чаще всего на четвертом шаге применяют только одну проверку:
— если промежуточных страниц нет, то троеточие не выводим.
Тогда как добавление еще нескольких проверок позволит нам избежать нелепого случая описанного в статье:
стр1, стр2, стр3, ..., стр5
Где вместо троеточия, красиво бы вписалась стр4. А то и несколько промежуточных страниц, если их общее количество не помешает.
По поводу всего комментария в целом: в борьбе между объемом и намеками я выбрал последнее. Излишние рассуждения мешают. А вот намеки работают даже для вас: фейла с окончаниями вы в своих работах не допустите ;)
Хотя иллюстрации, конечно же, не помешали бы.
Можно узнать, что не так здесь с паджинацией? 'стр5' легко заменяется на что угодно (5, #5, №5).
Насколько я понял, дело в троеточии, которое «как бы» мешает — ну это уже не к программированию относится, а к дизайну интерфейса.
По поводу величины списка — она должна быть фиксированной, и я свято в это верю. Пользователь может быть искренне удивлён, что количество элементов на странице варьируется по фиг знает какому правилу (кстати, количество элементов на страницу довольно часто делают настраиваемой пользователем величиной). Гугл (авторитет) одобряет.
По выводу пустых значений — выводить надо именно значения из БД, если заранее не оговорено иного (а не так что «если заметят, то может быть изменим на что-то другое...»). Если там ничего нет — то и выводится «ничего», хардкод всякого «пусто»/«ничего нет» и тд это явно не лучший вариант.
Итого, получается что всё вышеперечисленное к программированию имеет весьма далёкое отношение, а к пользовательским интерфейсам — самое непосредственное. Привычки у всех свои, приведённые в топике мне видятся однозначно вредными.
Насколько я понял, дело в троеточии, которое «как бы» мешает — ну это уже не к программированию относится, а к дизайну интерфейса.
По поводу величины списка — она должна быть фиксированной, и я свято в это верю. Пользователь может быть искренне удивлён, что количество элементов на странице варьируется по фиг знает какому правилу (кстати, количество элементов на страницу довольно часто делают настраиваемой пользователем величиной). Гугл (авторитет) одобряет.
По выводу пустых значений — выводить надо именно значения из БД, если заранее не оговорено иного (а не так что «если заметят, то может быть изменим на что-то другое...»). Если там ничего нет — то и выводится «ничего», хардкод всякого «пусто»/«ничего нет» и тд это явно не лучший вариант.
Итого, получается что всё вышеперечисленное к программированию имеет весьма далёкое отношение, а к пользовательским интерфейсам — самое непосредственное. Привычки у всех свои, приведённые в топике мне видятся однозначно вредными.
Паджинацию выше уже разжевали, вместо троеточия могла стоять четвертая страница. Робот сам этого не сделает.
Величина списка: ну-ка, не подсматривая скажите сколько постов выводится на первой странице хабра? А если на один больше, то беда?
Пустые значения изумительны, когда они стоят внутри ссылки. Забыл автор заголовок написать, и теперь не может даже щелкнуть по нему, чтобы отредактировать. А мог бы щелкнуть на 'no subject'.
Попробуйте только допустить подобную глупость. Уж я то вам тогда припомню «весьма далекое отношение» к программированию: Р
Величина списка: ну-ка, не подсматривая скажите сколько постов выводится на первой странице хабра? А если на один больше, то беда?
Пустые значения изумительны, когда они стоят внутри ссылки. Забыл автор заголовок написать, и теперь не может даже щелкнуть по нему, чтобы отредактировать. А мог бы щелкнуть на 'no subject'.
Попробуйте только допустить подобную глупость. Уж я то вам тогда припомню «весьма далекое отношение» к программированию: Р
Паджинацию я видел, написали пока я пост печатал. Посчитал излишним это отмечать.
Я не так часто захожу на главную страницу хабра, чтобы это знать. Но Вы правы, это, ну-ка, беда. Количество должно быть строго определено.
Для редактирования заголовка обычно есть специальный элемент управления, а клик по заголовку открывает ссылку (ну или в Вашем случае опционально открывает окно редактирования). К тому же в шаблоне можно не выводить ссылку, если значение пустое.
Повторюсь: глупости написаны у Вас. Сам пост в стиле д'Артаньяна, да и комментарии такого же толка. Пост нужно писать не для того, чтобы показать свою мнимую крутость («ох как мне тут надоело что-то разгребать»), а чтобы поделиться опытом и рассказать новое и не выдавать откровенную чепуху за ценную информацию. И когда в комментариях несколько человек пытаются разжевать о чём же собственно опус-то был — стоит задуматься о том, как писать следующий. Последнее Ваше предложение помножу-ка я на нуль.
Я не так часто захожу на главную страницу хабра, чтобы это знать. Но Вы правы, это, ну-ка, беда. Количество должно быть строго определено.
Для редактирования заголовка обычно есть специальный элемент управления, а клик по заголовку открывает ссылку (ну или в Вашем случае опционально открывает окно редактирования). К тому же в шаблоне можно не выводить ссылку, если значение пустое.
Повторюсь: глупости написаны у Вас. Сам пост в стиле д'Артаньяна, да и комментарии такого же толка. Пост нужно писать не для того, чтобы показать свою мнимую крутость («ох как мне тут надоело что-то разгребать»), а чтобы поделиться опытом и рассказать новое и не выдавать откровенную чепуху за ценную информацию. И когда в комментариях несколько человек пытаются разжевать о чём же собственно опус-то был — стоит задуматься о том, как писать следующий. Последнее Ваше предложение помножу-ка я на нуль.
Это даст некашу в голове, это избавит от дополнительной логики сложных интегральных вычислений текущего количества элементов на странице, это даст возможность разрешать пользователю самому регулировать размер выборки на странице.
Вы просто так поспорить захотели, или есть аргументы когда этот вариант чего-то «не даст»?
Согласно подходу изменяемого количества элементов на странице, пользователь никогда не должен видеть страницу с малым количеством элементов (насколько ясно, это — цель такого подхода). Как быть тогда с последней и предпоследней страницами, их тоже скукоживать если что?
Вы просто так поспорить захотели, или есть аргументы когда этот вариант чего-то «не даст»?
Согласно подходу изменяемого количества элементов на странице, пользователь никогда не должен видеть страницу с малым количеством элементов (насколько ясно, это — цель такого подхода). Как быть тогда с последней и предпоследней страницами, их тоже скукоживать если что?
Например, представьте себе, что у вас фиксированная сетка дизайна: 5х4 элемента на странице, никак иначе.
Последнее предложение было написано с иронией, и надеюсь не оскорбительной.
По поводу списка, мне непонятно почему вы так держитесь за фиксированную величину. Какое из двух зол для вас меньше?:
— переменное количество товаров магазина в разделе «утюги»
— или описанный пример «100 утюгов на первой странице, 1 утюг на второй»
Для редактирования заголовка обычно есть специальный элемент управленияА вот это уже, как вы сами сказали, работа дизайнера-интерфейсера. А ведь он может и не дать программисту такую кнопку. Он ведь считает, что есть кликабельный заголовок.
По поводу списка, мне непонятно почему вы так держитесь за фиксированную величину. Какое из двух зол для вас меньше?:
— переменное количество товаров магазина в разделе «утюги»
— или описанный пример «100 утюгов на первой странице, 1 утюг на второй»
Я говорил что здесь всё — работа проектировщика интерфейсов.
А из описанного примера — «100 утюгов на первой странице» для меня уже наибольшее зло, раз уж об интерфесах.
И если вдруг кто-то наконец догадается сократить выборку до 10-25 на страницу (правим конфиг), то вполне себе получаем пляску по количеству, описанную выше. А может и не получим даже, если будем использовать только два волшебных числа 100 и 120.
А из описанного примера — «100 утюгов на первой странице» для меня уже наибольшее зло, раз уж об интерфесах.
И если вдруг кто-то наконец догадается сократить выборку до 10-25 на страницу (правим конфиг), то вполне себе получаем пляску по количеству, описанную выше. А может и не получим даже, если будем использовать только два волшебных числа 100 и 120.
Не говоря уже о последнем примере с print. Информация пользователю должна выдаваться в шаблонах, тогда и со склонениями проблем не будет, а при нормальной реализации и с мультиязычностью.
В последнее время в интернациональных приложениях использую конструкции следующего вида:
echo sprintf(_('%s habit(s) are published'), $habitsCount);
В результате все фразы можно довольно точно перевести на любой язык.
echo sprintf(_('%s habit(s) are published'), $habitsCount);
В результате все фразы можно довольно точно перевести на любой язык.
* Избегайте текстовок вроде «доступ запрещен», «вы должны» — никто вам ничего не должен. Такие текстовки программисты обычно пишут сами, постарайтесь представить что вы это человеку в глаза говорите.
* Не теряйте сессию. У пользователей возникает огорчение, когда они тратят на комментарий 20 минут, а потом при попытке отправить его попадают на страницу авторизации.
* Если пользователь пытается попасть на страницу, требующую авторизации, то после авторизации кидайте его туда, куда он первоначально хотел попасть.
* Не надо требовать пароль с цифрами и спецсимволами, такие пароли ни капли не надежнее, но очень легко забываются.
* Не теряйте сессию. У пользователей возникает огорчение, когда они тратят на комментарий 20 минут, а потом при попытке отправить его попадают на страницу авторизации.
* Если пользователь пытается попасть на страницу, требующую авторизации, то после авторизации кидайте его туда, куда он первоначально хотел попасть.
* Не надо требовать пароль с цифрами и спецсимволами, такие пароли ни капли не надежнее, но очень легко забываются.
Добавлю парочку:
1. Для удобства восприятия, сегодняшнюю и вчерашнюю даты можно выводить как «Сегодня, 23:13» и «Вчера, 23:13», остальные — как обычно («23 мая, 23:13»).
2. Склонять русские имена и хранить падежные формы имен пользователей в БД, чтобы каждый раз не пересчитывать при выводе.
1. Для удобства восприятия, сегодняшнюю и вчерашнюю даты можно выводить как «Сегодня, 23:13» и «Вчера, 23:13», остальные — как обычно («23 мая, 23:13»).
2. Склонять русские имена и хранить падежные формы имен пользователей в БД, чтобы каждый раз не пересчитывать при выводе.
А иногда лучше выводить относительное значение вместо абсолютного.
Как пример, мне сейчас не очень интересно, что ваш комментарий написан «25 мая 2010, 20:15». Намного полезнее было бы знать, что он написан 10 минут назад.
Как пример, мне сейчас не очень интересно, что ваш комментарий написан «25 мая 2010, 20:15». Намного полезнее было бы знать, что он написан 10 минут назад.
Склонять слова просто:
nano.yandex.ru/project/inflect/
nano.yandex.ru/project/inflect/
пункт 1 ломает стабильность ссылок
А есть постраничный вывод, который не ломает стабильность ссылок?
Тут же на хабре, объект постоянно мигрирует по page2/, page3/, page4/…
Это не ирония, это вопрос. Вдруг знаете хороший способ?
Тут же на хабре, объект постоянно мигрирует по page2/, page3/, page4/…
Это не ирония, это вопрос. Вдруг знаете хороший способ?
это зависит от того что выводим
Обратный порядок страниц. Тогда, как только пост уйдет с главной страницы, он останется на своем URL'е навсегда.
В принципе, речь же об URL'е для поисковиков шла. URL может быть с обратным выводом страниц (для решения проблемы), а внешний вид пагинатора — обычный. Заморь, конечно, но почему нет? :)
Кстати, как то уже была горячая дискуссия на эту тему (и, скорее всего, даже не одна). Сам лично считаю достаточно логичным листание в «обычном» порядке, но нумерацию страниц — в обратном:
(9) 8 7 6 5 ->
Логичным, но чуть менее привычным, нежели (1) 2 3 4 5 ->. Но думаю также, что это дело грамотной визуальной реализации. В некоторых проектах вообще не смотришь на то, какие цифры написаны (хоть бы их даже совсем не было), а уже интуитивно понятно, что находишься «в начале» или «посередине», итд.
А вот листание «задом наперед» (приведенный вами пример) действительно вводит в жесткий диссонанс.
(9) 8 7 6 5 ->
Логичным, но чуть менее привычным, нежели (1) 2 3 4 5 ->. Но думаю также, что это дело грамотной визуальной реализации. В некоторых проектах вообще не смотришь на то, какие цифры написаны (хоть бы их даже совсем не было), а уже интуитивно понятно, что находишься «в начале» или «посередине», итд.
А вот листание «задом наперед» (приведенный вами пример) действительно вводит в жесткий диссонанс.
Именно, идеальной в плане нумерации и нет.
А вот с порядком листания, на мой взгляд, все достаточно ясно.
Будет главная страница сайта первой или последней — второй вопрос, а первый — что все новое точно должно быть в начале листалки — на самой левой странице списка. Это уже точно устоявшаяся привычка.
Это как оценки у нас и на западе — у нас — с 1 до 5, у них (образно) — с 5 до 1. Порядок разный, но все знают, что лучшие ученики всегда вверху рейтинга.
Так же и мы знаем, что самое свежее всегда слева.
А вот с порядком листания, на мой взгляд, все достаточно ясно.
Будет главная страница сайта первой или последней — второй вопрос, а первый — что все новое точно должно быть в начале листалки — на самой левой странице списка. Это уже точно устоявшаяся привычка.
Это как оценки у нас и на западе — у нас — с 1 до 5, у них (образно) — с 5 до 1. Порядок разный, но все знают, что лучшие ученики всегда вверху рейтинга.
Так же и мы знаем, что самое свежее всегда слева.
Но на «главной странице» (в данном случае — это наибольший номер) мы вынуждены писать фиксированное число элементов. А значит количество элементов на странице №1 будет меняться с каждым новым элементом.
список 19 по 10 на странице:
страница 2 — 10 штук (обложка)
страница 1 — 9 штук
добавим три свежих элемента
список 22 по 10:
страница 3 — 10 штук (обложка)
страница 2 — 10 штук
страница 1 — 2 штуки
7 элементов со страницы №1 поменяли свой УРЛ
список 19 по 10 на странице:
страница 2 — 10 штук (обложка)
страница 1 — 9 штук
добавим три свежих элемента
список 22 по 10:
страница 3 — 10 штук (обложка)
страница 2 — 10 штук
страница 1 — 2 штуки
7 элементов со страницы №1 поменяли свой УРЛ
Верно. Нормальная постраничка всегда обратная. Иначе добавление нового элемента передвинет расположение элементов на всех страницах, что для поисковых систем далеко не шоколадно.
Вопрос по «Список страниц для постраничного вывода» а как оно индексируется? Были опыты?
Я исхожу из того, что у постраничного вывода изначально проблемы с индексированием (комментарий выше поднял эту тему).
Возможно я не прав и просто не знаю правильных решений.
Возможно я не прав и просто не знаю правильных решений.
Увидел! Я проводил только один опыт, было 2 учасника.
2 абсолютно нулевых сайта по показателям, смежные тематики, но разные модули постраничной навигации.
Вообщем сейчас уже не помню точное название скриптов. но победил тот у которого постраничная навигация в коде шла списком и css уже делал свое дело. Смотрелось не так компактно как тот пример что здесь, но индексировалось хорошо. а вот второй, с javascript навигацией отставал сильно.
2 абсолютно нулевых сайта по показателям, смежные тематики, но разные модули постраничной навигации.
Вообщем сейчас уже не помню точное название скриптов. но победил тот у которого постраничная навигация в коде шла списком и css уже делал свое дело. Смотрелось не так компактно как тот пример что здесь, но индексировалось хорошо. а вот второй, с javascript навигацией отставал сильно.
Нормальным поисковикам уже давно наплевать на постраничный вывод, и они его понимают нормально.
ИМХО
ИМХО
Хорошая статья, собраны действительно значимые вещи, актуальные для почти любого сайта.
По поводу объектов на странице (10, 10, 11 vs. 10, 10,10,1). В одном из проектов мы применили подход 10,50,100 (пример: www.ratingruneta.ru/netcat/projects/, селектор «Показывать...». Обоснование: вероятность того, что кто-то что-то будет искать именно на N-й странице, отталкиваясь от равного кол-ва объектов на страницу, почти равна 0, поэтому вполне допустимо постепенное увеличение кол-ва объектов.
И по "'опубликовано' + xxx + 'привычек'". Склонять последнюю часть этого выражения очень легко (достаточно заложить всего 3 варианта, а правил выбора всего 4), а если этого не делать, выглядеть подобная фраза будет довольно убого.
По поводу объектов на странице (10, 10, 11 vs. 10, 10,10,1). В одном из проектов мы применили подход 10,50,100 (пример: www.ratingruneta.ru/netcat/projects/, селектор «Показывать...». Обоснование: вероятность того, что кто-то что-то будет искать именно на N-й странице, отталкиваясь от равного кол-ва объектов на страницу, почти равна 0, поэтому вполне допустимо постепенное увеличение кол-ва объектов.
И по "'опубликовано' + xxx + 'привычек'". Склонять последнюю часть этого выражения очень легко (достаточно заложить всего 3 варианта, а правил выбора всего 4), а если этого не делать, выглядеть подобная фраза будет довольно убого.
Интересный вариант. Но меня испугало ваше обоснование.
Если на страницах есть только переходы «next/previous» и отсутствует список всех страниц (применяется в блогах, в том же livejournal), то ваша система прекрасна. Особенно в момент первого шага с главной страницы на вторую.
Но если список страниц присутствует — я бы поостерегся. Все таки мы имеем ряд равнозначных элементов (стр1, стр2, стр3...), значит и их содержание ожидается равнозначным.
Если на страницах есть только переходы «next/previous» и отсутствует список всех страниц (применяется в блогах, в том же livejournal), то ваша система прекрасна. Особенно в момент первого шага с главной страницы на вторую.
Но если список страниц присутствует — я бы поостерегся. Все таки мы имеем ряд равнозначных элементов (стр1, стр2, стр3...), значит и их содержание ожидается равнозначным.
Согласен, если обязательно наличие стр1, стр2, стр3..., то такой вариант не подойдет. Написал, а потом понял, что можно и такое сделать — если вместо стрN писать 1-10, 11-50, 51-100 и т.д.
В голову пришел вариант:
1-9
10-99
100-999
Хочешь элемент с трехзначным номером? Ищи на третьей странице.
Жаль только не могу придумать область применения, где нам надо знать что нужный элемент находится на третьей странице, и при этом тысяча соседей на этой же странице не являются помехой.
1-9
10-99
100-999
Хочешь элемент с трехзначным номером? Ищи на третьей странице.
Жаль только не могу придумать область применения, где нам надо знать что нужный элемент находится на третьей странице, и при этом тысяча соседей на этой же странице не являются помехой.
Идея, мне кажется, неплохая. Дело даже не в том, что нужен именно трехзначный. Всего 3-мя ссылками можно дать список из тысячи элементов. При этом в реальности подавляющему большинству будет достаточно первой страницы, немногие зайдут на вторую, а уж до третьей не дойдет почти никто (просто потому что такая старая информация, скорее всего, уже не нужна). При этом, повторюсь, достаточно всего 3-х элементов.
Ура! Придумал область применения!
«Топ 999 самых богатых людей планеты»
Первую девятку всем интересно внимательно посмотреть, а список не попавших в сотню — можно и длинным оставить :)
«Топ 999 самых богатых людей планеты»
Первую девятку всем интересно внимательно посмотреть, а список не попавших в сотню — можно и длинным оставить :)
можно ведь сделать такой Пагинатор:
1-10, 10-20, 20-50, 50-100, 100-200, 200-500, 500-1000
Это совсем беда, никто не хочет знать, какую по счету статью в списке я читаю. Это абсолютно мусорная информация.
Это очень по-программистски и сильно притянуто за уши.
Сравнивая с «бумажной» типографикой такой пагинатор можно использовать только при алфавитном выводе
A-Г Д-Ж З-К Л-О…
Это очень по-программистски и сильно притянуто за уши.
Сравнивая с «бумажной» типографикой такой пагинатор можно использовать только при алфавитном выводе
A-Г Д-Ж З-К Л-О…
По моему, все опубликованные привычки — спорные.
после рефакторинга статья стала намного лучше, одобряю.
Хм… А я бы назвал «Полезные каждому веб-программисту привычки». Кажется у меня синдром Йоды :)
Работаю фронт-сайд разработчиком, использую эти и подобные принципы. Сбалансированные интерфейсы для Человека с высоким юзабилити — залог высокой производительности пользователей системы.
Оффтоп: Интересно, что цвета h4 заголовков немногим отличается от цвета заминусованных комментов.
4 раз прочитанно.
Я буду хорошим программистом! честное слово!
Я буду хорошим программистом! честное слово!
На бумажку и на стенку.
Еще замечу, что при простановке даты часто пишут текущий год.
Хотя легко можно сделать так:
С языками, кстати, еще одна засада: по-русски правильно «1 апреля», а по-английски — «1st of april»
Хотя легко можно сделать так:
1 апреля
23 марта
2 февраля
30 декабря 2009
С языками, кстати, еще одна засада: по-русски правильно «1 апреля», а по-английски — «1st of april»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Привычки полезные каждому веб-программисту