Vor und Zurück Buttons erstellen (varX+1)

[ROLS733]

Servus,

ich hab jetz schon ewig gesucht, aber nichts gefunden deswegen frag ich jetz einfach hier :) Ich hab eine Seite wo wir Seminare anbieten. Von der Übersichtsseite kommt man mit

<a href="seminar-detail.php?var=' . ($row['ID']) . '";</a>

auf die jeweilige Detailseite des Seminars. Der Link sieht da so aus:

http://www.example.org/seminar-detail.php?var=3

Nun möchte ich auf der Detailseite unten jeweils ein vor und zurück Button einfügen mit dem man auf das nächste bzw. vorherige Seminar kommt. Also muss die Var nur eins erhöht oder verringert werden. Aber wie mach ich das am besten?

Vielen Dank schonmal für eure Hilfe :)

Arne

[Der Martin]

Moin,

Der Link sieht da so aus:

www.xxxxx.de/seminar-detail.php?var=3

Nun möchte ich auf der Detailseite unten jeweils ein vor und zurück Button einfügen mit dem man auf das nächste bzw. vorherige Seminar kommt. Also muss die Var nur eins erhöht oder verringert werden. Aber wie mach ich das am besten?

erhöhen heißt, 1 addieren; verringern heißt, 1 subtrahieren. Wo liegt genau das Problem?

Du musst nur aufpassen, dass auf der ersten und letzten Seite der Vor- bzw. Zurück-Link nicht ins Nirwana zeigt.

Ciao,
 Martin

[pl]

Aber wie mach ich das am besten?

Ich mach sowas über die Konfiguration/Routingtable. Da gibt es für zusammengehörige Seiten einmal den parent und des Weiteren die Attribute next und prev über die dann automatisch verlinkt wird.

Also muss die Var nur eins erhöht oder verringert werden.

Das wäre da nur entsprechend einzutragen. MFG

[Rolf B]

Hallo pl,

nicht mein Minus, aber es ist berechtigt. Man möchte sicherlich nicht bei - sagenwirmal - 100 Seminaren jedes Seminar in der Routingtabelle eintragen. Und bei fachlichen Änderungen der Seminare ständig die Routingtabelle pflegen.

Rolf

[pl]

nicht mein Minus, aber es ist berechtigt. Man möchte sicherlich nicht bei - sagenwirmal - 100 Seminaren jedes Seminar in der Routingtabelle eintragen. Und bei fachlichen Änderungen der Seminare ständig die Routingtabelle pflegen.

Doch, möchte man. Aber nicht händisch, denn dafür gibt es das CMS: Neue Seite erstellen oder vorhandene Seite editieren, Attribute setzen (parant, next, prev), fertig. Das ist das was der Autor macht, mehr nicht.

Ist es nicht der Sinn eines FW/CMS es so zu tun!? Ja! Genau das ist der Sinn! Und nein, mit der Routingtabelle hat der Autor gar nichts zu tun. Der weiß höchstens daß es sowas gibt.

Was die Bewertung betrifft: -1 ist einfach nur dumm. Da hat mal wieder jemand den Sinn eines CMS nicht verstanden. MFG

[Rolf B]

Hallo pl,

Die prev/next Beziehung in einem CMS ist möglicherweise dynamisch, vor allem, wenn es dabei um Reihenfolgen basierend auf irgendwelchen Seitenattributen geht (wie dem Seitentitel).

Wenn ich das über die Routingtabelle löse, muss ein Update eines Seitentitels bis zu 5 Einträge in der Routingtabelle ändern (next-Link des alten Vorgängers, prev-Link des alten Nachfolgers, next-Link des neuen Vorgängers, prev-Link des neuen Nachfolgers, prev- und next-Links der geänderten Seite). Sowas ist gar nicht multiuser-freundlich. Entweder lockst Du brutal, oder fliegst mit Race-Conditions aus der Kurve.

Was mit der Routingtabelle gar nicht geht, ist eine Prev/Next Navigation auf einer gefilterten Sicht. Arne beschreibt ja keine unabhängigen Dokumente, sondern Elemente einer Liste.

Rolf

[pl]

Eine Route zum Inhalt muss es immer geben! Es ist nur die Frage ob man die Routen statisch oder dynamisch verwaltet. Naheliegend ist es, eine URL wie /index.html als den statischen Teil zu betrachten. So ergibt sich ein optionaler dynamischer Anteil infolge Anhängen von Parametern like /index.html?x=y.MFG

[TS]

Hello,

Eine Route zum Inhalt muss es immer geben! Es ist nur die Frage ob man die Routen statisch oder dynamisch verwaltet. Naheliegend ist es, eine URL wie /index.html als den statischen Teil zu betrachten. So ergibt sich ein optionaler dynamischer Anteil infolge Anhängen von Parametern like /index.html?x=y

Es geht auch ohne URL-Parameter, indem man einfach einen Teil des URL-Pfades als Path-Info nutzt.

<Domain>/galerie/zimmer/33  

