Hallo Rolf, > du hast auf deiner Demo-Seite nur 3 Spiele (bzw. 3 Editionen eines Spiels) gelistet. Du schreibst aber auch, dass das Ganze sehr lang werden könne. Ja, ist eben nur zum Testen. > Wie hast Du Dir das denn gedacht? Du hast eine Spiele-DB mit 4711 Spielen und zeigst diese Liste jedem Spieler an? Und er (oder sie) wählt dann in 4711 Zeilen aus, was vorhanden ist, was nicht und was man nicht haben will? Ja, jeder Benutzer wird die Liste sehen. Registrierte Benutzer sollen die Checkbox-Werte verändern können. Das Ganze hat tatsächlich so angefangen, dass ich viele Jahre Videospiele gesammelt habe und irgendwann keine Übersicht mehr hatte, welche Edition ich schon hatte und welche nicht. So ist die Idee zu der Website entstanden. > Um das effizient zu speichern, brauchst Du > > - eine Tabelle mit den Usern > - eine Tabelle mit den Spielen > - eine Beziehungstabelle User-Spiel, wo der Checkbox-Status gespeichert wird. > Die SQL Query dafür würde dann sinngemäß so aussehen: > > ~~~sql > SELECT spiel.titel, spiel.edition, spiel.platform, spiel.region, spiel.jahr, > us.status > FROM spiel LEFT JOIN user_spiel us > ON us.spiel_id = spiel.id AND us.user_id = $user_id > ~~~ Klingt gut, das muss ich mal ausprobieren. Ich kenne nur ein paar SQL-Befehle und LEFT JOIN und ON gehören nicht dazu. Titel, Edition, Plattform usw. kommen übrigens nicht aus der Datenbank, sondern aus einer JSON-Datei. Ich habe nur den Wert der Checkboxen darin. > Einen der 3 Status (habich, habichnich, willichnich) speicherst Du **nicht**. Der, den Du nicht speicherst, ist sinnvollerweise der Wert, der als häufigster zu erwarten ist. Nicht pro User, sondern über alle User betrachtet. Ich denke, das ist "habe ich nicht" und das ist ja auch die Ausgangssituation, wenn ein neuer User kommt. Mir ist nicht daran gelegen, ein explizites „Habe ich nicht“ festzuhalten, daher würde ich diesen Wert nicht in der DB speichern. > Beim Zurückspeichern in die DB musst Du natürlich aufpassen. Ab besten ermittelst Du vor dem Zurückspeichern nochmal den aktuellen Stand, gleichst das mit den angekreuzten Werten ab und weißt dann, ob Du die Beziehungszeile für diesen User einfügen, ändern oder löschen musst. So hatte ich es vor. > Man **kann** die Sache auch als Stringwurst realisieren. Aber dann nicht als "2 0 1". Wenn überhaupt, musst Du die Zahlen mit der Spiel-ID verbinden. Gut zu wissen! > Der Vorteil ist die einfachere Handhabung beim Laden und Speichern. Der Nachteil ist, dass Du nicht eben mal in der DB selektieren kannst, wer die Black Phantom Edition hat. Oder wer die Standard-Edition partout nicht haben will. Das kannst Du nur mit der Beziehungstabelle elegant lösen. Wobei... die Abfrage auf den Wert, der nicht gespeichert wird, ist etwas mühsamer, denn da musst Du gucken welcher User für ein bestimmtes Spiel keinen Eintrag hat, das ist ein anderes SQL als für die beiden anderen Werte. Ja, das Auslesen muss ich noch einmal überdenken. > Beim UI bist Du mit einer Checkbox definitiv falsch bedient. Die kann nur "checked" oder "unchecked" speichern, d.h. du hast keine Chance, dass der Browser dem Server den ausgewählten Zustand meldet. Das geht nur mit einem select, mit zwei Checkboxen, mit radio buttons oder einem versteckten input-Element, in dem Du den Wert abspeicherst. Die visuelle Checkbox wäre dann ein reiner optischer Gimmick. An der Stelle wird die Anwendung unzugänglich - ohne JavaScript ginge gar nichts mehr und ein User ohne Maus oder ohne Sehvermögen rennt vermutlich in ein undurchdringliches Gestrüpp. Kein Problem, dann löse ich das anders … vielleicht mit den Radio-Buttons. Muss ich mal noch schauen. > Das Problem bei Radiobuttons ist, dass sie die Pfeiltasten umwidmen und die Leertaste ignorieren. Das könntest Du mittels JavaScript noch lösen. Auf jeden Fall brauchst Du eine visuelle Hervorhebung der aktuellen Zelle, um die Bedienbarkeit der Seite zu gewährleisten. Im Moment drücke ich Tab und sehe nicht, wo der Eingabefokus ist. > > Ob die Sache mit einem select Element, das man visuell versteckt, besser lösbar ist, weiß ich auch nicht recht. Aber so wie es ist, sollte es nicht bleiben. Es ist weder zugänglich noch bedienbar, es ist diskriminierenderweise nur für sehende Mausschubser geeignet, die obendrein erraten müssen, was deine Icons zu bedeuten haben. Als Screentoucher kann man zur Not klarkommen, benötigt aber einen Stylus, um mit dem dicken Finger nicht danebenzutippen. Das wird durch den Umstand, dass Du bei schmalem Viewport den Font verkleinerst und die "Checkboxen" gleich mit, nicht wirklich verbessert. Danke für die Hinweise, ich versuche, das noch zu optimieren. Die Bedeutung der Icons könnte man ganz einfach durch eine Legende lösen. Ist noch nichts final und einiges habe ich auch auf dem Schirm, jedoch noch nicht die Zeit gehabt, es auch umzusetzen.

