paginering vind ik lastig. vooral met OOP. eerlijk gezegd snap ik er geen zak van.
er wordt altijd vertelt: laat het paginate-object de paginering afhandelen, om te zorgen voor flexibiliteit. maar paginering kan je toch eigenlijk niet zien als object? voor mij niets tastbaars. en de gegevens die je altijd moet invoeren, daardoor gaat al die flexibiliteit toch helemaal verloren?
als ik die van Roel hier zie, lijkt die me best netjes. maar het database gebeuren zit in die class, alle links, de hele shit. die flexibiliteit is dan toch weg, en is het meer een verzameling functies?
dus, hoe hoort een paginering in OOP eruit te zien?
Jeroen, niet elke method moet een return hebben. Een setter (zoals setData) set vaak een value aan een property, deze hoeft -eigenlijk mag- niks te retourneren.
Verder is de opbouw van de logica een beetje als volgt:
Je hebt een PaginatorItemInterface. Deze zorgt ervoor hoe het Item eruit ziet. Dus bijv. of het in een div gaat, of in een lijst.
De method render van deze klasse retourneert 1 enkel item.
Met de method setData vullen we wat gegevens van het item in.
Dan heb je een PaginatorButtonFormInterface. Deze zorgt voor de buttons << < 1 | 2 | 3 | > >> enz. Hoe dat eruit ziet plaats je in de render method van de PaginatorButtonFormInterface.
Vervolgens heb je nog een PaginatorBackendInterface. Deze zorgt voor het ophalen van de gegevens.
De method getItems retourneert een array van PaginatorItemInterfaces met alle items. Deze haalt die bijv. uit de database.
Als laatst heb je een Paginator object die alles bij elkaar voegt en via de render method een mooie code teruggeeft met items en buttons.
Waarom maak je niet gebruik van het Adapter pattern? Kan je dat toelichten. Wanneer ik een paginator maak, maak ik meestal gebruik van het Adapter pattern vandaar ;-)
Dit is toch een adapter?
3 maal zelfs:
Je kan zelf een backend injecteren om de items op te halen, PaginatorPDOLinkBackend is een voorbeeldimplementatie.
De backend kan dan een implementatie van PaginatorItemInterface teruggeven. PaginatorLinkItem is het voorbeeld.
En tot slot kan je zelfs de knopjes zelf aanpassen met PaginatorButtonFormInterface, al had ik geen zin daar een voorbeeld voor te maken/.
Best wel een adapter-pattern toch?
[size=xsmall]Toevoeging op 02/06/2012 00:42:51:[/size]
Ja ik begin het te begrijpen, alleen AbstractPaginatorPDOBackend wordt geextend in PaginatorPDOLinkBackend. Waarom? Die kan je toch ook prima samenvoegen?
@Jeroen,
Ja, nu natuurlijk wel, maar het is goed mogelijk dat je meerdere backends voor verschillende items wil maken, die alle op PDO gebaseerd zijn en die ook allemaal een aantal dezelfde helper-functies nodig hebben. Dan wordt de AbstractPaginatorPDOBackend opeens nuttig.
Het is natuurlijk helemaal niet noodzakelijk om zó modulair te werken, maar ik heb een beetje overdreven, omdat jij graag flexibiliteit wou zien.
nou, in ieder geval bedankt voor de hele uitgebreide reacties op dit vraagstuk. het is mij een heel stuk duidelijker, maar zal nog veel moeten oefenen (op heel OO gebied) om dit goed toe te kunnen toepassen.