und im Dispatcher z. B. alle Requests, die mit /galerie/ anfangen, an sein Modul (Skript) galerie.php weiterreicht. Das Skript wertet dann "zimmer/33" als Path-Info aus und sucht den passenden Datenbankeintrag bzw. das Dokument.

Man kann selbstverständlich auch den ganzen Pfad als Path-Info benutzen und alle Requests an dasselbe Skript weiterreichen. Hängt ja nur vom Datenmodell dahinter ab.

So ähnlich meintest Du das vermutlich?

Ich finde die Methode mit sprechenden Pfaden immer eleganter, als die mit kryptischen Requestparametern. Und wenn die Pfade dann auch noch zum <title>-Element und zu den <h1> und dem Content des Dokumentes passen, wird der SEO meistens auch belohnt.

Glück Auf
Tom vom Berg

[pl]

So ähnlich meintest Du das vermutlich?

Genauso! Beispiel hier, Link next ganz unten. Statische Routingtable, vanity URLs. Und: Der Link kriegt automatisch den Title von der nächsten Seite. MFG

[Felix Riesterer]

Lieber Arne,

Du benötigst eine Gesamtliste aller IDs, sowie die aktuelle. Dann kannst Du anhand der Gesamtliste den jeweiligen Vorgänger und Nachfolger bestimmen.

ich hab jetz schon ewig gesucht, aber nichts gefunden

Der Suchbegriff wäre Paginierung oder pagination gewesen.

<a href="seminar-detail.php?var=' . ($row['ID']) . '";</a>

OMG. Du darfst hier zwar davon ausgehen, dass $row['id'] einen reinen Ziffern-String beinhaltet, trotzdem sind solche Konstrukte ein Programmierfehler, weil Du den Kontextwechsel nicht (sichtbar) berücksichtigst. Im Moment ist der ID-Wert eine Zahl, aber was, wenn das einmal geändert wird? Ich habe mir angewöhnt, meine Programmlogik so zu schreiben, dass mich solche Details nicht belasten können, da sie kontext-gerecht kodiert werden. Du darfst freilich tun, was Dir beliebt, aber was tut Dein Script bei einem Aufruf wie diesem hier?

/seminar-detail.php?var=%3BDROP%20TABLE%20seminar

Nun möchte ich auf der Detailseite unten jeweils ein vor und zurück Button einfügen

Du meinst Links, die wie Buttons gestyled sind. Für echte Buttons bräuchtest Du ein passendes Formular...

Also muss die Var nur eins erhöht oder verringert werden. Aber wie mach ich das am besten?

Wenn es nur das wäre, könntest Du einen geklammerten Ausdruck verwenden:

$str = '?' . ( $row['id'] + 1 );

Aber das genügt hier nicht. Es prüft nicht, ob es dieses Seminar überhaupt gibt. Daher mein Hinweis auf die Gesamtliste aller verfügbaren Seminare. Die steht in einem Array, welche so oder so ähnlich aus der Datenbank kommt:

$seminars = array(
  '123' => array(
    'id' => 123,
    'title' => 'Filmkritik: Das Leben des Brian',
    'time' => ...
   ),
  '125' => array(...)
);

$all = array_keys($seminars);
$next = array('id' => 0);
$prev = array('id' => 0);

$current = array_search($row['id'], $all);

if ($current >= 0
  && array_key_exists($current + 1)
) {
  $next = $seminars[$all[$current + 1]];
}

if ($current > 0
  && array_key_exists($current - 1)
) {
  $prev = $seminars[$all[$current - 1]];
}

// vorheriges Seminar verlinken?
if ($prev['id'] > 0) {
  // HTML für Link zum vorherigen Seminar
}

// nächstes Seminar verlinken?
if ($next['id'] > 0) {
  // HTML für Link zum nächsten Seminar
}

Der Code ist weder getestet noch vollständig. Aber Du solltest erkennen können, wie er bei einer nicht fortlaufenden Nummerierung der Seminare sich nicht zu falschen Links hinreißen lässt. Wie man den Kontextwechsel beim Erzeugen der Links berücksichtigt, lasse ich Dich alleine herausfinden. Link dazu habe ich oben angegeben.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

dein Kontextwechsel-Argument ist im Allgemeinen gültig, führt hier aber ein wenig in die Irre. Arne beschreibt keine Verarbeitung von User-Daten im SQL, sondern die Ausgabe von HTML basierend auf DB-Inhalten. Wenn also Kontextwechsel, dann von "fachlicher Text nach HTML", also für den Umstand, dass eine ID HTML Symbole enthält. Es sollte demnach ein htmlspecialchars($row['ID']) Aufruf erfolgen.

Das Code-Stück, mit dem die Details gelesen werden, hat Arne nicht gezeigt. Dort wäre der von Dir skizzierte DROP TABLE Angriff möglich, und dort muss der entsprechende escape-Aufruf erfolgen oder mit parameter binding gearbeitet werden. Wir wissen nicht, ob das bereits passiert, aber ich würde annehmen, dass deine Warnung an dieser Stelle nötig war.

