[php] complexe lijst en volgende/vorige knoppen?

[PanMan]

Hoi. Ik heb een site, met daarop een aantal redelijk complexe searches (veel variabelen en sorteermogelijkheden) voor items. Voor elk gevonden item kan je doorklikken naar een detailpagina over dat item.Nu wil de klant dat op die detailpagina een knop vorige/volgende komt (twee knoppen dus ). En dat is best lastig: Tot nu toe kan ik gewoon linken naar de pagina van een object. Maar voor die volgende/vorige knoppen moet ik dus de volledige context van de vorige pagina doorgeven. En dat zijn dus meerdere pagina's. Heeft iemand een handig idee om dat te gaan doen? Ik kan natuurlijk gewoon alle opties doorgeven, en de query opnieuw opbouen, zoeken, goede res bepalen, en volgende/vorige zo bepalen, maar dat vind ik redelijk ingewikkeld. Een andere optie die m'n mind croste is bij de gevonden results die in een sessie opslaan (alleen de item-ID's), zodat de pagina van het item die kan doorzoeken. Maar dat vind ik ook niet echt een mooie oplossing. (sessie die niet werkt, verkeerde items, etc). Een heel makkelijke, maar heeeel lelijke en onveilige optie zou zijn om gewoon de gebouwde SQL query door te geven aan de itempagina, en die daar opnieuw uit te voeren. Maar dat lijkt me dus nogal onveilig, zeker als het via de client zou gaan.
Iemand die hier wel een slimme oplossing voor heeft?
Ohja, in de titel staat PHP omdat ik dit bouw met PHP/MySQL. Maar het gaat me meer om het idee, dan om de daadwerkelijke uitvoering (als ik het idee snap, lukt dat me hopelijk zelf ).

[djc]

Je kunt elk resultaat zien als item x dat je krijgt in de lijst van items gesorteerd op criterium y. Dus met een query als ?criterium=datum&order=desc&num=18 ben je er dan, je kunt met een LIMIT clause aangeven dat je LIMIT num, 1 wil hebben.

[ Voor 29% gewijzigd door djc op 28-02-2005 23:14 ]

[JayVee]

• Eerste optie lijkt mij de beste omdat het de meest robuste is.
• Resultaat van query in de session stoppen is onvoordelig kwa performance, aangezien je het ook doet als het niet nodig is.
• Query aan de client geven kan absoluut niet. Dat is een enorm veiligheidslek.

Wie zegt dat de links naar vorige/volgende klaar moeten zijn op het moment dat je het detail overzicht print. Je kan ook naar een pagina linken die aanhand van de current id en de constraints (via GET) bepaalt wat de volgende/vorige pagina is en de browser daar naartoe headert. Dan doe je al dat werk alleen als het nodig is.

[PanMan]

Manuzhai schreef op maandag 28 februari 2005 @ 23:14:
Je kunt elk resultaat zien als item x dat je krijgt in de lijst van items gesorteerd op criterium y. Dus met een query als ?criterium=datum&order=desc&num=18 ben je er dan, je kunt met een LIMIT clause aangeven dat je LIMIT num, 1 wil hebben.

Ja natuurlijk, dat weet ik, ik ken Limit. Maar stel dat ik in de zoekpagina 3 criteria opgeef, en een order-by kies. Dus de zoekpagina is iets als search.php?eis1=100&eis2=4&eis3=blaat&order=cat5. En vervolgens item 4 uit die lijst (met wellicht 20 resultaten) kies. Hoe weet ik dan op mijn item-pagina wat item 5 is? Dat is eigenlijk mijn vraag.

[ Voor 35% gewijzigd door PanMan op 28-02-2005 23:18 ]

[R4NCOR]

Je zou ook een rijtje id's meekunnen geven.

bijvoorbeeld

item.php?rijtje=1,2,5,6,8&id=5

Deze trek je dan uit elkaar met

code:

$rijtje = explode(",", $_GET['rijtje']);

Je item.php weet welk id hij zelf heeft, dus aan de hand daarvan is dan gemakkelijk vorige/volgende te bepalen?

Bij het ophalen van de sql-resultaten maak je of course even een variabele aan met die id's gescheiden door komma's, die je vervolgens in het linkje meegeeft.

[djc]

Als je eenmaal een query hebt heb je toch altijd een lijst met resultaten? Als je eenmaal een lijst met resultaten hebt kun je daar toch altijd een LIMIT-clause op toepassen? Ik zie het probleem niet.

[PanMan]

R4NCOR schreef op maandag 28 februari 2005 @ 23:21:
Je zou ook een rijtje id's meekunnen geven.

bijvoorbeeld

item.php?rijtje=1,2,5,6,8&id=5

Deze trek je dan uit elkaar met

code:

$rijtje = explode(",", $_GET['rijtje']);

Je item.php weet welk id hij zelf heeft, dus aan de hand daarvan is dan gemakkelijk vorige/volgende te bepalen?

Bij het ophalen van de sql-resultaten maak je of course even een variabele aan met die id's gescheiden door komma's, die je vervolgens in het linkje meegeeft.

Ook best een optie, die ik nog niet had bedacht . Enige nadeel is dat dit wellicht een probleem gaat vormen als het straks 2000 resultaten zijn (niet dat iemand die allemaal gaat bekijken, maar om nou na 10 te stoppen, is ook weer zoiets). Wat is de max length van een GET url?
Als iemand hier een goede oplossing voor heeft... Tot nu toe vind ik dit de beste . Iets anders is natuurlijk ook nogsteeds welkom.

[ Voor 5% gewijzigd door PanMan op 28-02-2005 23:38 . Reden: maxlength toegevoegd ]

[R4NCOR]

Manuzhai schreef op maandag 28 februari 2005 @ 23:22:
Als je eenmaal een query hebt heb je toch altijd een lijst met resultaten? Als je eenmaal een lijst met resultaten hebt kun je daar toch altijd een LIMIT-clause op toepassen? Ik zie het probleem niet.

De item-pagina is een afzonderlijke pagina, waar die resultaten-lijst dus niet meer bekend is. Naar wat ik er van begrijp gaat het erom de beste oplossing daarvoor te zoeken

edit:
@ hierboven: goed punt.. Maar ik weet ook niet in wat voor situatie je verkeerd, wat de bedoeling is? Hoe realistisch is dat?
@ hier beneden: Goed punt

[ Voor 16% gewijzigd door R4NCOR op 01-03-2005 00:01 ]

[djluc]

Een rijtje id's in je session opslaan kan nog wel. Dat is niet zo heel ernstig wat betreft performance.

[sebas]

Je kunt je resultaten door middel van SELECT * INTO ... met een SessionID o.i.d. in een temporaire tabel opslaan, die je vervolgens aan de hand van een UNIQUE veld erin kunt browsen.

[kunnen]

PanMan schreef op maandag 28 februari 2005 @ 23:27:
Wat is de max length van een GET url?

Volgens mij 1024 tekens?

[sebas]

Pulsher schreef op dinsdag 01 maart 2005 @ 16:55:
[...]


Volgens mij 1024 tekens?

Volgens mij niet:

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.

Bron: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2

[PanMan]

okee, als het volgens de RFC oneindig is, maar in de praktijk (op IE, b.v.) 255, dan is die oneindig natuurlijk onwerkbaar, in de praktijk . Ik zal zo ff een testje bouwen.

Testresults
Firefox lijkt iig geen probleem te hebben met een URL van 4000 tekens. IE kapt hem na 2000 tekens querystring af. Apache geeft beide gewoon goed door.
Maar het zou natuurlijk kunnen dat eoa proxy het eerder afkapt, waardoor het toch niet voor iedereen fijn werkt (al is het natuurlijk niet heeel belangrijke functionaliteit. Ze kunnen altijd teruggaan, naar de vorige pagina).

[ Voor 55% gewijzigd door PanMan op 01-03-2005 20:29 . Reden: Results toegevoegd ]

[sebas]

Het is juist gevaarlijk om meer dan 255bytes lange URIs te gebruiken. Niet oneindig, maar simpelweg niet door HTTP 1.1 gespecificeerd, dus aan de implementatie van de betrokken software overgelaten.