На мой взгляд, у стандартной постраничной навигации Друпала есть несколько недостатков.

Во-первых, ссылка на последнюю страницу стала бы более информативна и занимала бы меньше места, если её заменить на номер последней страницы [28].


Во-вторых, стоит нам перейти на вторую страницу и мы тут же видим две ссылки на первую страницу: [1] и [Первая]


Аналогичную картину мы видим с противоположной стороны навигационной линейки


Ниже привожу вариант своего решения этих недочетов (для Drupal 6.x)

В прошлой вводной части я немного познакомил тех, кто не был знаком, с элементом GridView, предназначенным для отображения табличной информации на форме. Я рассказал о том, что GridView (для своего удобства я буду называть этот элемент далее везде как гридвью) можно связать с источником данных. Источников может быть несколько типов. В моих примерах везде будет в качестве источника использоваться ObjectDataSource.

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

Были когда-то споры, в какую сторону делать paging: справа — налево, или слева-направо…
Не принимал участия в обсуждении, так как понимал что тут палка о двух концах:
1) Логично, для нашего славянского/европейского мировозрения когда старое слева, а новое справа (стойкая ассоциация с иллюстрацией эволюции человека из обезьяны).
2) Но как элемент управления это правило действительно неудобно, для пользователя важно определить в данный момент его местоположение, и исходя из этого, удобнее, когда страница (выделенный номер страницы) на которой он в находится, расположена справа (текущее местоположение) и остальные слева, по которым можно уйти на предыдущие. Такой paging мы сейчас на Хабре и используем. Я, и думаю многие другие, привыкли к нелогичному направлению хронологии.
И вопрос направления хронологии меня мало-помалу перестал тревожить.