Zum fachlichen Vorschlag: sicherlich kann man sich eine Liste sämtlicher IDs beschaffen; das setzt aber eine vollständige Lektüre der Seminartabelle voraus. Das würde ich mal vorsichtig als Performancerisiko betrachten, wenn es viele Seminare gibt. Ermitteln von direktem Vorgänger und Nachfolger unter einer bestimmten Sortierreihenfolge ist in SQL mühsam, aber machbar und mit entsprechendem Index auch performant. Siehe meinen Vorschlag.

Rolf

[TS]

Hello,

Zum fachlichen Vorschlag: sicherlich kann man sich eine Liste sämtlicher IDs beschaffen; das setzt aber eine vollständige Lektüre der Seminartabelle voraus. Das würde ich mal vorsichtig als Performancerisiko betrachten, wenn es viele Seminare gibt. Ermitteln von direktem Vorgänger und Nachfolger unter einer bestimmten Sortierreihenfolge ist in SQL mühsam, aber machbar und mit entsprechendem Index auch performant. Siehe meinen Vorschlag.

Wenn keine Direktverlinkung gewünscht ist (für Bookmarks notwendig), sondern nur ein Blättern möglich sein soll, ist das gar kein Problem. Dann nimmt man tatsächlich Buttons, z. B PREV und SUCC und merkt sich den SORT-Wert der aktuellen ID z. B. in der Session. Wird SUCC ausgewählt geht das Query ab SORT-Wert asc limited 3, wird PREV ausgewählt, läuft das Query ab dem SORT-Wert desc limited 3. Man hat im Ergebnis also immer nur ein, zwei oder drei Datensätze. Ich habe hier drei Sätze ab dem Sortwert genommen und nicht zwei (größer oder kleiner). Das ist je nach Umgebungslogik notwendig, dass man den gültigen SORT-Wert bei nur einem Satz im Ergebnis nicht verliert.

Enthält das Ergebnis drei Sätze, gibt es den gesuchten Nachfolger (oder Vorgänger). Außerdem bleibt der Button aktiv, weil es auch einen NachNachfolger (oder VorVorgänger) gibt.

Enthält das Ergebnis nur noch zwei DS, passiviert man den Button oder nimmt ihn ganz weg. Ich tendiere immer zu passivieren.

Enthält das Ergebnis nur noch einen DS, gobt man eine Meldung aus, dass in dieser Richtung keine DS mehr folgen. Wenn man vorher den Button passiviert hatte, sollte man hierhin gar nicht mehr gelangen. Aber das sind Feinheiten. :-)

Außerdem sollte man bei obiger Logik bezüglich der Bounds beachten, ob der Datenbestand dynamisch ist, sich also zwischen den Abfragen verändern kann.

Mit SQL-Injection dürfte es hier keine Probleme geben, da ja nur PREV und SUCC abgefragt werden und das Query nur aus Serverdaten zusammengestellt wird.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo Tom,

Buttons würde ich für grundsätzlich falsch halten. Du wechselst auf ein anderes Dokument. Das ist ein Link.

Wenn keine Direktverlinkung gewünscht ist

Angesichts der ID in der URL würde ich glauben, dass sich diese Frage nicht stellt.

Aber mal angenommen, man würde deine PREV und SUCC Buttons implementieren. Was genau sollten sie auf der Seite seminar_details?var=3 tun? (Mal abgesehen davon, dass der Parameter mit var schlecht benannt ist; er sollte id heißen)

Einen Postback auf seminar_details?var=3 und submit=prev im POST-Body? In dem Fall müsste der Server die ID der vorigen Seite ermitteln, und dann per Location-Header einen Redirect zur richtigen Seite auslösen, denn andernfalls würdest Du in der URL var=3 anzeigen, während var=7 dargestellt wird. Wenn man dann den "Zurück" Button des Browsers drückt, gibt es die "Soll das normal übermittelt werden?" Rückfrage. Ist das gute UX? Oder verstehe ich einfach nur deinen Ansatz nicht?

Rolf

[TS]

Hello,

steht eigentlich alles drin in meinem Posting.

Ich habe einen Lösungsweg mit Session beschrieben, bei dem kein Zugang zu den Records per URi (Direktverlinkung) vorgesehen ist. Die Requestparameter sind folglich überflüssig.

Ob das Gesetz ist, dass jeder Dokumentinhalt eine eigene URi haben muss, konnte ich nirgends finden. Ich kenne nur die Regeln:

• Bookmarking möglich = URi und GET
• kein Bookmarking möglich = Buttons und POST
• für DM-Statements grundsätzlich POST

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Ob das Gesetz ist, dass jeder Dokumentinhalt eine eigene URi haben muss,

Wenn es um Dokumente geht (das Seminar Nr 4711 wäre mNn eins), dann würde ich das als Teil des Hypertext-Konzepts sehen. Statt "das ist Gesetz" würde ich aber lieber "das ist gesetzt" formulieren wollen :)

