Suchbegriff zur nächsten Seite mitnehmen
borisbaer
1 1 
Rolf B
0 borisbaer
1 
Der Martin
0 borisbaer
0 T-Rex
Suchbegriff zur nächsten Seite mitnehmen
borisbaer
MudGuardHallo zusammen,
ich möchte gerne einen Suchbegriff bei einer paginierten Tabelle zur nächsten Seite mitnehmen. Momentan mache ich das, indem ich den Suchbegriff als Session-Variable speichere, doch die bleibt natürlich auch nach dem Refresh der Seite, was ich jedoch nicht haben möchte.
Eine Möglichkeit, die mir in den Sinn kam, ist, statt Links zur Paginierung zu verwenden, diese zu Submit-Buttons zu machen. Dann könnte ich den Inhalt des Suchfelds mitnehmen. So richtig gut finde ich das aber nicht.
Eine zweite Möglichkeit wäre, die Suche als Query-String zu speichern. Sieht dann natürlich nicht so schön aus in der URL-Zeile.
Gibt es da so etwas wie eine Best-Practice-Methode?
Grüße
Boris
akzeptierte Antworten
Suchbegriff zur nächsten Seite mitnehmen
Bewertung: +1, 3 Stimmen
-
ich möchte gerne einen Suchbegriff bei einer paginierten Tabelle zur nächsten Seite mitnehmen.
Das ist eine durchaus gängige Anforderung.
Momentan mache ich das, indem ich den Suchbegriff als Session-Variable speichere, doch die bleibt natürlich auch nach dem Refresh der Seite, was ich jedoch nicht haben möchte.
Das ist aus meistens vielen Gründen keine besonders gute Idee, auch wenn Mr. Fantastic hier im Forum, nennen wir ihn einfach mal @TS das garantiert anders sieht.
Eine Möglichkeit, die mir in den Sinn kam, ist, statt Links zur Paginierung zu verwenden, diese zu Submit-Buttons zu machen. Dann könnte ich den Inhalt des Suchfelds mitnehmen. So richtig gut finde ich das aber nicht.
Ich vermute mal, Du willst einen POST-Requests statt eines GET provozieren. Kann man machen. Hängt zunächst aber nicht davon ab, ob Du einen Button verwendest. Darüber hinaus hat das viele Nachteile.
Eine zweite Möglichkeit wäre, die Suche als Query-String zu speichern.
M.E. die beste, soweit ich Deinen Use-Case verstanden habe. Speichern würde ich das dann aber nicht nennen. Du kreist eine URL, die zu nachvollziehbaren Ergebnissen führt. Das möchte man im Regelfall aus vielen Gründen gerne haben.
Sieht dann natürlich nicht so schön aus in der URL-Zeile.
Den ganzen Query-Kram kannst Du dabei mittels Rewrites usw. noch aufhübschen, aber das Prinzip bleibt.
Wenn Dein Problem wirklich nur sein sollte "huch, das ist aber eine hässliche Browserzeile": lass es bleiben.
Gibt es da so etwas wie eine Best-Practice-Methode?
ME ja: Query-Paramter für eine Suchabfrage gehören nach Möglichkeit in einen GET-Request.
-
Hallo Mitleser,
Du willst einen POST-Requests statt eines GET provozieren. Kann man machen…
Eher nicht.
Es gibt Usecases für POST und Usecases für GET, und eigentlich sind die nicht austauschbar.
Ein GET, wo ein POST hingehört (sprich: der fachliche Ressourcen am Server updated), kollidiert mit Caches. Ein POST, wo ein GET hingehört, führt je nach Browser zu blöden Rückfragen bei der History-Navigation ("wollen Sie diese Daten tatsächlich nochmal senden?!").
Eine Suchanfrage und auch das Anzeigen von Seite X im Suchergebnis ist aus meiner Sicht definitiv ein GET. Den Suchbetriff in den Queryparameter zu setzen ist absolut okay, man schaue mal, welche Bandwürmer da die Suchmaschinen produzieren.
Rolf
--
sumpsi - posui - obstruxi-
Du willst einen POST-Requests statt eines GET provozieren. Kann man machen…
Eher nicht. […]
100% D'accord mit Deinen Argumenten. Meine Intention war schlicht, das Thema möglichst populärwissenschaftlich zu beleuchten.
-
-
Das ist aus meistens vielen Gründen keine besonders gute Idee, auch wenn Mr. Fantastic hier im Forum, nennen wir ihn einfach mal @TS das garantiert anders sieht.
Gilt das nur für Suchbegriffe oder Ähnliches? Ich speichere nämlich die Sortierungseinstellungen durchaus in der Session, als z.B. title DESC oder so.
Ich vermute mal, Du willst einen POST-Requests statt eines GET provozieren. Kann man machen. Hängt zunächst aber nicht davon ab, ob Du einen Button verwendest. Darüber hinaus hat das viele Nachteile.
Ja, genau. Welche Nachteile denn?
M.E. die beste, soweit ich Deinen Use-Case verstanden habe. Speichern würde ich das dann aber nicht nennen. Du kreist eine URL, die zu nachvollziehbaren Ergebnissen führt. Das möchte man im Regelfall aus vielen Gründen gerne haben.
So habe ich es nun auch gelöst. Du sagt, man möchte das so haben. Aber warum?
Den ganzen Query-Kram kannst Du dabei mittels Rewrites usw. noch aufhübschen, aber das Prinzip bleibt.
Ja, stimmt. Wobei ich hier keine Notwendigkeit sehe.
Wenn Dein Problem wirklich nur sein sollte "huch, das ist aber eine hässliche Browserzeile": lass es bleiben.
Okay. 😉
ME ja: Query-Paramter für eine Suchabfrage gehören nach Möglichkeit in einen GET-Request.
Gut, danke, das wollte ich wissen!
Das führt mich aber zu einer andern Frage: Wie soll ich Suchbegriffe in der URL handhaben? Im Moment könnte da stehen ?search=Demon’s Souls. Da ist sowohl ein Leerzeichen als auch ein Apostroph drin. Sollte ich das codieren, z.B. %20 für die Leerzeichen? Da muss es doch eine eingebaute Funktion in PHP geben.
Grüße
Boris-
Guten Abend,
Das ist aus meistens vielen Gründen keine besonders gute Idee, auch wenn Mr. Fantastic hier im Forum, nennen wir ihn einfach mal @TS das garantiert anders sieht.
Gilt das nur für Suchbegriffe oder Ähnliches? Ich speichere nämlich die Sortierungseinstellungen durchaus in der Session, als z.B. title DESC oder so.
das kann man machen; eigentlich sollten aber alle Informationen, die das Ergebnis der Abfrage inhaltlich beeinflussen, auch als URL-Parameter übergeben werden. Die Präsentation dieser Inhalte (also beispielsweise die Sortierung) kann gern auch auf anderem Weg gesteuert werden.
Ich vermute mal, Du willst einen POST-Requests statt eines GET provozieren. Kann man machen. Hängt zunächst aber nicht davon ab, ob Du einen Button verwendest. Darüber hinaus hat das viele Nachteile.
Ja, genau. Welche Nachteile denn?
Zum Beispiel, dass die Browser dann jedesmal mit einer für manche Nutzer unverständlichen Rückfrage reagieren, wenn man die Anzeige aktualisieren möchte.
M.E. die beste, soweit ich Deinen Use-Case verstanden habe. Speichern würde ich das dann aber nicht nennen. Du kreist eine URL, die zu nachvollziehbaren Ergebnissen führt. Das möchte man im Regelfall aus vielen Gründen gerne haben.
So habe ich es nun auch gelöst. Du sagt, man möchte das so haben. Aber warum?
Weil man die Abfrage dann auch anderen als Link mitteilen kann, oder weil man sie als Bookmark speichern und wieder und wieder abrufen kann - um zu sehen, was sich seit gestern verändert hat.
Das führt mich aber zu einer andern Frage: Wie soll ich Suchbegriffe in der URL handhaben? Im Moment könnte da stehen ?search=Demon’s Souls. Da ist sowohl ein Leerzeichen als auch ein Apostroph drin. Sollte ich das codieren, z.B. %20 für die Leerzeichen? Da muss es doch eine eingebaute Funktion in PHP geben.
Das muss natürlich URL-codiert werden (auch als Percent-Encoding bezeichnet). Stichwort: Kontextspezifische Codierung bzw. Maskierung.
Einen schönen Tag noch
Martin--
"Malen nach Zahlen" sagten wir im Matheunterricht, wenn es bei der Kurvendiskussion hieß: Zeichnen Sie den Graphen der Funktion ...-
Hallo Martin,
das kann man machen; eigentlich sollten aber alle Informationen, die das Ergebnis der Abfrage inhaltlich beeinflussen, auch als URL-Parameter übergeben werden. Die Präsentation dieser Inhalte (also beispielsweise die Sortierung) kann gern auch auf anderem Weg gesteuert werden.
Zum Beispiel, dass die Browser dann jedesmal mit einer für manche Nutzer unverständlichen Rückfrage reagieren, wenn man die Anzeige aktualisieren möchte.
Ich verstehe. Es erfolgt bei mir jedoch nach jedem POST-Request eine Umleitung zum index, sodass bei einem Refresh keine erneute POST-Anfrage initiiert wird.
Weil man die Abfrage dann auch anderen als Link mitteilen kann, oder weil man sie als Bookmark speichern und wieder und wieder abrufen kann - um zu sehen, was sich seit gestern verändert hat.
Das ist ein starkes Argument. Das kam mir gar nicht in den Sinn. Vielen Dank für die Aufklärung!
Das muss natürlich URL-codiert werden (auch als Percent-Encoding bezeichnet). Stichwort: Kontextspezifische Codierung bzw. Maskierung.
Also
urlencode()? Diese Funktion wandelt die Leerzeichen zu Plus-Zeichen um. Das Apostroph lässt sie jedoch stehen.Grüße
Boris-
n'Abend Boris,
Das muss natürlich URL-codiert werden (auch als Percent-Encoding bezeichnet). Stichwort: Kontextspezifische Codierung bzw. Maskierung.
Also
urlencode()? Diese Funktion wandelt die Leerzeichen zu Plus-Zeichen um. Das Apostroph lässt sie jedoch stehen.darf sie auch gern, denn das[1] Apostroph ist ja in URL-Parametern nicht verboten und hat keine spezielle Bedeutung. Dafür sollte diese Funktion beispielsweise @ durch %40 oder # durch %23 ersetzen. Oder % durch %25.
Einen schönen Tag noch
Martin--
"Malen nach Zahlen" sagten wir im Matheunterricht, wenn es bei der Kurvendiskussion hieß: Zeichnen Sie den Graphen der Funktion ...
Manche sagen auch der Apostroph; ich habe in der Schule aber das gelernt. ↩︎
-
Hi,
darf sie auch gern, denn das Apostroph
Manche sagen auch der Apostroph; ich habe in der Schule aber das gelernt.
Muß das heutzutage nicht die Apostroph:in heißen?
cu,
Andreas a/k/a MudGuard -
Hallo Martin,
Manche sagen auch der Apostroph; ich habe in der Schule aber das gelernt.
ich auch. Scheint aber tatsächlich falsch zu sein: https://www.korrekturen.de/genus/der-oder-das-apostroph.shtml
Kurios.
-
-
-
-
-
Also logisch betrachtet gibt es da 3 Lösungen:
-
Du schleifst den Parameter in der URL mit und müsstest demnach alle Links anfassen.
-
Du findest dich damit ab, dass die Suche via Session gespeichert wird (kann auch ganz smart sein).
2-3. Du löscht die Parameter aus der Session, wenn der User auf eine "nicht Suchseite" kommt.
Eventuell kannst du es auch über Cookies lösen. Dann könntest du eine Zeit einstellen, wann der Cookie gelöscht wird. Somit könntest du verhindern, dass die Suche am nächsten Tag noch aktiv ist. Ist der User auf einer Suchseite wird der Cookie aktualisiert. Da kommen aber neue Probleme ... deshalb war nur eine nicht zu Ende Gedachte Idee, die neue Impulse bringen soll.
Gruß
Impulsgeber T-Rex-
Hallo T-Rex,
- Du findest dich damit ab, dass die Suche via Session gespeichert wird (kann auch ganz smart sein).
hatte ich eine Weile so gehabt, aber es hat sich nicht richtig angefühlt. Für mich trotzdem die zweitbeste Lösung.
2-3. Du löscht die Parameter aus der Session, wenn der User auf eine "nicht Suchseite" kommt.
Ja, könnte man machen. Klingt aber unnötig umständlich.
Eventuell kannst du es auch über Cookies lösen. Dann könntest du eine Zeit einstellen, wann der Cookie gelöscht wird. Somit könntest du verhindern, dass die Suche am nächsten Tag noch aktiv ist. Ist der User auf einer Suchseite wird der Cookie aktualisiert. Da kommen aber neue Probleme ... deshalb war nur eine nicht zu Ende Gedachte Idee, die neue Impulse bringen soll.
Hm... sicher, das ist ’ne Überlegung, aber ich finde Martins Argument mit der send- und speicherbaren Suche wirklich ausschlaggebend, deshalb habe ich mich tatsächlich für
- Du schleifst den Parameter in der URL mit und müsstest demnach alle Links anfassen.
entschieden. 😉
Trotzdem danke für die Impulse! 🙂
Grüße
Boris
-