[PHP/ZF] Zend_Paginator

[NielsNL]

Modbreak:

Dit topic is afgesplitst van De Devschuur Coffee Corner

Hoe doen jullie dat?
Ik heb een lijst, die verdeel ik over meerdere paginas:

SQL:

"SELECT * FROM users WHERE (nickname LIKE '%".$name."%' OR email LIKE '%".$name."%')ORDER by id ASC limit $offset, $itemsPerPage";

Om nu te weten hoeveel paginas ik nodig heb, gebruik ik een 2e query:

SQL:

"SELECT id FROM users WHERE (nickname LIKE '%".$name."%' OR email LIKE '%".$name."%')";

Om daarop alleen een num_rows op los te laten.
Is dit nou echt nodig, of zijn hier beter manieren voor?

[ Voor 8% gewijzigd door Woy op 23-09-2009 10:49 ]

[.oisyn]

Ik zou gewoon COUNT(*) selecten om te tellen, ipv tegen de database te zeggen dat ie alle resultaten moet returnen om vervolgens alleen maar in het aantal geïnteresseerd te zijn.

[ Voor 21% gewijzigd door .oisyn op 22-09-2009 13:30 ]

[Janoz]

Wel eens van COUNT() gehoord?

[mithras]

Ik gebruik een paginator klasse, maar intern doet deze eerst een COUNT(*) en vervolgens kan je de limiet instellen. Dan kan je de count opslaan en bij elke volgende / vorige pagina die count gebruiken en hoef je alleen dat beperkt aantal entries op te halen. Dat lijkt me wat makkelijker dan eerst alles ophalen en in php het te gaan sorteren

[Koetjeboe]

COUNT(*) zou ik ook aanraden, in mijn ervaring, zeker bij de wat complexere queries icm veel results, een stuk sneller.

[ Voor 7% gewijzigd door Koetjeboe op 22-09-2009 13:32 ]

[NielsNL]

.oisyn schreef op dinsdag 22 september 2009 @ 13:28:
Ik zou gewoon COUNT(*) selecten om te tellen, ipv tegen de database te zeggen dat ie alle resultaten moet returnen om vervolgens alleen maar in het aantal geïnteresseerd te zijn.

Janoz schreef op dinsdag 22 september 2009 @ 13:30:
Wel eens van COUNT() gehoord?

mithras schreef op dinsdag 22 september 2009 @ 13:30:
Ik gebruik een paginator klasse, maar intern doet deze eerst een COUNT(*) en vervolgens kan je de limiet instellen. Dan kan je de count opslaan en bij elke volgende / vorige pagina die count gebruiken en hoef je alleen dat beperkt aantal entries op te halen. Dat lijkt me wat makkelijker dan eerst alles ophalen en in php het te gaan sorteren

Koetjeboe schreef op dinsdag 22 september 2009 @ 13:31:
COUNT(*) zou ik ook aanraden, in mijn ervaring, zeker bij de wat complexere queries icm veel results, een stuk sneller.

COUNT is will be!

[RAJH]

NielsNL schreef op dinsdag 22 september 2009 @ 13:20:
Hoe doen jullie dat?
Ik heb een lijst, die verdeel ik over meerdere paginas:

SQL:

"SELECT * FROM users WHERE (nickname LIKE '%".$name."%' OR email LIKE '%".$name."%')ORDER by id ASC limit $offset, $itemsPerPage";

Om nu te weten hoeveel paginas ik nodig heb, gebruik ik een 2e query:

SQL:

"SELECT id FROM users WHERE (nickname LIKE '%".$name."%' OR email LIKE '%".$name."%')";

Om daarop alleen een num_rows op los te laten.
Is dit nou echt nodig, of zijn hier beter manieren voor?

Je kunt ook gebruik maken van SQL_CALC_FOUND_ROWS in combinatie met FOUND_ROWS() indien je MySQL gebruikt. Meer informatie is te vinden op http://dev.mysql.com/doc/....html#function_found-rows.