Grundsätzlich sehe ich das so: wenn die URI eine ID enthält, dann sollte man annehmen, dass sie bookmarkfähig ist und demnach bei Navigationen zum dargestellten Inhalt passen muss. Ein System, das nicht bookmarkfähig ist, hält die ID komplett aus der URI heraus und speichert die aktuelle Dokument-ID in der Session, wie von Dir vorgeschlagen. In dem Fall kann man dann auch Postbacks machen, die die URI unverändert lassen und lediglich einen anderen Inhalt liefern.

Mein Einwand war: Die Verwendung von nicht bookmarkfähigen URLs, insbesondere Navigation per POST, macht den Umgang mit der Vor/Zurück Navigation des Browsers schwierig. Solche Navigationen findet man oft, und genauso oft steht auf den Seiten "Verwenden Sie nicht den Zurück-Button Ihres Browsers".

URLs, die den dargestellten Zustand der Application exakt beschreiben, sind aus meiner Sicht besser, weil man dem User damit nicht vorschreibt, wie er auf der Seite navigieren darf.

Rolf

[TS]

Hello,

ok, um den Browser zufrieden zu stellen, muss man entweder die Cache und Pragmaeinstellungen durchschauen und darauf vertrauen, dass der Browser das auch tut :-O

oder man muss nach dem Post mit einem Location Header einen Redirect per GET veranlassen. Da sind wir aber wieder am Startpunkt unserer gedanklichen Kreisbahn angekommen. :-)

Glück Auf
Tom vom Berg

[Auge]

Hallo

ok, um den Browser zufrieden zu stellen, muss man entweder die Cache und Pragmaeinstellungen durchschauen und darauf vertrauen, dass der Browser das auch tut :-O

oder man muss nach dem Post mit einem Location Header einen Redirect per GET veranlassen. Da sind wir aber wieder am Startpunkt unserer gedanklichen Kreisbahn angekommen. :-)

… oder man macht es sich einfach und nutzt den von HTML dafür vorgesehenen Mechanismus von Links, die einen GET-Request senden, ohne dass dieser simuliert oder umständlich per Redirect ausgelöst werden müsste.

Tschö, Auge

[Der Martin]

Hi,

ok, um den Browser zufrieden zu stellen, muss man entweder die Cache und Pragmaeinstellungen durchschauen und darauf vertrauen, dass der Browser das auch tut :-O

oder man muss nach dem Post mit einem Location Header einen Redirect per GET veranlassen. Da sind wir aber wieder am Startpunkt unserer gedanklichen Kreisbahn angekommen. :-)

… oder man macht es sich einfach und nutzt den von HTML dafür vorgesehenen Mechanismus von Links, die einen GET-Request senden, ohne dass dieser simuliert oder umständlich per Redirect ausgelöst werden müsste.

eben - ich habe mich nämlich auch schon gefragt, warum Tom so von hinten durch die Brust ins Knie schießen will. Ob man nun Links mit URL-Parameter baut oder lieber lesefreundliche URLs, ist dann eine Frage der Kosmetik und der Benutzerfreundlichkeit.

Schönen Nachmittag,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Ob man nun Links mit URL-Parameter baut oder lieber lesefreundliche URLs, ist dann eine Frage der Kosmetik und der Benutzerfreundlichkeit.

Und eine Frage des Gefunden-Werdens. Bei der Suche nach „Hommingberger Gepardenforelle“ sollte https://example.net/articles/hommingberger-gepardenforelle höher ranken als https://example.net/?article=12345.

LLAP 🖖

[Auge]

Hallo

Ob man nun Links mit URL-Parameter baut oder lieber lesefreundliche URLs, ist dann eine Frage der Kosmetik und der Benutzerfreundlichkeit.

Und eine Frage des Gefunden-Werdens. Bei der Suche nach „Hommingberger Gepardenforelle“ sollte https://example.net/articles/hommingberger-gepardenforelle höher ranken als https://example.net/?article=12345.

Ist das nicht Teil der Benutzerfreundlichkeit (mit positiven Nebenwirkungen)?

Tschö, Auge

[TS]

Hello,

Ob man nun Links mit URL-Parameter baut oder lieber lesefreundliche URLs, ist dann eine Frage der Kosmetik und der Benutzerfreundlichkeit.

Und eine Frage des Gefunden-Werdens. Bei der Suche nach „Hommingberger Gepardenforelle“ sollte https://example.net/articles/hommingberger-gepardenforelle höher ranken als https://example.net/?article=12345.

Ist das nicht Teil der Benutzerfreundlichkeit (mit positiven Nebenwirkungen)?

Dax sollte Standard sein, wenn man seine Besucher ernst nimmt.

Glück Auf
Tom vom Berg

[TS]

Hello,

ok, um den Browser zufrieden zu stellen, muss man entweder die Cache und Pragmaeinstellungen durchschauen und darauf vertrauen, dass der Browser das auch tut :-O

