Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
amout:32;page:11
Я обычно #2. Вообще скроллинг лучше пагинации :-)
Делаем сейчас правочный сайт, решили 100 записей на страницу по дефолту выводить :-)
Делаем сейчас правочный сайт, решили 100 записей на страницу по дефолту выводить :-)
Всегда вариант 3, так как он наиболее понятен пользователю, а для программиста легко его реализовать.
«так как он наиболее понятен пользователю»?
хм, как пример вот у нас на Хабре есть раздел «новое» попробуйте за одно действие найти например первую запись за 1 апреля.
хм, как пример вот у нас на Хабре есть раздел «новое» попробуйте за одно действие найти например первую запись за 1 апреля.
название раздела как бы говорит нам, что он не предназначен для поиска материалов по какому-либо критерию, отличному от «новое».
вот, не надо. Новое вполне может быть «надуровнем» «нового за час» или за день или за месяц и так далее, по временным периодам, что позволило бы отсортировать куда более гармонично чем сейчас с цифровым «пагинатором» который практически не несет ни какой информации.
надо, шурик, надо =) новое может быть только одно — с момента последнего посещения.
О_О а почему у меня не с последнего :( и у меня топики по идее устаревать должны моментально, по вашей логике.
В общем, с чего бы это вдруг?
Неужели вы мыслите только на этом уровне абстракций новое/старое? И у вас нет промежуточных этапов таких как вчерашний, прошлогодний и тд и тп?
В общем, с чего бы это вдруг?
Неужели вы мыслите только на этом уровне абстракций новое/старое? И у вас нет промежуточных этапов таких как вчерашний, прошлогодний и тд и тп?
а между состояниями бита у тебя тоже промежуточные этапы есть? ;-)
все меньше вижу смысла в продолжении этой ветки.
мда… зрение у айтишников садится всё быстрее и быстрее =)
Со зрением у меня на отлично, у Вас с доводами что-то ни то… По этой причине и не выходит конструктивной беседы.
мои доводы не изменились. но вначале ты что-то видел, а потом перестал… что это было? потеря зрения? буйная фантазия? или обрыв коннекта с матрицей? =)
Так познакомьте с ними, мои приведены в достаточно осмысленной форме в комментариях к данному топику.
Ну вот, например, клацнул я кнопочку «обновить» справа.
И жду.
И жду.
И жду.
И ничего не обновляется.
Потом я клацаю кнопочку «обновить» снова.
И получаю результат: нет обновлений.
Это потому что первый запрос прошел, но результата почему-то я не получил на экране. ХЗ почему, теперь это уже не узнаешь. А второй запрос на обновление естественно выдал что ничего нового нет.
Если бы была возможность не автоматического обновления, а скажем за «последние 5 минут», или как в почтовике выставлять галочки — «прочитано»/«непрочитано», то мне было бы гораздо удобнее.
Понятно что такой фичи не сделают.
И жду.
И жду.
И жду.
И ничего не обновляется.
Потом я клацаю кнопочку «обновить» снова.
И получаю результат: нет обновлений.
Это потому что первый запрос прошел, но результата почему-то я не получил на экране. ХЗ почему, теперь это уже не узнаешь. А второй запрос на обновление естественно выдал что ничего нового нет.
Если бы была возможность не автоматического обновления, а скажем за «последние 5 минут», или как в почтовике выставлять галочки — «прочитано»/«непрочитано», то мне было бы гораздо удобнее.
Понятно что такой фичи не сделают.
Подобное отследить несколько сложно, разве что отравлять ответ серверу только при удачном обновлении, в голове вертится решение но что-то сформулировать не могу.
Но если что в данной ветке разговор идет немого о другом уровне а не о комментариях к статье которые в данному случае выводятся общим списком в отличии от постраничного вывода топиков.
Но если что в данной ветке разговор идет немого о другом уровне а не о комментариях к статье которые в данному случае выводятся общим списком в отличии от постраничного вывода топиков.
а если интернет завис, или лаг какой был, и запрос на получение «нового» отправился, а результата ты не получил?
а если браузер два раза отправил запрос? например, блядские Огнелис и Конкьюрор
так вот, потеряется при этом всё новое нахуй.
а если браузер два раза отправил запрос? например, блядские Огнелис и Конкьюрор
так вот, потеряется при этом всё новое нахуй.
Вы о чём? Несколько раз перечитал и вникнуть не могу что потеряется? Куад? Не могли бы вы прояснить, если не сложно?
и ты не знаешь как решить эту элементарную проблему? и почтой никогда не пользовался? =)
а тебе не кажется что это воркэраунд, а не настоящее решение проблемы?
у меня сейчас горячую воду отключили. я, конечно, могу помыться через чайник, и так скорее всего и будет. но из крана как-то удобнее.
у меня сейчас горячую воду отключили. я, конечно, могу помыться через чайник, и так скорее всего и будет. но из крана как-то удобнее.
а какое ты видишь настоящее? с чтением мыслей? ;-)
ну, например после загрузки страницы через три секунды аяксом отправляется на сервер сообщение, что страница действительно доставлена пользователю. если подтверждение на сервер не пришло, то страница считается не загруженной и /new не изменится. как вариант, задержку можно устанавливать вручную в профиле пользователя.
а, вот еще пример. У меня братан делал управление электростанцией через веб-интерфейс. Скорее всего, им еще пользуются.
Рядом, конечно, только маленькая деревенька, и если что — жертв будет не так много :)
Рядом, конечно, только маленькая деревенька, и если что — жертв будет не так много :)
А причем ту третий вариант, раздел Новое и 1 апреля, не вижу связи между обычной постраничной навигации как в книге(третий вариант) и тем что Вы описали. На хабре как раз используется третий вариант, но причем тут конкретная дата я понять не могу.
Сейчас дописываем модуль для «бесстраничного» вывода данных с автоматической выгрузкой и загрузкой новых элементов через js.
Страницы это рудимент «физических» изданий (книги, журналы & etc). Обосновано разве, что замена цифрового «пагинатора» смылловым-содержанием, другими словами делить не по количеству записей а по их содержанию группировать.
Страницы это рудимент «физических» изданий (книги, журналы & etc). Обосновано разве, что замена цифрового «пагинатора» смылловым-содержанием, другими словами делить не по количеству записей а по их содержанию группировать.
как сделаешь, свисни.
Хочется посмотреть
Хочется посмотреть
Красиво, удобно, да!
Но.
Это ПОЛЬЗОВАТЕЛЬ видит сайт как веб-приложение.
А вот поисковик видит его как набор страниц. Это даже ужасней, чем печатное издание.
И с точки зрения эффективности рекламы, мнение поисковика о том, как должен быть устроен сайт — в явном приоритете.
И если это обычный сайт компании, то делается он не для изысков на JS, а для того чтобы повысить продажи.
В чем я не прав?
Но.
Это ПОЛЬЗОВАТЕЛЬ видит сайт как веб-приложение.
А вот поисковик видит его как набор страниц. Это даже ужасней, чем печатное издание.
И с точки зрения эффективности рекламы, мнение поисковика о том, как должен быть устроен сайт — в явном приоритете.
И если это обычный сайт компании, то делается он не для изысков на JS, а для того чтобы повысить продажи.
В чем я не прав?
Смотрите во первых при отключенном js на странице будет присутствовать пагинатор в том или ином виде, соответственно поисковик все запарсит без проблем а пользователь перешедший по ссылке попадет именно к той части общего списка которая соответствует его поисковому запросу.
«А вот поисковик видит его как набор страниц.»
По вашему какая инфа была бы релевантней для документа который разбит на несколько страниц и пагинатор в первом случае был бы: 1,2,3..., а во втором: предисловие, вступление, глава первая — «вакханалия в старом замке»...?
«А вот поисковик видит его как набор страниц.»
По вашему какая инфа была бы релевантней для документа который разбит на несколько страниц и пагинатор в первом случае был бы: 1,2,3..., а во втором: предисловие, вступление, глава первая — «вакханалия в старом замке»...?
.../page-10
3 вариант. Всегда использовал и буду. Потому, что в книге так же идут страницы, а не диапазон абзацев :) Для человека такая нумерация более понятна.
На малоскоростных каналах, если страница не докачалася, второй вариант дозволяет пользователю продолжить чтение с середины: ...&skip=53
третий вариант. пользователю более понятен.
кроме этого пытаюсь использовать mod_rewrite, чтобы URL были понятными пользователю: example.com/news/3
кроме этого пытаюсь использовать mod_rewrite, чтобы URL были понятными пользователю: example.com/news/3
Третий вариант, тоже mod_rewrite, только
example.com/news/page3.html
p.s. Почему никто не ставит в конце ".html"?
example.com/news/page3.html
p.s. Почему никто не ставит в конце ".html"?
а зачем ставить html, особенно если это нифига не html, и даже не скрипт?
Как же не html? Страничка ведь приходит в html?
Адрес вида example.com/news/3/ — указывает как-то в никуда, просто в каталог (так уж повелось, что все теперь мыслят путями к файлам)
example.com/news/3 — указывает на нечто «3» — а что это? картинка? скрипт? страница?
Раз уж указываете в ссылках на JPG — ".jpg" (неважно как он там появляется, может и автоматом генерится), то почему на HTML не указать ".html"?
Адрес вида example.com/news/3/ — указывает как-то в никуда, просто в каталог (так уж повелось, что все теперь мыслят путями к файлам)
example.com/news/3 — указывает на нечто «3» — а что это? картинка? скрипт? страница?
Раз уж указываете в ссылках на JPG — ".jpg" (неважно как он там появляется, может и автоматом генерится), то почему на HTML не указать ".html"?
1. «так уж повелось, что все теперь мыслят путями к файлам»
исключительно веб-разработчики на PHP мыслят адрес сайта как путь к файлу. Обычные люди даже примерно не представляют, как это работает (то что скриптики кладутся в папочку по FTP).
разработчики на Java/Python парсят URL с помощью роутера, управляющего сайтом. На сайте обычно вообще нет никаких «скриптов», к которым можно обращаться.
Если вспомнить матчасть, URI — это идентификатор ресурса. WWW перед именем домена обозначает что всё, что находится в этой области — так или иначе открывается веб-браузером, или по крайней мере имеет отношение к вебу.
То что «3.jpg» является обязательно JPEG-файлом — это легенда пользователей Windows, ведь винда не умеет распознавать файлы иначе. Но даже в Windows по умолчанию отключены расширения, поэтому пользователь всегда видит файл с названием «3».
В Линуксе с этим как-то попроще. Например, в проводнике можно посмотреть первые строчки текстового файла прямо на иконке этого файла.
Но это еще не всё. Пусть его, этот самый JPG, в конце концов это статический файл.
А вот при обращении к _ресурсу_ example.com/news/3/ — это очень сложное обращение. Сначала серверу example.com отправляется желание пользователя получить какой-то абстрактный ресурс "/news/3/". Потом, в зависимости от технологии, сервер выбирает веб-приложение, которое будет обрабатывать этот запрос. Например, "/news" обрабатывается программой NewsDispatcher. Потом этой самой программе отправляется запрос на получение ресурса "/3/". Она его анализирует, определяет что нужно выдать и уже выдает.
Причем, в принципе, по одному и тому же адресу может выдавать разные вещи. То есть, например, на сайте example.com в профиле пользователя можно поставить галочку «выдавать все ресурсы через RSS», и тогда по адресу «example.com/news/3/» будет лежать RSS, а можно выдавать по ATOM, а можно вообще по браузерочитаемому HTML.
Говорить что ресурс /3/, обрабатываемый программой NewsDispatcher — это «просто веб-страничка» значит ничего не сказать простому юзверю, а веб-разработчика ввести в неприятное заблуждение о статичности получаемого контента.
исключительно веб-разработчики на PHP мыслят адрес сайта как путь к файлу. Обычные люди даже примерно не представляют, как это работает (то что скриптики кладутся в папочку по FTP).
разработчики на Java/Python парсят URL с помощью роутера, управляющего сайтом. На сайте обычно вообще нет никаких «скриптов», к которым можно обращаться.
Если вспомнить матчасть, URI — это идентификатор ресурса. WWW перед именем домена обозначает что всё, что находится в этой области — так или иначе открывается веб-браузером, или по крайней мере имеет отношение к вебу.
То что «3.jpg» является обязательно JPEG-файлом — это легенда пользователей Windows, ведь винда не умеет распознавать файлы иначе. Но даже в Windows по умолчанию отключены расширения, поэтому пользователь всегда видит файл с названием «3».
В Линуксе с этим как-то попроще. Например, в проводнике можно посмотреть первые строчки текстового файла прямо на иконке этого файла.
Но это еще не всё. Пусть его, этот самый JPG, в конце концов это статический файл.
А вот при обращении к _ресурсу_ example.com/news/3/ — это очень сложное обращение. Сначала серверу example.com отправляется желание пользователя получить какой-то абстрактный ресурс "/news/3/". Потом, в зависимости от технологии, сервер выбирает веб-приложение, которое будет обрабатывать этот запрос. Например, "/news" обрабатывается программой NewsDispatcher. Потом этой самой программе отправляется запрос на получение ресурса "/3/". Она его анализирует, определяет что нужно выдать и уже выдает.
Причем, в принципе, по одному и тому же адресу может выдавать разные вещи. То есть, например, на сайте example.com в профиле пользователя можно поставить галочку «выдавать все ресурсы через RSS», и тогда по адресу «example.com/news/3/» будет лежать RSS, а можно выдавать по ATOM, а можно вообще по браузерочитаемому HTML.
Говорить что ресурс /3/, обрабатываемый программой NewsDispatcher — это «просто веб-страничка» значит ничего не сказать простому юзверю, а веб-разработчика ввести в неприятное заблуждение о статичности получаемого контента.
Вот, кстати, с приходом возможности создавать «красивые ссылки» и ЧПУ я ни как не могу понять глубинный смысл постфиксов типа .html, веры в то что это чудо делается из благих намерений для поисковиков — нет :)
можно же использовать фрэймворки, которые на автомате занимаются красивыми URL'ами? Django, например
Django? я не пишу на Python'е.
кроме того, зачем мне использовать framework, если можно решить этот вопрос куда быстрее и без лишних «примочек»?
кроме того, зачем мне использовать framework, если можно решить этот вопрос куда быстрее и без лишних «примочек»?
для уменьшения сложности
— mod_rewrite решает эту проблему на стороне web-сервера Apache.
— Django «Django runs through each URL pattern, in order, and stops at the first one that matches the requested URL.». т.е. это выполняет не we-сервер, а сам framework. не вижу тут какого-либо плюса.
это на первый взгляд по поводу сложности со стороны тех. части.
— настройка mod_rewrite для красивых URL занимает не больше 5-ти минут.
— Django «Django runs through each URL pattern, in order, and stops at the first one that matches the requested URL.». т.е. это выполняет не we-сервер, а сам framework. не вижу тут какого-либо плюса.
это на первый взгляд по поводу сложности со стороны тех. части.
— настройка mod_rewrite для красивых URL занимает не больше 5-ти минут.
...?start=1&end=10
не применяю т.к это дает вольность пользователю, а еще лучше роботу и хакеру. Можно ввести ...?start=1&end=100000000000, а значит нужно делать дополнительные проверки.
Использую вариант три всегда, т.е /page/2/ и так далее, а размер страницы константа в коде.
не применяю т.к это дает вольность пользователю, а еще лучше роботу и хакеру. Можно ввести ...?start=1&end=100000000000, а значит нужно делать дополнительные проверки.
Использую вариант три всегда, т.е /page/2/ и так далее, а размер страницы константа в коде.
>>>когда указывается просто номер страници а разработчик потом сам вычисляет с какой позиции и сколько нужно выбрать
представил специально обученного разарботчика, который перхватывает реквесты, вычисляет и шлет респонсы :)))
мысль тут сквозит — 3 вариант удобнее для пользователя.
объясните тупому, чем?
да хоть в килограммах или фунтах вычисляйте.
представил специально обученного разарботчика, который перхватывает реквесты, вычисляет и шлет респонсы :)))
мысль тут сквозит — 3 вариант удобнее для пользователя.
объясните тупому, чем?
да хоть в килограммах или фунтах вычисляйте.
На своем сайте/движке делаю вот так:
Как было на недосуперхабре.
Как было на недосуперхабре.
У себя всегда ориентируюсь на статический контент. Поэтому обычно используется унифицированный формат:
/section/
/section/2.html
/section/N.html
…
Либо:
/section/
/section,2/
/section,3/
…
А, вообще, вид ссылок не принципиален, т.к. прозрачно трансформируется в вызов объекта через мапинг URI ссылок.
/section/
/section/2.html
/section/N.html
…
Либо:
/section/
/section,2/
/section,3/
…
А, вообще, вид ссылок не принципиален, т.к. прозрачно трансформируется в вызов объекта через мапинг URI ссылок.
когда таких маппингов будет под сотню — взвоешь горючими слезами.
Почему? Вместо одной записи вида
'/section/ => my_section_handler',
появляется или две:
'/section/ => my_section_handler',
'/section/(\d+)\.html => my_section_handler($1)',
или одна:
'/section/((\d+)\.html)? => my_section_handler($2)',
где тут сотня (лишних) маппингов?
'/section/ => my_section_handler',
появляется или две:
'/section/ => my_section_handler',
'/section/(\d+)\.html => my_section_handler($1)',
или одна:
'/section/((\d+)\.html)? => my_section_handler($2)',
где тут сотня (лишних) маппингов?
на каждый тип страницы у тебя будет по маппингу. сотня типов — сотня маппингов.
вывод списка секций и вывод одной секции — это совсем разные вещи. зачем их все роутить на один хэндлер?
вывод списка секций и вывод одной секции — это совсем разные вещи. зачем их все роутить на один хэндлер?
Да, естественно, что каждый тип — свой хэндлер и свой маппинг.
Но я не представляю себе проект, где будут сотни разных типов объектов :)
У меня в самых толстых проектах не бывало больше нескольких десятков типов объектов.
И в любом случае смотреть надо не на абсолютные, а на относительные цифры. Даже в случае, когда объект состоит из десятка строк кода и десятка строк шаблона, одна строка привязки — это ничтожно :) А уж когда объект ещё более сложный…
Наконец — объекты _в любом_ случае нужно как-то привязывать к ссылкам. Так почему бы в этой привязке сразу же и механизм постраничного разбиения не указать?
Но я не представляю себе проект, где будут сотни разных типов объектов :)
У меня в самых толстых проектах не бывало больше нескольких десятков типов объектов.
И в любом случае смотреть надо не на абсолютные, а на относительные цифры. Даже в случае, когда объект состоит из десятка строк кода и десятка строк шаблона, одна строка привязки — это ничтожно :) А уж когда объект ещё более сложный…
Наконец — объекты _в любом_ случае нужно как-то привязывать к ссылкам. Так почему бы в этой привязке сразу же и механизм постраничного разбиения не указать?
значит у тебя не было действительно толстых проектов ;-)
почему бы не использовать единое правило роутинга для всех хэндлеров?
я, например, параметры передаю так: d-o-b.ru/?article:hiqus
а конкретный хэндлер определяется по набору ключей.
например, для упомянутой выше ссылки будет вызван action/article/get.inc
а для ссылки ?article/list будет вызван action/article/list/get.inc
при этом глядя на ссылку я чётко понимаю какой файл вызывается и нет необходимости мысленно матчить реврайты…
почему бы не использовать единое правило роутинга для всех хэндлеров?
я, например, параметры передаю так: d-o-b.ru/?article:hiqus
а конкретный хэндлер определяется по набору ключей.
например, для упомянутой выше ссылки будет вызван action/article/get.inc
а для ссылки ?article/list будет вызван action/article/list/get.inc
при этом глядя на ссылку я чётко понимаю какой файл вызывается и нет необходимости мысленно матчить реврайты…
Или у нас разная оценка толщины :)
>почему бы не использовать единое правило роутинга для всех хэндлеров? я, например, параметры передаю так: d-o-b.ru/?article:hiqus
Так для такого случая мой метод точно также работает, как и для каждой отдельной прописи.
'/sections/(\w+)/(\d+)\.html => sections_loader($1, $2)',
А внутри sections_loader:
function pre_action() { $handler = object_loader('prefix_'.$this->id()); $handler->set_page($this->page()); return $handler; }
>при этом глядя на ссылку я чётко понимаю какой файл вызывается и нет необходимости мысленно матчить реврайты…
Ну, у меня обычно реврайт вообще только один. Если нет такого статического файла — то на общий лоадер :)
И, вообще, я не понимаю, зачем нужны ссылки вида ?article/list, если можно сразу вызывать /article/list/ :)
>почему бы не использовать единое правило роутинга для всех хэндлеров? я, например, параметры передаю так: d-o-b.ru/?article:hiqus
Так для такого случая мой метод точно также работает, как и для каждой отдельной прописи.
'/sections/(\w+)/(\d+)\.html => sections_loader($1, $2)',
А внутри sections_loader:
function pre_action() { $handler = object_loader('prefix_'.$this->id()); $handler->set_page($this->page()); return $handler; }
>при этом глядя на ссылку я чётко понимаю какой файл вызывается и нет необходимости мысленно матчить реврайты…
Ну, у меня обычно реврайт вообще только один. Если нет такого статического файла — то на общий лоадер :)
И, вообще, я не понимаю, зачем нужны ссылки вида ?article/list, если можно сразу вызывать /article/list/ :)
когда тебе потребуется внутри /sections/ поместить кучу разных страниц — придётся писать либо кучу реврайтов, либо прописывать все дочерние хэндлеры в sections_loader, что есть те же яйца, но в профиль.
затем, чтобы по урлу было видно либо он роутится на хэндлер, либо нет. а зачем делать псевдостатику и потом ковыряться в конфликтах между реврайтами и реальными файлами?
затем, чтобы по урлу было видно либо он роутится на хэндлер, либо нет. а зачем делать псевдостатику и потом ковыряться в конфликтах между реврайтами и реальными файлами?
>когда тебе потребуется внутри /sections/ поместить кучу разных страниц — придётся писать либо кучу реврайтов, либо прописывать все дочерние хэндлеры
Я же привёл пример, как одним реврайтом и одним мапингом мы можем прописать любое количество хэндлеров.
И мой пример кроме формата URL (более человекопонятного) [i]от твоего ничем не отличается[/i] :)
>затем, чтобы по урлу было видно либо он роутится на хэндлер, либо нет
В формате URL лучше ориентироваться на пользователя, а не на программиста.
>а зачем делать псевдостатику
Например, затем, что она позволяет включить статическое кеширование, которое сразу на пару-тройку порядков повысит производительность сервера :)
>и потом ковыряться в конфликтах между реврайтами и реальными файлами?
А их и нет в моём случае.
Я же привёл пример, как одним реврайтом и одним мапингом мы можем прописать любое количество хэндлеров.
И мой пример кроме формата URL (более человекопонятного) [i]от твоего ничем не отличается[/i] :)
>затем, чтобы по урлу было видно либо он роутится на хэндлер, либо нет
В формате URL лучше ориентироваться на пользователя, а не на программиста.
>а зачем делать псевдостатику
Например, затем, что она позволяет включить статическое кеширование, которое сразу на пару-тройку порядков повысит производительность сервера :)
>и потом ковыряться в конфликтах между реврайтами и реальными файлами?
А их и нет в моём случае.
не, твой пример нифига не понятен %-(
ну да, какже, человекопонятен. как человек догадается что означают эти циферки?
пользователь тыкает на ссылки, а вот с урлами приходится возиться программисту.
кверистринг «статическому кэшированию» тоже как бы не особо мешает
ну да, какже, человекопонятен. как человек догадается что означают эти циферки?
пользователь тыкает на ссылки, а вот с урлами приходится возиться программисту.
кверистринг «статическому кэшированию» тоже как бы не особо мешает
>кверистринг «статическому кэшированию» тоже как бы не особо мешает
Мешает абсолютно :)
/section/?action=list
и
/section/?action=new
будут указывать на один файл.
>пользователь тыкает на ссылки, а вот с урлами приходится возиться программисту.
Ну, это очень трудно догадаться, что класс, обрабатывающий /section/list/ надо искать в classes/section/list.php, а /section/new/ в classes/section/new.php :)
Мешает абсолютно :)
/section/?action=list
и
/section/?action=new
будут указывать на один файл.
>пользователь тыкает на ссылки, а вот с урлами приходится возиться программисту.
Ну, это очень трудно догадаться, что класс, обрабатывающий /section/list/ надо искать в classes/section/list.php, а /section/new/ в classes/section/new.php :)
гм… а зареврайтить на разные файлы — никак? %-)
ну это в простейшем случае. а вот что-нить по сложнее:
/posts/2009/04/03/3/20/xxx/
как тут можно догадаться, что это посты по тэгу xxx на третее апреля сего года с третьей страницы при кол-ве 20 штук на страницу?
ну это в простейшем случае. а вот что-нить по сложнее:
/posts/2009/04/03/3/20/xxx/
как тут можно догадаться, что это посты по тэгу xxx на третее апреля сего года с третьей страницы при кол-ве 20 штук на страницу?
>гм… а зареврайтить на разные файлы — никак? %-)
А зачем когда единая точка входа во фреймворк во всех смыслах удобнее?
>а вот что-нить по сложнее: /posts/2009/04/03/3/20/xxx/
1. А это уже сразу по формату видно, что уникальный, а не типичный случай. Его мапить отдельно
'/posts/(\d{4}/\d{2}/\d{2}/\d+/\d+)/ => my_handler($1)'
2. Если же это что-то типа унифицированного по примеру ранее /parts/posts/2009/04/03/3/20/xxx/ — то тупо передавать 2009/04/03/3/20/xxx внутрь класса parts_posts и пусть он сам разбирается, что с этим форматом делать. list($year, $month, $day, $page, $per_page) = explode('/', $id);
А зачем когда единая точка входа во фреймворк во всех смыслах удобнее?
>а вот что-нить по сложнее: /posts/2009/04/03/3/20/xxx/
1. А это уже сразу по формату видно, что уникальный, а не типичный случай. Его мапить отдельно
'/posts/(\d{4}/\d{2}/\d{2}/\d+/\d+)/ => my_handler($1)'
2. Если же это что-то типа унифицированного по примеру ранее /parts/posts/2009/04/03/3/20/xxx/ — то тупо передавать 2009/04/03/3/20/xxx внутрь класса parts_posts и пусть он сам разбирается, что с этим форматом делать. list($year, $month, $day, $page, $per_page) = explode('/', $id);
при «статическом кэшировании» до этой точки запрос не доходит
вот, о чём я и говорил — чтобы узнать какой хэндлер будет вызван, нужно прошерстить все правила на предмет совпадения. и кто-нибудь обязательно перепутает page и amount местами. и параметр из середины придётся указывать всегда, без возможности положиться на дэфолт.
вот, о чём я и говорил — чтобы узнать какой хэндлер будет вызван, нужно прошерстить все правила на предмет совпадения. и кто-нибудь обязательно перепутает page и amount местами. и параметр из середины придётся указывать всегда, без возможности положиться на дэфолт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А как Вы делаете Pagination на своих сайтах