[PHP] doorgeven query naar volgende pagina

[Verwijderd]

Ik heb een pagina (1) dat een overzicht geeft van de inhoud van een tabel. De inhoud van dit overzicht kan worden aangepast d.m.v. een filter. Aan de hand van de filter input wordt een nieuwe SELECT-query opgebouwd en daarmee wordt het filter toegepast op het overzicht. Vrij eenvoudig en vrij "recht toe, recht aan".

Welnu, de volgende stap is om het overzicht te kunnen printen. Omdat (1) allemaal aanvullende elementen bevat (navigatie, diverse icons) is het eenvoudigweg printen van (1) geen optie. Er moet dus een nieuwe pagina worden geladen (2). Deze wordt geladen in een popup.

Om (2) exact hetzelfde overzicht te laten bevatten als (1) zou het het makkelijkste zijn om de hele query door te geven. Maar hoe doe je dit mooi en veilig?

- Ik zou GET of POST kunnen gebruiken, maar dan wordt het systeem wel erg onveilig, dit is dus geen acceptabele optie.

- Ik zou een sessie var. met een soort van $actual-query kunnen opslaan in (1) en uitlezen in (2), maar dit is m.i. ook niet echt mooi.

- Ik zou een temp tabel in de db kunnen zetten, en daarin de query tijdelijk opslaan, en de id doorgeven van (1) naar (2). Ook dit lijkt me vrij inefficient.

Heeft iemand andere ideen, of opmerkingen over mijn gedachten?

BVD!

[Brakkie]

Je pagina(1) in wordt toch opgebouwd aan de hand van een aantal filters? Dan kan je toch gewoon die filters doorgeven naar pagina (2) door middel van een _GET variabetel. Ik snap je probleem eigenlijk niet echt.

[Michali]

Die sessie kan toch perfect? Mischien kun je er nog extra maatregelen bij nemen voor wat extra veiligheids mbt die sessie, maar dat moet je zelf maar even bekijken.

[Verwijderd]

Brakkie schreef op woensdag 20 april 2005 @ 17:09:
Je pagina(1) in wordt toch opgebouwd aan de hand van een aantal filters? Dan kan je toch gewoon die filters doorgeven naar pagina (2) door middel van een _GET variabetel. Ik snap je probleem eigenlijk niet echt.

Dat klopt, maar het opstellen van de query op basis van de filters is nogal complex. Dit zou ik dus het liefst maar een maal doen. Mocht het doorgeven van de query als geheel niet lukken, is dit natuurlijk altijd een alternatief.

[andrew]

Verwijderd schreef op woensdag 20 april 2005 @ 17:11:
[...]

Dat klopt, maar het opstellen van de query op basis van de filters is nogal complex. Dit zou ik dus het liefst maar een maal doen. Mocht het doorgeven van de query als geheel niet lukken, is dit natuurlijk altijd een alternatief.

Maar je kunt dat toch wel in een functie zetten (parse_filter_query oid) en die ook aanroepen in je overzicht?

En anders lijkt mij de sessie variabele ook het mooist.

[T-MOB]

Je zou ook gewoon een print-stylesheet kunnen maken voor pagina (1) natuurlijk. Die neem je als volgt op in de header van je pagina:

code:

<link rel="stylesheet" type"text/css" href="print.css" media="print">

[Verwijderd]

andrew schreef op woensdag 20 april 2005 @ 17:17:
[...]
Maar je kunt dat toch wel in een functie zetten (parse_filter_query oid) en die ook aanroepen in je overzicht?

En anders lijkt mij de sessie variabele ook het mooist.

Er zijn erg veel factoren die een rol spelen in het opbouwen van de query. Er kan op elke column gefilterd en gesorteerd worden (en de columns staan van tevoren niet vast, alles wordt dynamisch opgebouwd) Dus er worden erg veel variabelen in de functie betrokken.

Ik zal het $_SESSION alternatief nog eens grondig nagaan.

in elk geval, dank allemaal!

[T-MOB]

Verwijderd schreef op woensdag 20 april 2005 @ 18:55:
[...]
Er zijn erg veel factoren die een rol spelen in het opbouwen van de query. Er kan op elke column gefilterd en gesorteerd worden (en de columns staan van tevoren niet vast, alles wordt dynamisch opgebouwd) Dus er worden erg veel variabelen in de functie betrokken.

Ik zal het $_SESSION alternatief nog eens grondig nagaan.

in elk geval, dank allemaal!

Als het printen van de pagina het enige doel van de actie is zou ik je stellig adviseren om niet moeilijk te doen en CSS toepassen om een strakke print te verkrijgen.
Als het om meer gaat lijken sessions de beste weg om te bewandelen. Aan de andere kant heb je code om de query op te bouwen al geschreven, die zal ook werken op basis van $_POST en/of $_GET variabelen. Ik kan me moeilijk voorstellen dat het copy-pasten van deze code naar een andere pagina een probleem op gaat leveren. Als dit een performance hit oplevert ben ik iig erg benieuwd om wat voor een exotisch gebeuren het gaat...

[Verwijderd]

Het filter criteria worden inderdaad via POST en GET verstuurd, en vervolgens wordt op basis van deze waarden de query gebouwd.

Het bouwen van deze query is erg complex omdat er o.a. gekeken wordt of er een FK relatie is, zo ja wordt niet de id geladen, maar de aan de id gekoppelde waarde in de foreign-table. Zo zijn er nog wat meer stappen die het opbouwen een complex geheel maken.

Uiteraard is het mogelijk om alle P/G vars door te sturen, en de query-build code dan nogmaals aan te roepen, maar dat is in principe zonde, de query is er immers al. Het is niet zo dat performance een heel zwaarwegend argument is, maar er moet wel een beetje rekening mee gehouden worden.


Het overzicht ziet er als volgt uit: http://www.asystance.nl/alis/pix/screens/showmonster.png. De query achter dit overzicht wordt niet alleen gebruikt voor de print out, maar ook om de waarden naar Excel en CSV te exporteren. Printen kan dus wellicht d.m.v. CSS, maar vervolgens speelt dan hetzelfde probleem bij de export stappen.