[NielsNL]

RAJH schreef op dinsdag 22 september 2009 @ 14:02:
[...]


Je kunt ook gebruik maken van SQL_CALC_FOUND_ROWS in combinatie met FOUND_ROWS() indien je MySQL gebruikt. Meer informatie is te vinden op http://dev.mysql.com/doc/....html#function_found-rows.

Ik heb het toch bij COUNT(*) gehouden, dat was iets eenvoudiger.
Ik gebruik dit voor een zoek functie i.c.m. jQuery en ajax. Als er interesse is, wil ik dat hier wel posten...

[japaveh]

mithras schreef op dinsdag 22 september 2009 @ 13:30:
Ik gebruik een paginator klasse, maar intern doet deze eerst een COUNT(*) en vervolgens kan je de limiet instellen. Dan kan je de count opslaan en bij elke volgende / vorige pagina die count gebruiken en hoef je alleen dat beperkt aantal entries op te halen. Dat lijkt me wat makkelijker dan eerst alles ophalen en in php het te gaan sorteren

Om hier eventjes op in te haken, we staan immers toch in de koffiehoek

Ik heb binnen het ZF ook zoiets geprobeerd te doen. Daarbij kun je onder andere 2 opties gebruiken:

PHP:

$runList = array(..) //array gevormd door het model
$paginator = new Zend_Paginator(new Zend_Paginator_Adapter_Array($runList));

Nu is dit niet de meest ideale oplossing omdat die $runList alle entries uit de tabel vormt en dus niet een gereduceerd aantal entries hebt, gevormd door LIMIT.

Je kunt dus ook gebruik maken van Zend_Paginator_Adapter_DbSelect via

PHP:

$adapter = new Zend_Paginator_Adapter_DbSelect($db->select()->from('posts'));

Deze geeft wel meteen intern je juiste query's, maar ik krijg dit maar niet goed in het MVC pattern. Je wilt toch juist in je controller de paginator aanmaken en niet in het model?

Zie ik iets over het hoofd? Iemand een tip? * japaveh slurpt intussen aan koffie

[NielsNL]

Euh, ik maak geen gebruik van het Zend framework, daarom gaat dit voor mij niet werken.

[mithras]

japaveh schreef op dinsdag 22 september 2009 @ 14:44:
[...]


Om hier eventjes op in te haken, we staan immers toch in de koffiehoek

Ik heb binnen het ZF ook zoiets geprobeerd te doen. Daarbij kun je onder andere 2 opties gebruiken:

PHP:

$runList = array(..) //array gevormd door het model
$paginator = new Zend_Paginator(new Zend_Paginator_Adapter_Array($runList));

Nu is dit niet de meest ideale oplossing omdat die $runList alle entries uit de tabel vormt en dus niet een gereduceerd aantal entries hebt, gevormd door LIMIT.

Je kunt dus ook gebruik maken van Zend_Paginator_Adapter_DbSelect via

PHP:

$adapter = new Zend_Paginator_Adapter_DbSelect($db->select()->from('posts'));

Deze geeft wel meteen intern je juiste query's, maar ik krijg dit maar niet goed in het MVC pattern. Je wilt toch juist in je controller de paginator aanmaken en niet in het model?

Zie ik iets over het hoofd? Iemand een tip? * japaveh slurpt intussen aan koffie

Ja, dat klopt. Het is niet heel erg gemakkelijk om het in je applicatie te stoppen vind ik. Ik heb het nu in mijn controller, maar ik wil af van de vette controllers en naar de vette modellen toe Op dit moment die ik dit:

PHP:

$page = ($this->getRequest()->page)?$this->getRequest()->page:1;

//Creation of the paginator
$article = new Blog_Model_Article;
$select = $article->getMapper()->getDbTable()->select()->order('create_date DESC');
$paginator = new Zend_Paginator(new Zend_Paginator_Adapter_DbTableSelect($select));
$paginator->setItemCountPerPage($countperPage);
$paginator->setCurrentPageNumber($page);

