Как сделать пагинацию (отстраничиватель)?

[флоппик]

Но не нравится мне наличие Select в контроллере. Получается, что у нас есть DbTable, есть Mapper, есть Model и всё равно в итоге мы имеем в контроллере Select с передачей параметров для фильтрации, джойнами и т.п. Есть мнения, рекомендации?

Там для этого есть Zend_Paginator_AdapterAggregate — http://framework.zend.com/manual/ru/zend.paginator.advanced.html
Тебе надо просто научить пагинатор ходить непосредственно по мапперу или модели.

 

[lagoff]

AmdY

внутри тот же код с отдельным пэеджером и моделью.

Так это совсем другое дело. Это хардкодинг зависимости, а не хардкодинг логики вычисления оффсета из абстрактного понятия "страница".
В этом случае это спор ни о чем, ибо подходы практически одинаковые.

А у меня железное - меньше писать кода, в разы

Для примера с инъекцией, который я приводил, кода будет одинаково.
Разница заключается лишь в том, кто по факту создает зависимость. В вашем случае это модель, в моем - контроллер.
Единственный минус для вашего подхода - неявность порождения самого экземляра пейджинга, с точки зрения контроллера. Но это может быть и плюсом в некотором роде.

Я вообще говорил о другом: что пейджинг не должен знать о модели в принципе. Модель о пейджинге, как носителе сервиса вычисления offset'a, может знать, но не обязана.

 

[lagoff]

Вот! Вот на примерах кода и всплывают махровые теоретики!

Ой, чорт, спалился. Я вот не понимаю, откуда у вас такое неистребимое желание оскорбить или унизить других? Вы этим какие-то свои физические или моральные недостатки компенсируете что ли?

Замечательный пример — нарушена и инкапсуляция, и полиморфизм.

Да ладно. Не вижу. Аргументировать сможете?

 

[AmdY]

В вашем случае это модель, в моем - контроллер.

В этом и суть, засунув в модель однажды этот код, можно навсегда о нём забыть и дёргать метод, а в вашем варианте нужно каждый раз хардкодить в контроллере. Да, теоретически разница маленькая, а практически профит огромный. Вариант с контроллером тоже можно сделать человеческим выделив в отдельный метод принимающий модель, тогда вариант получится даже лучше моего за счёт доступности переменных request-а.

 

[Absinthe]

Даже в модель пихать не надо, надо лишь сделать динамически добавляемую примесь к модели.

 

[lagoff]

а практически профит огромный.

Ну я определенно не вижу профита

// Метод #1: внедрение зависимости
$pager = Pager::factory()->setCurrentPage($_GET['page']);
$data  = $model->where(...)->order(...)->fetchWithPager($pager);
// работа с шаблонизатором

// Метод #2: хардкодинг зависимости
$data  = $model->where(...)->order(...)->fetchWithPager($_GET['page'], $_GET['limit']);
$pager = $model->getPager();
// работа с шаблонизатором

Первый случай более гибкий с точки зрения создания и предварительной настройки опций пейджинга - мы независимы от сигнатуры метода.
Второй случай позволяет не создавать отдельно $pager, а сразу запихивать в шаблонизатор, как $model->getPager();
Первый случай завязывается только на интерфейс
Второй на интерфейс + класс

Нет, профита тут не будет явного.

Профит возникнет тогда, когда мы привлечем сюда третьего участника, который будет знать и о модели, и о пейджинге и инкапсулировать логику fetch через пейджер напрямую. При этом ни модель не будет знать и пейджинге, ни педжинг о модели.

 

[lagoff]

Даже в модель пихать не надо, надо лишь сделать динамически добавляемую примесь к модели.

Это технология исполнения, от зависимости модели от пейджинга мы никуда не уходим.

 

[AmdY]

Первый случай более гибкий с точки зрения создания и предварительной настройки опций пейджинга

гибче где? метод возвращает массив с данными и объектом пэйджера, который можно точно так же настраивать, перестраивать, причём делать при желании во вьюхе, где этому и место.

вы теорезируете о мифической гибкости, а на практике такой подход применяю годами и он значительно гибче и легко внедряется в любой фреймворк.

 

[Absinthe]

от зависимости модели от пейджинга мы никуда не уходим.

Чо?
Примесь делает возможным брать страницу с модельки.
Кусочком строчки(->page($page)).

Куда уж проще?
Никакой зависимости модели нет, это делается автоматически. Примесью.

 

[lagoff]

вы теорезируете о мифической гибкости,

AmdY, честно, надоело уже аргументы приводить и с примерами расписывать.
Нравится? Пользуетесь? Ну и пользуйтесь. Я же вас не заставляю не пользоваться.

Все равно разницы никакой нет. Я это уже аргументировал выше... Спор ни о чем.

 

[lagoff]

Чо?
Примесь делает возможным брать страницу с модельки.
Кусочком строчки(->page($page)).

Куда уж проще?
Никакой зависимости модели нет, это делается автоматически. Примесью.

Как вы опеределяете класс, с примесями или без - тут значения не имеет, т.к. экземпляр класса все равно монолитен.

 

[Absinthe]

т.к. экземпляр класса все равно монолитен.

0_O
Примесь добавит ему новых возможностей.