oder man muss nach dem Post mit einem Location Header einen Redirect per GET veranlassen. Da sind wir aber wieder am Startpunkt unserer gedanklichen Kreisbahn angekommen. :-)

… oder man macht es sich einfach und nutzt den von HTML dafür vorgesehenen Mechanismus von Links, die einen GET-Request senden, ohne dass dieser simuliert oder umständlich per Redirect ausgelöst werden müsste.

eben - ich habe mich nämlich auch schon gefragt, warum Tom so von hinten durch die Brust ins Knie schießen will. Ob man nun Links mit URL-Parameter baut oder lieber lesefreundliche URLs, ist dann eine Frage der Kosmetik und der Benutzerfreundlichkeit.

Ich habd doch lediglich vorgetragen, wie es per POST-Button gehen kann, in der Sortierung vorwärts und rückwärts zu blättern. Das geht per Link selbstverständlich auch.

Was man per Link aber nicht machen sollte, ist DM-Statements zu füttern und auszulösen. Dafür sollte man dann schon den POST-Button benutzen und anschließend den geänderten Datensatz per Location-Header wieder anzeigen lassen. Insbesondere bei Listen interessant.

Die nächste Stufe wäre dann sicherlich AJAX.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Was man per Link aber nicht machen sollte, ist DM-Statements zu füttern und auszulösen.

99% einverstanden. Das 1% ist das Update von "Ihre besuchten Seiten" für die späteren Werbemails 😉

Aber das war ja auch gar nicht Thema des Thread.

Rolf

[TS]

Hello,

Was man per Link aber nicht machen sollte, ist DM-Statements zu füttern und auszulösen.

99% einverstanden. Das 1% ist das Update von "Ihre besuchten Seiten" für die späteren Werbemails 😉

Aber das war ja auch gar nicht Thema des Thread.

Die Frage war: wie mach ich das mit einem Button?
Gezeigt wurde eine URL mit Requestparametern.

Die habe ich (per Formular und Post-Button) wegrationalisiert und mich auf die mögliche Datenbanklogik konzentriert.

Da Buttons lt. anderem Teilthread auch ohne Formular möglich sind, ist das Thema noch nicht zuende.

Außerdem müsste noch gezeigt werden, wie es mit URL-Parameter respektive Links in dynamischen Datenbeständen funktioniert. Da ist ja bestenfalls der aktive DS später noch gültig, die Positionen für PREV und NEXT sind dann aber ggf. schon irreführend, weil DS dazu gekommen sein können. Das ist übrigens ein beliebter Fehler in vielen CS-Verwaltungsapplikationen.

Glück Auf
Tom vom Berg

[Felix Riesterer]

Lieber TS,

Da Buttons lt. anderem Teilthread auch ohne Formular möglich sind, ist das Thema noch nicht zuende.

das ist ein Missverständnis. Buttons völlig ohne zugehörigem Formular haben keine Funktion. Ob sie nun als Nachfahrenelement innerhalb des Formulars, oder außerhalb wild verstreut mit passendem form-Attribut notiert werden, ist da zweitrangig, Hauptsache sie gehören zu einem.

Liebe Grüße

Felix Riesterer

[TS]

Hello,

Da Buttons lt. anderem Teilthread auch ohne Formular möglich sind, ist das Thema noch nicht zuende.

das ist ein Missverständnis. Buttons völlig ohne zugehörigem Formular haben keine Funktion. Ob sie nun als Nachfahrenelement innerhalb des Formulars, oder außerhalb wild verstreut mit passendem form-Attribut notiert werden, ist da zweitrangig, Hauptsache sie gehören zu einem.

<modus grad="besserwessi">mit AJAX können sie auch ohne Formular eine Wirkung haben</modus>

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Das Code-Stück, mit dem die Details gelesen werden, hat Arne nicht gezeigt. Dort wäre der von Dir skizzierte DROP TABLE Angriff möglich, und dort muss der entsprechende escape-Aufruf erfolgen oder mit parameter binding gearbeitet werden.

...;DROP TABLE ... hat bei PHP mit MySQL noch nie funktioniert, wenn nicht mysql(i)_multi_query() verwendet wird. Und da das üblicherweise nicht zum Einsatz kommt, kann man als SQL-Injector nur mit Statement-Erweiterungen arbeiten, nicht aber mit mehreren.

dedlfix.

[Matthias Apsel]

Hallo Felix Riesterer,

Nun möchte ich auf der Detailseite unten jeweils ein vor und zurück Button einfügen

Du meinst Links, die wie Buttons gestyled sind. Für echte Buttons bräuchtest Du ein passendes Formular...

Ja, aber nein. Ja, weil zu einer anderen Seite navigiert werden soll. Nein, weil buttons auch ohne Formular existieren können. Das Formular wird nur benötigt, wenn Daten versendet werden sollen. (Dass das form-Element semantisch passend ist, bedeutet nicht, dass es notwendig wäre.)

Bis demnächst
Matthias