//From db objects to article models
$articles = $article->getMapper()->import($paginator->getCurrentItems());

Dus maak je gebruik van een functie ModelMapper::import(). Het is niet de mooiste manier en daarom wil ik eerder toe naar een controller waarin je eigenlijk alleen maar dit doet (even uit de losse pols hoor):

PHP:

$article   = new Blog_Model_Article;
$articles  = $article->fetchPage($page, $numberPerPage);
$paginator = $article->getPaginator();

En in de mapper iets als:

PHP:

public function fetchPage($page = 1, $numberPerPage = 5)
{
  $paginator = $this->getPaginator()
                    ->setItemCountPerPage($numberPerPage)
                    ->setCurrentPageNumber($page);
  $articles = array();
  foreach ($paginator->getCurrentItems() as $item) {
    $article = new Blog_Model_Article;
    $article->setId($item->id)
            ->setTitle($item->title);
    $articles[] = $article;
  }
  return $articles;
}

public function getPaginator ()
{
  if (null === $this->_paginator) {
    $select = $this->getMapper->getDbTable()->select()->order('create_date DESC');
    $this->_paginator = new Zend_Paginator(new Zend_Paginator_Adapter_DbTableSelect($select));
  }
  return $this->_paginator;
}

[japaveh]

@mithras

Dat is wel een goede opzet. Ik heb er tot nu toe voor gekozen om de model een array te laten maken en deze volledig door te geven naar de controller. Daar maak ik er een paginate-object van en bepaal ik de juiste pagina etc. Voordeel is dat je de model/controller goed gescheiden houdt, maar je creeert wel een (behoorlijke?) overhead door de grotere resultset en de grote array die je moet doorsturen. Ik moet nog eens benchmarken wat het verschil nu precies is.

ZF is prima te gebruiken, maar voor dit soort dingen moet je altijd wel goed nadenken vind ik, gelukkig zijn er wel meerdere wegen die naar Rome leiden.

[iH8]

mithras schreef op dinsdag 22 september 2009 @ 15:18:

En in de mapper iets als:

PHP:

public function fetchPage($page = 1, $numberPerPage = 5)
{
  $paginator = $this->getPaginator()
                    ->setItemCountPerPage($numberPerPage)
                    ->setCurrentPageNumber($page);
  $articles = array();
  foreach ($paginator->getCurrentItems() as $item) {
    $article = new Blog_Model_Article;
    $article->setId($item->id)
            ->setTitle($item->title);
    $articles[] = $article;
  }
  return $articles;
}

public function getPaginator ()
{
  if (null === $this->_paginator) {
    $select = $this->getMapper->getDbTable()->select()->order('create_date DESC');
    $this->_paginator = new Zend_Paginator(new Zend_Paginator_Adapter_DbTableSelect($select));
  }
  return $this->_paginator;
}

Dat vind ik nu echt niets voor in de mapper. Hoort imo thuis in een actionhelper. Of ben ik hier verkeerd bezig?

een split van deze ZF Paginator perikelen richting [PHP/ZF] Paginator zou gaaf zijn mods.

[mithras]

iH8 schreef op dinsdag 22 september 2009 @ 21:42:
[...]


Dat vind ik nu echt niets voor in de mapper. Hoort imo thuis in een actionhelper. Of ben ik hier verkeerd bezig?

Je krijgt van deze paginator (door de db adapter) een array van Zend_Db_Table_Row's. Dan moet je action helper op een of andere manier weten hoe je die row naar je model krijgt. Dat is een afhankelijkheid die ik niet zou willen inbouwen eigenlijk.

De mapper is juist de laag waarin je de database velden koppelt aan je model. Waarom dat niet doen met de paginator?

[ Voor 8% gewijzigd door mithras op 22-09-2009 21:59 ]

[Cartman!]

Met curry