Hallo Rolf, > du hast auf deiner Demo-Seite nur 3 Spiele (bzw. 3 Editionen eines Spiels) gelistet. Du schreibst aber auch, dass das Ganze sehr lang werden könne. Ja, ist eben nur zum Testen. > Wie hast Du Dir das denn gedacht? Du hast eine Spiele-DB mit 4711 Spielen und zeigst diese Liste jedem Spieler an? Und er (oder sie) wählt dann in 4711 Zeilen aus, was vorhanden ist, was nicht und was man nicht haben will? Ja, jeder Benutzer wird die Liste sehen. Registrierte Benutzer sollen die Checkbox-Werte verändern können. Das Ganze hat tatsächlich so angefangen, dass ich viele Jahre Videospiele gesammelt habe und irgendwann keine Übersicht mehr hatte, welche Edition ich schon hatte und welche nicht. So ist die Idee zu der Website entstanden. > Um das effizient zu speichern, brauchst Du > > - eine Tabelle mit den Usern > - eine Tabelle mit den Spielen > - eine Beziehungstabelle User-Spiel, wo der Checkbox-Status gespeichert wird. > Die SQL Query dafür würde dann sinngemäß so aussehen: > > ~~~sql > SELECT spiel.titel, spiel.edition, spiel.platform, spiel.region, spiel.jahr, > us.status > FROM spiel LEFT JOIN user_spiel us > ON us.spiel_id = spiel.id AND us.user_id = $user_id > ~~~ Klingt gut, das muss ich mal ausprobieren. Ich kenne nur ein paar SQL-Befehle und LEFT JOIN und ON gehören nicht dazu. > Einen der 3 Status (habich, habichnich, willichnich) speicherst Du **nicht**. Der, den Du nicht speicherst, ist sinnvollerweise der Wert, der als häufigster zu erwarten ist. Nicht pro User, sondern über alle User betrachtet. Ich denke, das ist "habe ich nicht" und das ist ja auch die Ausgangssituation, wenn ein neuer User kommt. Mir ist nicht daran gelegen, ein explizites „Habe ich nicht“ festzuhalten, daher würde ich diesen Wert nicht in der DB speichern. > Beim Zurückspeichern in die DB musst Du natürlich aufpassen. Ab besten ermittelst Du vor dem Zurückspeichern nochmal den aktuellen Stand, gleichst das mit den angekreuzten Werten ab und weißt dann, ob Du die Beziehungszeile für diesen User einfügen, ändern oder löschen musst. So hatte ich es vor. > Man **kann** die Sache auch als Stringwurst realisieren. Aber dann nicht als "2 0 1". Wenn überhaupt, musst Du die Zahlen mit der Spiel-ID verbinden. Gut zu wissen! > Der Vorteil ist die einfachere Handhabung beim Laden und Speichern. Der Nachteil ist, dass Du nicht eben mal in der DB selektieren kannst, wer die Black Phantom Edition hat. Oder wer die Standard-Edition partout nicht haben will. Das kannst Du nur mit der Beziehungstabelle elegant lösen. Wobei... die Abfrage auf den Wert, der nicht gespeichert wird, ist etwas mühsamer, denn da musst Du gucken welcher User für ein bestimmtes Spiel keinen Eintrag hat, das ist ein anderes SQL als für die beiden anderen Werte. Ja, das Auslesen muss ich noch einmal überdenken. > Beim UI bist Du mit einer Checkbox definitiv falsch bedient. Die kann nur "checked" oder "unchecked" speichern, d.h. du hast keine Chance, dass der Browser dem Server den ausgewählten Zustand meldet. Das geht nur mit einem select, mit zwei Checkboxen, mit radio buttons oder einem versteckten input-Element, in dem Du den Wert abspeicherst. Die visuelle Checkbox wäre dann ein reiner optischer Gimmick. An der Stelle wird die Anwendung unzugänglich - ohne JavaScript ginge gar nichts mehr und ein User ohne Maus oder ohne Sehvermögen rennt vermutlich in ein undurchdringliches Gestrüpp. Kein Problem, dann löse ich das anders … vielleicht mit den Radio-Buttons. Muss ich mal noch schauen. > Das Problem bei Radiobuttons ist, dass sie die Pfeiltasten umwidmen und die Leertaste ignorieren. Das könntest Du mittels JavaScript noch lösen. Auf jeden Fall brauchst Du eine visuelle Hervorhebung der aktuellen Zelle, um die Bedienbarkeit der Seite zu gewährleisten. Im Moment drücke ich Tab und sehe nicht, wo der Eingabefokus ist. > > Ob die Sache mit einem select Element, das man visuell versteckt, besser lösbar ist, weiß ich auch nicht recht. Aber so wie es ist, sollte es nicht bleiben. Es ist weder zugänglich noch bedienbar, es ist diskriminierenderweise nur für sehende Mausschubser geeignet, die obendrein erraten müssen, was deine Icons zu bedeuten haben. Als Screentoucher kann man zur Not klarkommen, benötigt aber einen Stylus, um mit dem dicken Finger nicht danebenzutippen. Das wird durch den Umstand, dass Du bei schmalem Viewport den Font verkleinerst und die "Checkboxen" gleich mit, nicht wirklich verbessert. Danke für die Hinweise, ich versuche, das noch zu optimieren. Die Bedeutung der Icons könnte man ganz einfach durch eine Legende lösen. Ist noch nichts final und einiges habe ich auch auf dem Schirm, jedoch noch nicht die Zeit gehabt, es auch umzusetzen.