[Felix Riesterer]

Lieber Matthias,

Nein, weil buttons auch ohne Formular existieren können. Das Formular wird nur benötigt, wenn Daten versendet werden sollen. (Dass das form-Element semantisch passend ist, bedeutet nicht, dass es notwendig wäre.)

und wie genau bringst Du einen Button ohne umgebendes Formular dazu, dass eine neue Seite mit einem bestimmten URL-Parameter aufgerufen wird? Und bitte ohne JavaScript!

Liebe Grüße

Felix Riesterer

[MudGuard]

Hi,

und wie genau bringst Du einen Button ohne umgebendes Formular dazu, dass eine neue Seite mit einem bestimmten URL-Parameter aufgerufen wird? Und bitte ohne JavaScript!

mit dem form-Attribut.

Das form muß nicht (mehr) Vorfahre des Buttons sein.

(abgesehen davon hatte Matthias ja explizit gesagt, daß das form beim Versand von Daten benötigt wird)

cu,
Andreas a/k/a MudGuard

[Felix Riesterer]

Lieber MudGuard,

mit dem form-Attribut.

dieses hat aber nur einen Sinn, wenn es ein Formular mit passender ID gibt. Völlig ohne Formular hat ein Button keine Funktion.

Das form muß nicht (mehr) Vorfahre des Buttons sein.

Um diesen Umstand ging es Matthias gemäß seiner Formulierung offensichtlich nicht. Sonst hätte ich ja keine Einwände gehabt.

(abgesehen davon hatte Matthias ja explizit gesagt, daß das form beim Versand von Daten benötigt wird)

Richtig, aber nicht, dass ein solcher Versand für den hier benötigten Zweck (oder Effekt) zwingend erforderlich ist.

Liebe Grüße

Felix Riesterer

[Matthias Apsel]

Hallo Felix Riesterer,

dieses hat aber nur einen Sinn, wenn es ein Formular mit passender ID gibt. Völlig ohne Formular hat ein Button keine Funktion.

Nein. Ein <button type=button> funktioniert ohne Formular.

(abgesehen davon hatte Matthias ja explizit gesagt, daß das form beim Versand von Daten benötigt wird)

Richtig, aber nicht, dass ein solcher Versand für den hier benötigten Zweck (oder Effekt) zwingend erforderlich ist.

Deshalb schrieb ich

Ja, weil zu einer anderen Seite navigiert werden soll.

Bis demnächst
Matthias

[Der Martin]

Hi,

dieses hat aber nur einen Sinn, wenn es ein Formular mit passender ID gibt. Völlig ohne Formular hat ein Button keine Funktion.

Nein. Ein <button type=button> funktioniert ohne Formular.

da könnte man jetzt spitzfindig sein und widersprechen. Ein <button type="button"> hat nämlich von sich aus gar keine Funktion. Erst mit Javascript bekommt er eventuell eine.

Ciao,
 Martin

[Auge]

Hallo

dieses hat aber nur einen Sinn, wenn es ein Formular mit passender ID gibt. Völlig ohne Formular hat ein Button keine Funktion.

Nein. Ein <button type=button> funktioniert ohne Formular.

da könnte man jetzt spitzfindig sein und widersprechen. Ein <button type="button"> hat nämlich von sich aus gar keine Funktion. Erst mit Javascript bekommt er eventuell eine.

Ja, aber genau dann braucht er eben auch keinen Bezug zu irgendeinem Formular.

Tschö, Auge

[Felix Riesterer]

Liebes Auge,

da könnte man jetzt spitzfindig sein und widersprechen. Ein <button type="button"> hat nämlich von sich aus gar keine Funktion. Erst mit Javascript bekommt er eventuell eine.

Ja, aber genau dann braucht er eben auch keinen Bezug zu irgendeinem Formular.

warum nur fühle ich mich durch die Entwicklung dieses Teilthreads zunehmend verarscht...?

Liebe Grüße

Felix Riesterer

[Auge]

Hallo

da könnte man jetzt spitzfindig sein und widersprechen. Ein <button type="button"> hat nämlich von sich aus gar keine Funktion. Erst mit Javascript bekommt er eventuell eine.

Ja, aber genau dann braucht er eben auch keinen Bezug zu irgendeinem Formular.

warum nur fühle ich mich durch die Entwicklung dieses Teilthreads zunehmend verarscht...?

Ich habe absolut keine Ahnung.

Tschö, Auge

[Felix Riesterer]

Lieber Matthias,

Nein. Ein <button type=button> funktioniert ohne Formular.

mir fehlt der entsprechende Humor, um diesen Witz lustig zu finden.

Liebe Grüße

Felix Riesterer

[Matthias Apsel]

Hallo Felix Riesterer,

mir fehlt der entsprechende Humor, um diesen Witz lustig zu finden.

Es war nicht meine Intention witzig zu sein. Du schriebst: „Du meinst Links, die wie Buttons gestyled sind“. Dem stimme ich unumwunden zu.