Ik gebruik ook ZF en voor pagination heb ik een actionhelper gemaakt waar ik wat vars in stop en die geeft me een array aan info terug (je kunt zo makkelijk de scope van de paginator in 1 keer wijzigen), een viewhelper verwerkt dit weer voor me zodat het er netjes uit ziet. De actionhelper wijzigt in feite nooit meer (tenzij die scope anders moet (ik heb default de 'google manier' voor pagination)) en de viewhelper wisselt per design wel eens. Zo blijft alles netjes gescheiden en vervuil ik er niet mn model mee. Kwestie van smaak denk ik...

edit: om t totaal aantal rijen te krijgen gebruik ik COUNT() zoals eerderen al genoeg hadden geroepen

de SQL_CALC_FOUND_ROWS mogelijkheid gebruik ik niet meer, die schijnt heel sloom te zijn op je query (niet zelf gecheckt, heb ik aangenomen van mn collega die dit onderzocht heeft).

[ Voor 20% gewijzigd door Cartman! op 22-09-2009 23:03 ]

[iH8]

mithras schreef op dinsdag 22 september 2009 @ 21:58:
[...]
Je krijgt van deze paginator (door de db adapter) een array van Zend_Db_Table_Row's. Dan moet je action helper op een of andere manier weten hoe je die row naar je model krijgt. Dat is een afhankelijkheid die ik niet zou willen inbouwen eigenlijk.

De mapper is juist de laag waarin je de database velden koppelt aan je model. Waarom dat niet doen met de paginator?

Cartman is me te snel af.

PHP:

class ArticlesController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->results = $this->_helper->Paginate(
            $this->articles->select(),
            $this->_getParam('page',1),
            $this->_getParam('count',20)
        );
    }
}

PHP:

class Pjc_Helper_Paginate extends Zend_Controller_Action_Helper_Abstract
{
    public function direct($select, $page, $limit)
    {
        $results = Zend_Paginator::factory($select);
        $results->setItemCountPerPage($limit);
        $results->setCurrentPageNumber($page);
        return $results;
    }
}

Zoiets. Ik snap niet wat er hoeft te gebeuren in je model/mapper met een instance van je paginator. Je paginator accepteert een select object, da's geen resultset. hij voegt er zelf de offset en limit aan toe execute de query.

[pedorus]

Ach, het is heel eenvoudig dat pagineren; gewoon het volgende schema gebruiken..

quote: http://thedailywtf.com/Ar...nation-Consternation.aspx

[iH8]

pedorus schreef op dinsdag 22 september 2009 @ 23:37:
Ach, het is heel eenvoudig dat pagineren; gewoon het volgende schema gebruiken..

[...]

[japaveh]

@Mods, met iH8, Inderdaad een splitsje naar nieuw ZF/Paginate topic?

@iH8
Dan ben ik toch benieuwd naar datgene wat $this->articles->select() oplevert.

Is dat het resultaat van een query, dus van een DbSelect of iets dergelijks, of een array? Als je werkt met een mapper dan geeft je model altijd een aantal arrays of objecten terug maar nooit een rechtstreeks DbSelect.

Met de oplossing die je nu geeft heb je dan niet als voordeel dat je query's automatisch worden aangepast aan de hoeveelheid items en items_per_pagina, waardoor je een overhead krijgt. Of mis ik nu iets?

[iH8]

japaveh schreef op woensdag 23 september 2009 @ 00:02:

Dan ben ik toch benieuwd naar datgene wat $this->articles->select() oplevert.

Is dat het resultaat van een query, dus van een DbSelect of iets dergelijks, of een array? Als je werkt met een mapper dan geeft je model altijd een aantal arrays of objecten terug maar nooit een rechtstreeks DbSelect.

Model:

PHP:

class Pjc_Articles_Table extends Zend_Db_Table{
    
    protected $_name = 'articles';
}

Controller:

PHP:

class ArticlesController extends Zend_Controller_Action
{
    public function init()
    {
        $this->articles = new Pjc_Articles_Table();
    }

    public function indexAction()
    {
        $this->view->results = $this->_helper->Paginate(
            $this->articles->select(),
            $this->_getParam('page',1),
            $this->_getParam('count',20)
        );
    }
}

Init erbij, misschien is het dan duidelijker. Zoals ik al zei is $this->articles->select(); alleen het select object van het model. die pass je door naar je paginator, die voegt er limit en offset aan toe en dan pas wordt de resultset opgehaald. het bovenstaande resulteert in het volgende:

0.00054 DESCRIBE `articles`
0.00023 SELECT COUNT(1) AS `zend_paginator_row_count` FROM `articles`
0.00065 SELECT `articles`.* FROM `articles` LIMIT 20 OFFSET 280

Met de oplossing die je nu geeft heb je dan niet als voordeel dat je query's automatisch worden aangepast aan de hoeveelheid items en items_per_pagina, waardoor je een overhead krijgt. Of mis ik nu iets?

yup

[japaveh]

iH8 schreef op woensdag 23 september 2009 @ 01:01:
[...]
Model:
...
yup

Ikzelf maakt gebruik van een dataMapper. Dan kun je bovenstaand voorbeeld niet gebruiken omdat je eerst in je model de resultaten van de query naar objecten moet zetten.

Dan werkt het alleen als je de Zend_Paginate elementen naar het model verhuist volgens mij en dat gaat dan weer in tegen het MVC principe omdat het model enkel de resultaten uit de DB moet halen en zich niet moet bemoeien met de verdeling over verschillende pagina's.

[mithras]

iH8 schreef op dinsdag 22 september 2009 @ 23:34:
[...]


Cartman is me te snel af.

[code]

Zoiets. Ik snap niet wat er hoeft te gebeuren in je model/mapper met een instance van je paginator. Je paginator accepteert een select object, da's geen resultset. hij voegt er zelf de offset en limit aan toe execute de query.

PHP:

$items = $paginator->getCurrentItems();
print_r($items);

Door je db adapter van je paginator krijg je een Zend_Db_Table_Rowset terug en daarin zitten Zend_Db_Table_Row items. Door je mapper in te zetten kan je de Zend_Db_Table_Row gebruiken om uiteindelijk je modellen te krijgen. Want die modellen wil je uiteindelijk in je view krijgen (volgens mij).

Ik heb bijvoorbeeld een Blog_Model_Blog, Blog_Model_Article en Blog_Model_Reaction. Allemaal zijn ze 1:n (dus meerdere artikelen in een blog en meerdere reacties per artikel). Door je mapper in te zetten en daarbij in je view een array van Blog_Model_Articles te krijgen, ben je veel flexibeler, maar ook eenduidiger. Want kan jij gewoon in je view dingen doen als:

HTML:

<h1>Blog "<?= current($this->articles)->getBlog->getTitle()?>"</h1>
<ul>
  <? foreach ($this->articles as $article):?>
    <li><?= $article->getTitle()?> (<?= count($article->getReactions())?> reacties)</li>
  <? endforeach;?>
</ul>

Anders moet je in je select() al gaan bepalen dat je ook de blog-titel wil en de reacties wil joinen. Lijkt me niet de meest schone optie

/edit:
Ik zeg dus ook niet dat mijn optie de mooiste is Ik heb eigenlijk niet echt een idee van wat "goed" is, maar beide methoden vind ik niet goed. Daarvan is mijn manier de minst erge

De action helper voor de paginator is op zich wel een goed idee om het te abstraheren. Toch mis ik dan nog wel de koppeling terug naar mijn model. En die Blog_Model_ArticleMapper::import() is me ook niet te mooiste...

[ Voor 12% gewijzigd door mithras op 23-09-2009 09:08 ]

[iH8]

mithras schreef op woensdag 23 september 2009 @ 09:05:

Door je db adapter van je paginator krijg je een Zend_Db_Table_Rowset terug en daarin zitten Zend_Db_Table_Row items. Door je mapper in te zetten kan je de Zend_Db_Table_Row gebruiken om uiteindelijk je modellen te krijgen. Want die modellen wil je uiteindelijk in je view krijgen (volgens mij).

Die roundtrip vind ik echt heel erg vies. Je paginator heeft het model al aangesproken om daar na de rowset door de mapper te halen? Dat is toch uberhaubt geen goede opzet? Je paginator hoeft er geen hout om te geven of jij je resultset uit een model, mapper of wat dan ook halen wil. Ik geef een simpel voorbeeld met een model. Je kan ook je mapper een select object laten retourneren. De mapper van Zend zelf doet het toch ook zo?

Uit Component Requirements, Constraints, and Acceptance Criteria voor Zend_Db_Mapper:

# It will provide a Query API for RDMS mappers that bases on Zend_Db_Select
# It will provide a Query Object API that is sql-likeish but speaks in terms of the domain model (properties, entities).

Ik zeg ook niet dat mijn oplossing de beste is. Ik probeer niet eens een oplossing te geven want die zijn er meerdere. Alleen eerst je model aanspreken en dan je mapper in je controller is echt niet the MVC way hoe je het ook buigt of keert. Die oplossing vind ik niet kloppen. Lees de wiki van die mapper eens door of beter nog, haal 'm uit de incubator:

http://framework.zend.com...age.action?pageId=9437243
http://framework.zend.com...andard/incubator/library/

japaveh schreef op woensdag 23 september 2009 @ 07:22:
[...]

Ikzelf maakt gebruik van een dataMapper. Dan kun je bovenstaand voorbeeld niet gebruiken omdat je eerst in je model de resultaten van de query naar objecten moet zetten.

Dan werkt het alleen als je de Zend_Paginate elementen naar het model verhuist volgens mij en dat gaat dan weer in tegen het MVC principe omdat het model enkel de resultaten uit de DB moet halen en zich niet moet bemoeien met de verdeling over verschillende pagina's.

dito!

[ Voor 14% gewijzigd door iH8 op 23-09-2009 14:02 ]

[japaveh]

Ik heb de mapper uit de quickstart van Zend Framework genomen en het lijkt er inderdaad op dat de Zend_Db_Mapper een standarisatie is daarvan. Nu nog wachten totdat het opgenomen is in ZF.

[mithras]

Volgens mij is hier een misverstand Ik ga er graag vanuit dat ik in mijn view modellen heb, die ik kan gebruiken voor de voorbeelden uit mijn vorige post (zie edit). Sowieso is de methode om de paginator vanuit een action helper te gebruiken daar geen oplossing voor. Hoe zien jullie dat dan?

Daarnaast even wat dingen die ik niet snap, waarvan jij aanneemt die ik zeg (leuke zin ) hier neer zetten:

Je paginator heeft het model al aangesproken om daar na de rowset door de mapper te halen?
[...]
Alleen eerst je model aanspreken en dan je mapper in je controller is echt niet the MVC way hoe je het ook buigt of keert.

Ik doen in mijn controller dit:

PHP:

class Blog_ArchiveController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $article  = new Blog_Model_Article;
        $page     = $this->_getParam('page', 1);
        $count    = $this->_getParam('count', 20);
        $articles = $article->fetchPage($page, $count);

        $this->view->articles = $articles
    }
}

Dus waar je normaal met een Model::fetchAll() of Model::find() in je controller dit doet:

model -> mapper -> dbTable -> mapper -> model

Doe je met dit met een paginator aanroep in je controller:

model -> mapper -> dbTable -> paginator -> mapper -> model

Daar gaat de vergelijking met de eerste wel héél erg goed op (en die is zeker the MVC way).