Weiter schriebst du „Für echte Buttons bräuchtest Du ein passendes Formular...“. Das stimmt zwar für den speziellen Fall, ist aber eben nicht immer richtig.

Bis demnächst
Matthias

[Rolf B]

Hallo Arne,

wenn Du denn ganz sicher bist, dass die IDs fortlaufend sind, könntest Du das mit einer Addition machen. Dagegen gibt es aber zwei Einwände.

1. formal: IDs sollten unsprechend sein, d.h. auch kein fortlaufende Reihenfolge bestimmen.
2. technisch: Was ist, wenn ein Seminar gelöscht wurde? Dann fehlt eine ID und der Link geht ins Leere. IDs reorganisieren? Denk nicht mal dran. IDs sind unveränderlich. Und es gibt auch andere Umstände, unter denen IDs nicht fortlaufend sind.

Deshalb: nicht machen!

Ich würde mutmaßen, dass deine Seminare nach einem fachlichen Schlüssel sortierbar sein sollten, und gemäß dieses fachlichen Schlüssels sollte auch vor/zurück funktionieren.

D.h. beim Aufbereiten der Seite mit ID=3 musst Du ermitteln, welche Seminare in der logischen Reihenfolge der aktuellen Seite vorangehen und nachfolgen. Ich würde annehmen, dass Du auf einem XAMP System unterwegs bist und demnach PHP und MYSQL verwendest.

Irgendwo in deinem seminar-detail.php Script wird also ein MYSQL-Aufruf stehen, der Dir die anzuzeigenden Detailinformationen zum Seminar mit der geforderten ID beschafft. In diesem Aufruf solltest Du die IDs des vorigen und nächsten Seminars ermitteln.

Das kann man mit zwei Subselects machen, die man dem SELECT für die Details hinzufügt. Damit das nicht langsam wird, muss auf der Spalte name ein Index liegen.

SELECT s.id, s.name, s.column3, ..., s.columnN
     , (select id from seminare s1 
           where s1.name < s.name order by s1.name desc limit 1) as prev_id
     , (select id from seminare s2
           where s2.name > s.name order by s2.name limit 1) as next_id
FROM seminare s
where id = ?

So entstehen die Spalten prev_id und next_id, die NULL sind, falls das angezeigte Seminar das erste, letzte oder einzige in der Liste ist, und andernfalls die für das Blättern benötigte ID enthalten.

Auf diese Weise bekommst Du allerdings nur die ID, nicht den Namen des vorigen und nächsten Seminars. Wenn Du die auch brauchst, stößt Du auf Probleme.

• Subselects können immer nur eine Spalte liefern. Braucht man mehr, muss man LEFT JOIN verwenden
• Aber es gibt keine direkte SQL Formulierung für "joine nur eine Row von mehreren".
• Man kann das über einen zugejointen Tabellenausdruck lösen. Aber innerhalb dieses Ausdrucks sind die Spalten der primären Table nicht bekannt und du kannst keine Namen vergleichen.

Meine Empfehlung wäre daher ein eigenständiges zweites SQL, um ID und NAME von vorigem und näcshtem Seminar zu bekommen.

SELECT p.id as prev_id, p.name as prev_name, n.id as next_id, n.name as next_name
  FROM (SELECT id, name FROM seminare WHERE name < ? ORDER BY name DESC LIMIT 1) p,
       (SELECT id, name FROM seminare WHERE name > ? ORDER BY name LIMIT 1) n

Dieser Query-Vorschlag oben macht zwei Index-Seeks (vorausgesetzt dass auf der Spalte Name ein Index liegt) und ist damit ziemlich fix.

Ich habe es auch mit einem UNION probiert - aber dann sagt mir EXPLAIN, dass der zweite SELECT im UNION den Index nicht verwendet. Sehr merkwürdig, vielleicht ein Bug in dem MYSQL 5.6 das ich hier herumliegen habe.

Rolf

[Matthias Apsel]

Hallo Rolf B,

1. formal: IDs sollten unsprechend sein, d.h. auch kein fortlaufende Reihenfolge bestimmen.

Diese ID muss nicht mit der ID in der Datenbank identisch sein.

2. technisch: Was ist, wenn ein Seminar gelöscht wurde? Dann fehlt eine ID und der Link geht ins Leere.

Zumindest wegen der Möglichkeit des bookmarkens sollte man die Seminare niemals löschen.

Bis demnächst
Matthias

[Rolf B]

Hallo Matthias,

ja gut, aber, anderes Argument, irgendwann biete ich ein Seminar nicht mehr an, und dann sollte der "vor"/"zurück" Link es nicht mehr aufrufen, egal ob physisch gelöscht oder nicht. Einfache ID Arithmetik ist darum immer falsch. Virtuelle IDs für die URL zu generieren, hm, lohnt das? Macht das dieses Problem hier einfacher? Ich sehe es noch nicht.

Ein Bookmark auf ein nicht mehr verfügbares Seminar ist was anderes. Eine http 404 Antwort zusammen mit einer sinnvollen Angebotsseite würde ich nicht für falsch halten. Per "vor" dorthin zu kommen dagegen schon.

Rolf

[TS]

Hello,

Ein Bookmark auf ein nicht mehr verfügbares Seminar ist was anderes. Eine http 404 Antwort zusammen mit einer sinnvollen Angebotsseite würde ich nicht für falsch halten. Per "vor" dorthin zu kommen dagegen schon.

Ja!
Und anders herum auch. Wenn harte Links im Dokument für PREV und NEXT stehen, kann auch leicht ein inzwischen hinzugekommener DS übersprungen werden. "Nächster Zug fährt morgen". Sch..., dass ich den in 20Min. überblättert habe ;-)

Glück Auf
Tom vom Berg

[Auge]

Hallo

Und anders herum auch. Wenn harte Links im Dokument für PREV und NEXT stehen, kann auch leicht ein inzwischen hinzugekommener DS übersprungen werden.

Bei einzelnen Seiten für in sich geschlossene Seminare könnte man die Frage stellen, warum die zwischen zwei älteren Seminaren eingeordnet statt hinten dran gehängt werden sollten, aber schon thematische Gruppierungen sind eine mögliche Begründung dafür.

"Nächster Zug fährt morgen". Sch..., dass ich den in 20Min. überblättert habe ;-)

Passt die Zeitform? Passt nicht eher „Sch..., dass ich den in 20Min. überblättert haben werde“ oder gar „… gehabt haben werde“? 😉

Tschö, Auge

[TS]

Hello,

"Nächster Zug fährt morgen". Sch..., dass ich den in 20Min. überblättert habe ;-)

Passt die Zeitform? Passt nicht eher „Sch..., dass ich den in 20Min. überblättert haben werde“ oder gar „… gehabt haben werde“? 😉

Es käme auch noch ein Konjunktiv in Betracht ;-)

Glück Auf
Tom vom Berg

[Der Martin]

Moin,

"Nächster Zug fährt morgen". Sch..., dass ich den in 20Min. überblättert habe ;-)

Passt die Zeitform? Passt nicht eher „Sch..., dass ich den in 20Min. überblättert haben werde“ oder gar „… gehabt haben werde“? 😉

Es käme auch noch ein Konjunktiv in Betracht ;-)

"überblättert haben könnte"?
Futur II bei Sonnenaufgang braucht man jedenfalls fürs Jodeldiplom.

*scnr*
 Martin

[Auge]

Hallo

Passt die Zeitform? Passt nicht eher „Sch..., dass ich den in 20Min. überblättert haben werde“ oder gar „… gehabt haben werde“? 😉

Es käme auch noch ein Konjunktiv in Betracht ;-)

"überblättert haben könnte"?
Futur II bei Sonnenaufgang braucht man jedenfalls fürs Jodeldiplom.

Man könnte als Steigerung noch die Onkel-Hotte-Gedächtnis-Grammatik dranhängen. „Sch..., dass ich den in 20Min. überblättert gehabt haben werde, getun, getan, getätet haben tun <schlorz style="hochzieh: top;"/>.“

Tschö, Auge

[Tabellenkalk]

Hallo,

Es käme auch noch ein Konjunktiv in Betracht ;-)

"überblättert haben könnte"?
Futur II bei Sonnenaufgang braucht man jedenfalls fürs Jodeldiplom.

Seid ihr sicher, dass hier nicht Futur III zur Anwendung gekommt haben werden müsste?

Gruß
Kalk

[MudGuard]

Hi,

Seid ihr sicher, dass hier nicht Futur III zur Anwendung gekommt haben werden müsste?

7 Jahre nach dem Artikel, und der Eröffnungstermin wird immer noch in ferner Zukunft wären gewesen …

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo Tom,

gut, es gibt bei harten Links, die beim Seitenabruf generiert werden, eine zeitliche Lücke von 10s bis 10 Stunden, bis jemand auf PREV oder NEXT drückt. Da es hier nicht um Fahrpläne geht (die zumindest gestern abend in Köln extrem volatil waren), sondern um Seminare, halte ich das für akzeptabel.

Die Alternative ist das POST + Redirect Pattern, d.h. man hat einen Button für PREV oder NEXT, der die neue ID bestimmt und dann mit header("location:..." auf die neue Seite weiterleitet. Das sind dann nur eben zwei Requests. Statt mit POST und Redirect kann man es auch über JavaScript implementieren, das läuft aber letztlich auf's gleiche 'raus: 2 Requests.

Ohne header("location:") hat man einen POST Request im Browser-Verlauf, der mit OK beantwortet wurde und darum in der History landet. Zum einen ist der Zurück-Button des Browsers dann sehr lästig zu bedienen, zum anderen führt er (bei mir) zu falschen Ergebnissen. Statt auf die vorige Seite zu kommen blätterte er weiter vorwärts, weil die FORWARD-Operation wiederholt wurde.

Rolf