Ik wil nergens iemand afkraken of wat dan ook, ik wil graag via een discussie meer inzicht hebben in het principe en hiermee een duidelijke oplossing vinden voor dit probleem.
Het gaat mij meer om dat je door de paginator in je controller te plaatsen, je (naar mijn idee) verkeerd bezig bent de data te behandelen, omdat je direct met kolommen van je database zit te werken. Alle "in- en uitgangscontroles" die je kan doen bij je model door middel van getters en setters doe je dan compleet te niet. Of zie ik dat verkeerd?

[iH8]

mithras schreef op woensdag 23 september 2009 @ 14:48:
Volgens mij is hier een misverstand

Yup en een verschil van mening. Ik wil ook niemand afkraken hoor, ik ben ook op zoek naar meer inzicht. Ben pas een jaartje met OOP bezig en een half jaartje met ZF. Ik had al meegekregen dat MVC op meerdere manieren geimplementeerd wordt. Ik ben ook voor fat model, skinny controller. Maar boven alles ben ik tegen het aanspreken van m'n models in de view. Het behandelen en preppen van data vind ik een taak voor de controller. View showed alleen maar data. Ik weet ook niet wat wijsheid is, ik doe maar wat ik denk dat goed is.

mithras schreef op woensdag 23 september 2009 @ 14:48:

Het gaat mij meer omdat je door de paginator in je controller te plaatsen, je (naar mijn idee) verkeerd bezig bent de data te behandelen

mithras schreef op woensdag 23 september 2009 @ 14:48:

Alle "in- en uitgangscontroles" die je kan doen bij je model door middel van getters en setters doe je dan compleet te niet. Of zie ik dat verkeerd?

In- en uitgangscontroles? Ik zeg al, ik ben nieuw. Leg uit

[mithras]

iH8 schreef op woensdag 23 september 2009 @ 15:59:
[...]

True

[...]


In- en uitgangscontroles? Ik zeg al, ik ben nieuw. Leg uit

Ik bedoel meer met functies als:

PHP:

public function setId ($id)
{
  $this->_id = (int) $id;
}

Dat je dus met een setter expliciet je parameter converteert naar een integer, omdat php weak typed is en het php eigenlijk niets uitmaakt.

Ook heb ik bijvoorbeeld een kleine webshop geklust. Daarin modelleer ik het winkelmandje met een Shop_Model_Cart. Daarin heb ik dan bijvoorbeeld iets als:

PHP:

public function getPrice ()
{
  $price = 0;
  foreach ($this->getProducts as $product) {
    $price += $product->getPrice();
  }
  return $price;
}

Dit soort dingen vind ik heel erg handig, om zowel in je getter als setter extra dingen mogelijk te maken. Wanneer je in een paginator puur je Zend_Db_Table_Row gaat gebruiken mis je al deze controles. Dat is het punt wat ik eigenlijk probeer te maken

[iH8]

ok, leesvoer! http://www.noginn.com/2009/01/18/models-and-zend_paginator/

[japaveh]

Hmm interessant, morgen eens mee spelen. Grappig trouwens dat Matthew zelf ook worstelt met Zend_Paginator

[nika]

Vraag aan de mensen die zich met Zend_Paginator bezighouden.

Waar ik mee zit is hoe je een search optie combineert met de paginator. Zeg ik heb een lijst met personen en ik zoek op een naam, dat de paginator dan automatisch naar de juiste pagina springt (bijv. eerste vermelding van die naam).

[Cartman!]

Dat is geen logica die hoort in een paginator imo. Een paginator geeft gegevens terug over het aantal pagina's en welke pagina je nu zit etc. maar logica welke pagina precies geladen moet worden zit in je model naar mijn idee.

[mithras]

En daarnaast gaat het je ook niet lukken met Zend_Paginator volgens mij. Je kan een select meegeven waarin de search zit, zodat je een paginated resultset krijgt met alleen je zoek-resultaten.

Maar naar de juiste pagina springen, daarvoor moet je eerst alle data ophalen, dat doorzoeken, pagineren en de juiste pagina selecteren. Bye bye performance