Linuchs: Leere Checkbox erkennen

083

Leere Checkbox erkennen

  1. 0
  2. 1
    1. 0
      1. 1
        1. -1
          1. 0
            1. 0
              1. 0
                1. 0
                2. 0
                  1. 0
                    1. 0
                      1. 0
          2. 0
        2. 0

          HTML ist an vielen Stellen noch unsinnig!

          1. 0
          2. 0
            1. 0
              1. 0
                1. 0
                2. 0
                3. 0
          3. 0
          4. 0
          5. 0
            1. 0
              1. 0
  3. 0
    1. 0
      1. 0
  4. 0
    1. 0
      1. 0
      2. 0
        1. 0
    2. 0
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0
                1. 0
                  1. 0
                2. 0
                  1. 2
                3. 0
                  1. 0
                    1. 0
                      1. 0
                        1. 0
                          1. 2
                            1. 0
                              1. 0
                              2. 0
                          2. 0
                            1. 0
                              1. 0
                                1. 0
                              2. 0
                            2. 0
                              1. 0
                              2. 1
                                1. 0
                                  1. 0
                      2. -3
                        1. 0
                          1. 0
                            1. 1
                              1. 0
                              2. 0
              2. 0
                1. 0
                2. 0
                  1. 0
                    1. 0
                    2. 0

                      Vertrauen auf die Gerichte?

    3. 1
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0

Moin,

für eine JA / NEIN Aussage ist input type checkbox geeignet.

Aber der Wechsel von JA zu NEIN wird nicht gemeldet, weil eine leere Checkbox nicht übermittelt wird.

Andererseits kann die fehlende Information in meinen Projekten nicht als NEIN interpretiert werden, denn ich habe diverse Formulare und eine nicht vorhandene Checkbox darf nicht als Antwort gewertet werden.

Behelfe mich in den Formularen, die Checkboxen enthalten, mit einem input type hidden. Wenn das gesetzt ist und die Checkbox-Info fehlt, dann bedeutet das NEIN.

Geht das auch einfacher? Könnte man die Checkbox zwingen, auch ein NEIN zu übermitteln?

Gruß, Linuchs

  1. Geht das auch einfacher? Könnte man die Checkbox zwingen, auch ein NEIN zu übermitteln?

    Einfacher vielleicht nicht, aber per JS kannst jede checkbox ob .checked befragen und aus true//false machen wo Du wolle.

  2. hallo

    Moin,

    für eine JA / NEIN Aussage ist input type checkbox geeignet.

    Aber der Wechsel von JA zu NEIN wird nicht gemeldet, weil eine leere Checkbox nicht übermittelt wird.

    Andererseits kann die fehlende Information in meinen Projekten nicht als NEIN interpretiert werden, denn ich habe diverse Formulare und eine nicht vorhandene Checkbox darf nicht als Antwort gewertet werden.

    Behelfe mich in den Formularen, die Checkboxen enthalten, mit einem input type hidden. Wenn das gesetzt ist und die Checkbox-Info fehlt, dann bedeutet das NEIN.

    Geht das auch einfacher? Könnte man die Checkbox zwingen, auch ein NEIN zu übermitteln?

    Zwei Radiobuttons sind am einfachsten.

    Du hast immer noch die Wahl, welcher falls überhaupt, den Defaultzustand haben soll. Wobei ich raten würde auch diesen Zustand zu definieren

    <input name="group1" type=radio value=unset selected> Diesen Button kann man auch verbergen <input name="group1" type=radio value=false> <input name="group1" type=radio value=true>

    Du hast dann immer eine definierte Information zur Auswertung.

    -- https://beat-stoecklin.ch/pub/index.html

    Folgende Nachrichten verweisen auf diesen Beitrag:

    1. Inputfelder kennen keinen Default, weder für name noch für value. Wenn mit einem legacy Submit input Felder übermittelt werden sollen, müssen sie einen Namen und einen Wert haben.

      Bez. type=checkbox oder type=radio wird value übermittelt, wenn checked.

      1. hallo

        Inputfelder kennen keinen Default,

        <input type=radio selected value="you are wrong">

        -- https://beat-stoecklin.ch/pub/index.html
        1. Der Begriff Default ist hier vielen gar nicht klar!

          1. hallo

            Der Begriff Default ist hier vielen gar nicht klar!

            Dann klär uns auf.

            -- https://beat-stoecklin.ch/pub/index.html
            1. Ein Default ist ein Stellvertreter. So hat zum Beispiel jedes <form>, sofern nicht angegeben, als Default das Attribut enctype='application/x-www-form-urlencoded'.

              Gleichermaßen gibt es einen gleichnamigen Default für den Header Content-Type. Das heißt, ein Default ist das was zum Tragen kommt für etwas was nicht angegeben ist. Was den Content-Type betrifft, ein solcher muss gar nicht gesendet werden, dafür wird serverseitig der Default angenommen.

              Die Attribute name und value in <input>-Feldern sind nicht zwingend vorgegeben. Und wenn sie nicht definiert sind, gibt es keinen Default. Es gilt immer nur das, was da tatsächlich notiert oder nicht notiert ist.

              .

              1. hallo

                Ein Default ist ein Stellvertreter. So hat zum Beispiel jedes <form>, sofern nicht angegeben, als Default das Attribut enctype='application/x-www-form-urlencoded'.

                Gleichermaßen gibt es einen gleichnamigen Default für den Header Content-Type. Das heißt, ein Default ist das was zum Tragen kommt für etwas was nicht angegeben ist. Was den Content-Type betrifft, ein solcher muss gar nicht gesendet werden, dafür wird serverseitig der Default angenommen.

                Die Attribute name und value in <input>-Feldern sind nicht zwingend vorgegeben. Und wenn sie nicht definiert sind, gibt es keinen Default. Es gilt immer nur das, was da tatsächlich notiert oder nicht notiert ist.

                Es ist also nicht ausgeschlossen, dass ich ein default-Verhalten definieren kann.

                -- https://beat-stoecklin.ch/pub/index.html
                1. Hello,

                  hallo

                  Ein Default ist ein Stellvertreter. So hat zum Beispiel jedes <form>, sofern nicht angegeben, als Default das Attribut enctype='application/x-www-form-urlencoded'.

                  Gleichermaßen gibt es einen gleichnamigen Default für den Header Content-Type. Das heißt, ein Default ist das was zum Tragen kommt für etwas was nicht angegeben ist. Was den Content-Type betrifft, ein solcher muss gar nicht gesendet werden, dafür wird serverseitig der Default angenommen.

                  Die Attribute name und value in <input>-Feldern sind nicht zwingend vorgegeben. Und wenn sie nicht definiert sind, gibt es keinen Default. Es gilt immer nur das, was da tatsächlich notiert oder nicht notiert ist.

                  Es ist also nicht ausgeschlossen, dass ich ein default-Verhalten definieren kann.

                  ... dessen Werte sich dann mMn dann bei auslösen eines "RESET"-Events wieder einstellen sollten.

                  Glück Auf
                  Tom vom Berg

                  -- Es gibt nichts Gutes, außer man tut es!
                  Das Leben selbst ist der Sinn.
                2. Es ist also nicht ausgeschlossen, dass ich ein default-Verhalten definieren kann.

                  Dafür bist Du Programmierer. Es wäre schlimm, wenn Du das nicht könntest.

                  Bitte nochmal mit Essenz! Welchen substantiierten Rat gibst Du dem VP?

                  MfG

                  1. hallo

                    Es ist also nicht ausgeschlossen, dass ich ein default-Verhalten definieren kann.

                    Dafür bist Du Programmierer. Es wäre schlimm, wenn Du das nicht könntest.

                    Bitte nochmal mit Essenz! Welchen substantiierten Rat gibst Du dem VP?

                    https://forum.selfhtml.org/self/2018/nov/12/leere-checkbox-erkennen/1736236#m1736236

                    -- https://beat-stoecklin.ch/pub/index.html
                    1. Das Problem liegt ganz woanders. Nämlich daran, daß heutige Programmierer mit Kontrollstrukturen nicht richtig umgehen können!

                      Folgende Nachrichten verweisen auf diesen Beitrag:

                      1. @@pl

                        Kontrollstrukturen

                        Hat jemand meine Bingo-Karte gesehen?

                        LLAP 🖖

                        -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
          2. Hello,

            Der Begriff Default ist hier vielen gar nicht klar!

            Dann erkläre ihn doch bitte für die Nachwelt :-)

            Glück Auf
            Tom vom Berg

            -- Es gibt nichts Gutes, außer man tut es!
            Das Leben selbst ist der Sinn.
        2. Hello,

          Inputfelder kennen keinen Default,

          <input type=radio selected value="you are wrong">

          Das ist eine durchaus relevante Anregung!
          Betrachten wir den Workflow vom ersten Formularaufruf mit

          [ ] Ich möchte

          und der Auskunft aus der Datenbank, die bereits eine Wahl abgespeichert hatte, dann müsste hier ein Übergang von Checkbox auf Radio stattfinden.

          (x) ich möchte - lieber nicht ( )

          Dies stellt selbstverständlich die Existenz der Checkbox generell in Frage. Die könnte man also wegoperieren -> DEPRICATED.

          Allerdings sollte man auch nie den dritten Zustand (NULL) aus dem Augenmerk verlieren. Wie sieht es da bei Checkbox und Radio aus (bitte den gesamten Roundturn betrachten)? Und bitte auch das Groupworking unter dem Aspekt der DSGVO (= Behinderung des horizontalen Meinungsaustausches) nicht vergessen.

          Szenario: Wie würden Sie entscheiden?

          ja ( )
          nein ( )
          keine Meinung ( )

          Nun interessiert mich Eure Meinung ;-)

          Glück Auf
          Tom vom Berg

          -- Es gibt nichts Gutes, außer man tut es!
          Das Leben selbst ist der Sinn.
          1. HTML ist nicht unsinnig. Es kommt jedoch darauf an, das was man zur Verfügung hat, zweckmäßig zu nutzen. Und für diesen Fall hier finde ich auch, das mit 2 Radiobuttongs am zweckmäßgsten zu lösen.

            .

          2. HTML ist an vielen Stellen noch unsinnig!

            Tja ... Trunken von dem checkbox-Problem bin ich drauf hereingefallen. In einem Formular kann man sein Passwort ändern, aber nur dann, wenn das auch übermittelt wird. Hier eine Zeile, mit der mySQL zusammengesetzt wird:

            if (isset($_POST['passwort_1']) $q .= ",passwort ='".$row_db['passwort_1']."'\n";

            und schon ist das Passwort gelöscht, das Mitglied ausgesperrt. Richtig ist sowas:

            if (isset($_POST['passwort_1']) && strlen($row_db['passwort_1']) > 7) $q .= ",passwort ='".$row_db['passwort_1']."'\n";
            1. Ganz schlecht. Weil: Du vermischst die Logik mit Nutzdaten! Besser ist es, die Logik über sog. Schlüsselparameter abzubilden und diese von den Nutzdaten zu trennen. Schlüsselparameter sind Parameter die einmal von den Nutzdaten getrennt sind und zum Anderen dazu dienen, die ganze Geschäftslogik über HTTP zu schleifen.

              So wäre z.B. passform=1 ein Schlüselparameter, womit dem Server klargemacht wird, daß er als nächstes 2 Felder bereitstellen soll: 1 Feld für das neue Passwort und 1 Feld zum Vergleich um Tippfehler auszuschließen. Zu übertragen hast Du mindestens 3 Parameter beim Absenden des Formulars:

              password passwordconfirm chpass

              Wobei Letzerer der Schlüsselüparameter wäre. Damit ist serverseitig klar was zu tun ist. MfG

              1. Ganz schlecht. Weil: Du vermischst die Logik mit Nutzdaten!

                Tja, ich setze Platzhalter-Dateien (templates) ein. Für ein PHP-Programm kann es mehrere Platzhalter-Dateien geben.

                Im Fall von <form> muss ich einen Weg finden, die Logik des Formulars an PHP zu melden.

                Beispiel 1 im Adress-Formular, der Name des Häuptlings darf veröffentlicht werden, Häuptling kann diese Entscheidung aber rückgängig machen:

                <input type=hidden name="name_frei_x" value=1 /> <br><label for="name_frei_label"> <input id = "name_frei_label" type = "checkbox" name = "name_frei" value = '1' checked > Ansprechpartner bei den Veranstaltungen zeigen</label>

                PHP muss also name_frei_x abfragen, um zu wissen, ob in diesem Formular der Häuptlingsname gesperrt oder freigegeben werden kann.

                Selbes Programm, anderes Formular kann sich mit der Adresse des Vereins beschäftigen. Der Name des Ansprechpartners und die checkbox JA/NEIN kommt gar nicht vor.

                PHP fragt wieder name_frei_x ab, das fehlt und damit ist auch keine JA/NEIN Entscheidung zu treffen.

                1. Ganz schlecht. Weil: Du vermischst die Logik mit Nutzdaten!

                  Tja, ich setze Platzhalter-Dateien (templates) ein.

                  Eine Trennung der Schlüsselparameter von Nutzdaten hat doch mit Platzhaltern in Templates nichts zu tun.

                  MfG

                2. Lieber Linuchs,

                  Selbes Programm, anderes Formular kann sich mit der Adresse des Vereins beschäftigen. Der Name des Ansprechpartners und die checkbox JA/NEIN kommt gar nicht vor.

                  warum sollte ein "anderes Formular" von derselben Logik ausgewertet werden, wie das zuerst von Dir vorgestellte?

                  Du kannst die Problematik mit der Anzeigeerlaubnis in der Verarbeitung der Userdaten dahingehend mit abarbeiten, indem Du auf die andere URL des anderen Formulars eingehst.

                  Liebe Grüße,

                  Felix Riesterer.

                3. Im Fall von <form> muss ich einen Weg finden, die Logik des Formulars an PHP zu melden.

                  Nein. Ein Formular hat keine Logik. Was Du machen möchtest ist, Deine Logik auf HTTP Parameter abzubilden. Und dafür Schlüsselparameter (manche sagen auch Aktionparameter) definierst, womit der serverseitige Prozess weiß was er mit den Daten machen und welche er dafür prüfen soll.

                  Und wenn Daten unvollständig sind, kriegt der Benutzer eine entsprechende Fehlermeldung.

                  MfG

          3. hallo

            Dies stellt selbstverständlich die Existenz der Checkbox generell in Frage. Die könnte man also wegoperieren -> DEPRICATED.

            Soweit würde ich nicht gehen. Eine Checkbox ist dort sinnvoll, wo das Fehlen der Information betrieblich problemlos ist.

            Ich muss allerdings sagen, dass es eine Weile her ist, dass ich selbst für Javascript das letzte mal eine Checkbox eingesetzt habe.

            -- https://beat-stoecklin.ch/pub/index.html
          4. Dies stellt selbstverständlich die Existenz der Checkbox generell in Frage. Die könnte man also wegoperieren -> DEPRICATED.

            Wieso? Man kann doch mit einer "Generalmethode" reagieren, wenn eine Checkbox (Radio-Button oder was auch immer) zu fehlen scheint:

            function getCheckBoxValues ( $method, $arCheckBoxNames ) { if ( ( 'string' ) == $arCheckBoxNames ) { $arCheckBoxNames = [ $arCheckBoxNames ]; } $method = strtoupper( $method ); if ( 'POST' == $method ) { $helper = $_POST; } elseif ( 'GET' == $method ) { $helper = $_GET; } else { trigger_error( 'Falscher Wert für $method: ' . $method , E_USER_ERROR ); ### exit; } $arReturns = []; foreach ( $arCheckBoxNames as $CheckBoxName ) { if ( isset( $helper[$CheckBoxName] ) ) { $arReturns[$CheckBoxName] = $helper[$CheckBoxName]; } else { $arReturns[$CheckBoxName] = false; } } return $arReturns; } ### Test ####################################### $_POST['foo'] = 'on'; $_POST['bar'] = 0; $_POST['tok'] = 1; $_POST['qux'] = NULL; $_POST['quux'] = false; $_GET = $_POST; echo "################### POST ###################################\n": var_dump( getCheckBoxValues( 'post', ['foo', 'bar', 'tok', 'baz', 'qux', 'quux'] ) ); echo "################### GET ###################################\n": var_dump( getCheckBoxValues( 'Get', ['foo', 'bar', 'tok', 'baz', 'qux', 'quux'] ) );

            Welche Checkboxen erwartet werden kann man z.B. in die Session schreiben bevor man das Formular Richtung Useragent absendet. Die Werte NULL oder FALSE sollte man nicht als Value der Checkboxen verwenden. Das ist aber auch ziemlich schwierig.

            Folgende Nachrichten verweisen auf diesen Beitrag:

          5. ja ( )
            nein ( )
            keine Meinung ( )

            Muss bei Radio-Inputs (je nach Sachzusammenhang) ohnehin angeboten werden. Ist nämlich erst mal eine der Möglichkeiten ausgewählt, dann gibt es kein Zurück. Ohne die Variante "keine Meinung" zwingst Du den Benutzer, der keine Meinung hat, sich nach einem "Verklicken" notgedrungen zu entscheiden - was die Aussagekraft der gesammelten Daten beschädigt.

            1. Hello,

              ja ( )
              nein ( )
              keine Meinung ( )

              Muss bei Radio-Inputs (je nach Sachzusammenhang) ohnehin angeboten werden. Ist nämlich erst mal eine der Möglichkeiten ausgewählt, dann gibt es kein Zurück. Ohne die Variante "keine Meinung" zwingst Du den Benutzer, der keine Meinung hat, sich nach einem "Verklicken" notgedrungen zu entscheiden - was die Aussagekraft der gesammelten Daten beschädigt.

              Sagte ich doch hiermit, oder konnte man das missverstehen?

              Glück Auf
              Tom vom Berg

              -- Es gibt nichts Gutes, außer man tut es!
              Das Leben selbst ist der Sinn.
              1. Lieber TS,

                ja ( )
                nein ( )
                keine Meinung ( )

                hat Dir @Linuchs in irgend einer Weise nahegelegt, dass Du seine Problematik (Ja/nein-Frage) mit "keine Meinung" ergänzen solltest?

                Liebe Grüße,

                Felix Riesterer.

  3. Tach!

    Behelfe mich in den Formularen, die Checkboxen enthalten, mit einem input type hidden. Wenn das gesetzt ist und die Checkbox-Info fehlt, dann bedeutet das NEIN.

    Geht das auch einfacher? Könnte man die Checkbox zwingen, auch ein NEIN zu übermitteln?

    Nein, kann man nicht zwingen, das Verhalten ist im Standard so vorgesehen.

    Eine etwas einfachere Lösung geht mit eine Hidden-Input, aber nicht ein "eigenständiges" mit eigenem Namen sondern mit demselben wie die Checkbox. Es wird dann das Name-Value-Paar vom Hidden-Input gesendet und dazu entweder nichts oder der Wert von der angekreuzten Checkbox. Bei PHP ist es so, dass bei gleichem Namen der Wert im $_GET/$_POST-Array überschrieben wird. Somit hast du exakt einen Wert, entweder den Default-Wert vom Hidden-Input oder den vo der angehakten Checkbox. Die Auswertung beschränkt sich damit auf einen statt zwei Einträge.

    <input type="hidden" name="foo" value="false"> <input type="checkbox" name="foo" value="true">

    dedlfix.

    1. Übertragen wird das hier: foo=false&foo=true aber als best practice würde ich das nicht bezeichnen, es so zu machen.

      Weil Du damit vom Parser abhängig bist!

      1. Tach!

        Übertragen wird das hier: foo=false&foo=true aber als best practice würde ich das nicht bezeichnen, es so zu machen.

        Weil Du damit vom Parser abhängig bist!

        Es muss nur auf die Gegebenheiten bei Linuchs passen, weil er eine Individualsoftware erstellt und keine Massenware. Es ist auch nicht davon auszugehen, dass PHP in Zukunft das Parseverhalten ändert, das würde eine Menge Anwendungen kaputtmachen.

        dedlfix.

  4. Lieber Linuchs,

    für eine JA / NEIN Aussage ist input type checkbox geeignet.

    richtig. Aber der besseren UX wegen ist ein Paar von zwei Radio-Buttons geeigneter, von denen einer mit einer Vorselektierung versehen ist.

    <p> Einverstanden? <label> <input name="agree" value="yes"> Ja </label> <label> <input name="agree" value="no" selected> Nein </label> </p>

    Liebe Grüße,

    Felix Riesterer.

    Folgende Nachrichten verweisen auf diesen Beitrag:

    1. Hello,

      für eine JA / NEIN Aussage ist input type checkbox geeignet.

      richtig. Aber der besseren UX wegen ist ein Paar von zwei Radio-Buttons geeigneter, von denen einer mit einer Vorselektierung versehen ist.

      <p> Einverstanden? <label> <input name="agree" value="yes"> Ja </label> <label> <input name="agree" value="no" selected> Nein </label> </p>

      Dies bildet aber immer noch nicht die gesamte Datenhistorie ab, sondern versucht, (illegitim) zu konsolidieren. Es interpretiert einen NULL-Eintrag in der Datenbank um zu einem JA-NEIN-Eintrag. Die unterschiedlichen Zustände der unterschiedlichen Kontexte werden schlichtweg missachtet.

      Solange Datenbanksysteme drei logische Zustände leisten und Front-End-Forms nebst APIs diese auch erzeugen/beibehalten können, müssen wir diese auch berücksichtigen, insbesondere, da digitale Entscheidungen immer relevanter werden.

      Ich erinnere deshalb an eine der Kernfragen in der deutschen Geschichte:

      unlautere Fragetechnik

      Glück Auf
      Tom vom Berg

      -- Es gibt nichts Gutes, außer man tut es!
      Das Leben selbst ist der Sinn.
      1. Lieber TS,

        Dies bildet aber immer noch nicht die gesamte Datenhistorie ab, sondern versucht, (illegitim) zu konsolidieren.

        wovon sprichst Du hier? Mein Thema war eine Ja-/Nein-Antwort entgegen zu nehmen und dafür passende Formularfelder zu nutzen.

        Es interpretiert einen NULL-Eintrag in der Datenbank um zu einem JA-NEIN-Eintrag.

        Was Du in die value-Attribute hinein schreibst, bleibt Dir überlassen. Was Du in Deiner Datenbank tust, bleibt Dir überlassen. Ich habe mich hier auf das notwendige Markup spezialisiert, welches @Linuchs' Problem hinreichend lösen können sollte.

        Die unterschiedlichen Zustände der unterschiedlichen Kontexte werden schlichtweg missachtet.

        Richtig, sie waren nicht Gegenstand der Frage. Du hingegen entwirfst hier einfach Deine eigenen Gegebenheiten, um mir dann vorzuwerfen, dass ich mit meiner Antwort auf die Frage des OP (also nicht Deine!) nicht passend auf Deinen Anwendungsfall geantwortet hätte. Oder bist Du etwa @Linuchs?

        Solange Datenbanksysteme drei logische Zustände leisten und Front-End-Forms nebst APIs diese auch erzeugen/beibehalten können, müssen wir diese auch berücksichtigen, insbesondere, da digitale Entscheidungen immer relevanter werden.

        Ich habe keine Ahnung, wovon Du hier redest. Vielleicht verstehe ich einfach nicht, was Sache ist und empfinde Deinen Einwand deshalb als reichlich wirres Zeug.

        Ich erinnere deshalb an eine der Kernfragen in der deutschen Geschichte:

        WTF?

        Liebe Grüße,

        Felix Riesterer.

      2. Hallo

        Dies bildet aber immer noch nicht die gesamte Datenhistorie ab, sondern versucht, (illegitim) zu konsolidieren. Es interpretiert einen NULL-Eintrag in der Datenbank um zu einem JA-NEIN-Eintrag. Die unterschiedlichen Zustände der unterschiedlichen Kontexte werden schlichtweg missachtet.

        Solange Datenbanksysteme drei logische Zustände leisten und Front-End-Forms nebst APIs diese auch erzeugen/beibehalten können, müssen wir diese auch berücksichtigen

        Das hier diskutierte HTML-Formularelement Checkbox kann diesen Dreiklang der möglichen Werte (TRUE, FALSE, NULL) ganz offensichtlich nicht abbilden. Es gibt hier nur TRUE (übertragener Wert) oder NULL (nicht übertragener Wert), aber eben nicht FALSE (mit welchem Wert auch immer). Abgesehen von der Krücke <input type="hidden"> oder der Krücke der serverseitigen Vorgabe für einen nicht übertragenen Wert bleibt wohl nur zu konstatieren, dass eine Checkbox hier das falsche Formularelement ist.

        Ich erinnere deshalb an eine der Kernfragen in der deutschen Geschichte:

        unlautere Fragetechnik

        Hier werden aber nur TRUE und FALSE zur Auswahl gestellt. Kein gutes Beispiel.

        Tschö, Auge

        -- Eine Kerze stand [auf dem Abort] bereit, und der Almanach des vergangenen Jahres hing an einer Schnur. Die Herausgeber kannten ihre Leser und druckten den Almanach auf weiches, dünnes Papier.
        Kleine freie Männer von Terry Pratchett
        1. Liebes Auge,

          Hier werden aber nur TRUE und FALSE zur Auswahl gestellt.

          naja, man kann den Zettel auch ungültig machen, indem man ihn nicht ausfüllt, oder beide Felder ankreuzt.

          Kein gutes Beispiel.

          Das sehe ich allerdings auch so. Ich mag diese geschichtlichen Vermischungen mit technischen Details hier überhaupt nicht gerne. Nicht dass ich etwas dagegen hätte, mich mit der Geschichte meines Landes und meiner Vorväter auseinander zu setzen, aber nicht in diesem technischen Rahmen.

          Liebe Grüße,

          Felix Riesterer.

    2. @@Felix Riesterer

      für eine JA / NEIN Aussage ist input type checkbox geeignet.

      richtig. Aber der besseren UX wegen ist ein Paar von zwei Radio-Buttons geeigneter, von denen einer mit einer Vorselektierung versehen ist.

      Eine Checkbox kann man sicher in manchen Fällen durch ein Paar von Radio-Buttons ersetzen. Aber ein Paar von Radio-Buttons generell als geeigneter als eine Checkbox darzustellen, halte ich für sehr gewagt.

      Davon abgesehen, kam mir in diesem Fall auch ein Paar von Radio-Buttons in den Sinn.

      LLAP 🖖

      -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
      1. Lieber Gunnar,

        Eine Checkbox kann man sicher in manchen Fällen durch ein Paar von Radio-Buttons ersetzen. Aber ein Paar von Radio-Buttons generell als geeigneter als eine Checkbox darzustellen, halte ich für sehr gewagt.

        ich habe nur mit @Linuchs' Beschränkungen hantiert. In meinen Projekten darf das Nichtvorhandensein tatsächlich als "nein" gewertet werden, da ich von Checkbox-Werten grundsätzlich davon ausgehe, dass ihr Fehlen zwangsläufig ein "off" bedeutet. Aber es darf ja jeder seine Applikationen bauen, wie er/sie/* es gerne möchte.

        Davon abgesehen, kam mir in diesem Fall auch ein Paar von Radio-Buttons in den Sinn.

        Wenn es exklusiv ein JA oder Nein geben muss, halte ich diese Lösung für die intuitivste.

        Liebe Grüße,

        Felix Riesterer.

        1. @@Felix Riesterer

          ich habe nur mit @Linuchs' Beschränkungen hantiert.

          Du sagtest „Aber der besseren UX wegen ist ein Paar von zwei Radio-Buttons geeigneter.“ Das habe ich als allgemeines Statement aufgefasst und als solches infragegestellt.

          LLAP 🖖

          -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
          1. Lieber Gunnar,

            Das habe ich als allgemeines Statement aufgefasst und als solches infragegestellt.

            OK, verstehe. In welchen Fällen betrachtest Du es in seiner generalisierenden Form als falsch?

            Liebe Grüße,

            Felix Riesterer.

            1. @@Felix Riesterer

              In welchen Fällen betrachtest Du es in seiner generalisierenden Form als falsch?

              Beispiel 1: Mehrfachauswahl

              ☐ montags
              ☐ dienstags
              ☐ mittwochs
              ☐ donnerstags
              ☑︎ freitags
              ☑︎ sonnabends
              ☐ sonntags

              Wie soll das mit Radiobuttons aussehen? So?

              \begin{array}{lll} \text{montags} \quad & ⦿ \, \text{nie} \; & ○ \, \text{immer} \\ \text{dienstags} \quad & ⦿ \, \text{nie} \; & ○ \, \text{immer} \\ \text{mittwochs} \quad & ⦿ \, \text{nie} \; & ○ \, \text{immer} \\ \text{donnerstags} \quad & ⦿ \, \text{nie} \; & ○ \, \text{immer} \\ \text{freitags} \quad & ○ \, \text{nie} \; & ⦿ \, \text{immer} \\ \text{sonnabends} \quad & ○ \, \text{nie} \; & ⦿ \, \text{immer} \\ \text{sonntags} \quad & ⦿ \, \text{nie} \; & ○ \, \text{immer} \\ \end{array}

              Für eine Auswahl von 0 bis n gleichartigen Dingen sind Checkboxen wohl prädestiniert.

              Beispiel 2: AGB bestätigen

              ☐ Ich bestätige, die AGB gelesen zu haben und erkenne diese an.

              Wie soll das mit Radiobuttons aussehen?

              Haben Sie die AGB gelesen und erkennen Sie diese an?
              ⦿ ja   ◯ nein

              Oder so?

              ⦿ Ich bestätige, die AGB gelesen zu haben und erkenne diese an.
              ◯ Ich erkenne die AGB nicht an.

              Man will dem Nutzer hier sicher nicht vorgaukeln, sie hätte mehrere Optionen.

              LLAP 🖖

              -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
              1. @Gunnar Bittersmann

                der HTTP Standard kommt ja diesen Dingen vollumfänglich entgegen! Indem z.B. eine Mehrfachauswahl auf gleichnamige Parameter abgebildet und aus diesem serverseitig ein Array wird.

                Gleichermaßen lässt sich serverseitig auch recht einfach feststellen, ob ein bestimmter Parameter überhaupt gesendet wurde, z.B. agree=1 als Zustimmung die AGB gelesen zu haben.

                Parameter bei denen nur geprüft wird ob sie überhaupt im Request sind, werden Schlüsselparameter genannt. Sie sind essentiell zur Ablaufkontrolle für den gesamten Prozess!

                .

                1. Tach!

                  der HTTP Standard kommt ja diesen Dingen vollumfänglich entgegen! Indem z.B. eine Mehrfachauswahl auf gleichnamige Parameter abgebildet und aus diesem serverseitig ein Array wird.

                  Was serverseitig in den Programmiersprachen und deren Librarys passiert, ist nicht im HTTP-Standard festgelegt. Und nicht alle machen ein Array aus gleichnamigen Parametern. Die beiden Teilsätze mit "und" zu verknüpfen erweckt einen falschen Eindruck von einem kausalen Zusammenhang zwischen Standard und Programmierumgebungen.

                  Gleichermaßen lässt sich serverseitig auch recht einfach feststellen, ob ein bestimmter Parameter überhaupt gesendet wurde, z.B. agree=1 als Zustimmung die AGB gelesen zu haben.

                  Parameter bei denen nur geprüft wird ob sie überhaupt im Request sind, werden Schlüsselparameter genannt. Sie sind essentiell zur Ablaufkontrolle für den gesamten Prozess!

                  Mir scheint, das ist eine Bezeichnung von dir, und diese Steuerfunktion ist vielleicht für dein privates Framework von Interesse. Anderenorts habe ich diese Bezeichnung noch nicht für Parameter mit einer solchen Funktion gesehen.

                  dedlfix.

                  1. @dedlfix

                    der HTTP Standard kommt ja diesen Dingen vollumfänglich entgegen! Indem z.B. eine Mehrfachauswahl auf gleichnamige Parameter abgebildet und aus diesem serverseitig ein Array wird.

                    Was serverseitig in den Programmiersprachen und deren Librarys passiert, ist nicht im HTTP-Standard festgelegt. Und nicht alle machen ein Array aus gleichnamigen Parametern.

                    PHP macht das aber auch: Wenn Parameternamen einer bestimmten Schreibweise genügen!

                    Und ja, der richtige Umgang mit Schlüsselparametern gehört zum Handwerk!

                    .

                    PS: Man kann es erlernen.

                    Folgende Nachrichten verweisen auf diesen Beitrag:

                2. @@pl

                  Schlüsselparameter … Ablaufkontrolle

                  Hab ich ein Glück, dass ich meinen Bingo-Zettel wiedergefunden habe!

                  LLAP 🖖

                  -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                  1. @Gunnar Bittersmann

                    Schlüsselparameter … Ablaufkontrolle

                    Hab ich ein Glück, dass ich meinen Bingo-Zettel wiedergefunden habe!

                    Dann guck mal ob progressive Enhancement draufsteht!

                3. hallo

                  @Gunnar Bittersmann

                  der HTTP Standard kommt ja diesen Dingen vollumfänglich entgegen! Indem z.B. eine Mehrfachauswahl auf gleichnamige Parameter abgebildet und aus diesem serverseitig ein Array wird.

                  nicht bei php

                  -- https://beat-stoecklin.ch/pub/index.html
                  1. Hello,

                    @Gunnar Bittersmann

                    der HTTP Standard kommt ja diesen Dingen vollumfänglich entgegen! Indem z.B. eine Mehrfachauswahl auf gleichnamige Parameter abgebildet und aus diesem serverseitig ein Array wird.

                    nicht bei php

                    Da hat sich Hotti vermutlich nicht ausfühlich genug wiederholt:

                    • gleichnamige Parameter werden in PHP überschrieben, letzte Zuweisung gilt
                    • es sei denn, eine bestimmte Namenskonvention wird eingehalten (Abschluss des Parameters mit []

                    Das erwähnte er in einem anderen Posting schon und hat es versäumt, das hier zu wiederholen :-|

                    Glück Auf
                    Tom vom Berg

                    -- Es gibt nichts Gutes, außer man tut es!
                    Das Leben selbst ist der Sinn.
                    1. hallo

                      Hello,

                      @Gunnar Bittersmann

                      der HTTP Standard kommt ja diesen Dingen vollumfänglich entgegen! Indem z.B. eine Mehrfachauswahl auf gleichnamige Parameter abgebildet und aus diesem serverseitig ein Array wird.

                      nicht bei php

                      Da hat sich Hotti vermutlich nicht ausfühlich genug wiederholt:

                      • gleichnamige Parameter werden in PHP überschrieben, letzte Zuweisung gilt
                      • es sei denn, eine bestimmte Namenskonvention wird eingehalten (Abschluss des Parameters mit []

                      Es sei denn, ein bestimmter Hack wird angewendet. Sagt ja alles.

                      Seien wir aber ehrlich, um strukturierte Daten zu übertragen, baue man besser auf JSON, statt auf irgendwelche Verarbeitungsreihenfolgen der serverseitigen Software zu vertrauen.

                      -- https://beat-stoecklin.ch/pub/index.html
                      1. Hello Rolf,

                        Es sei denn, ein bestimmter Hack wird angewendet. Sagt ja alles.

                        Das ist eben ein Feature von PHP, das zwei Möglichkeiten anstelle von einer eröffnet.

                        Seien wir aber ehrlich, um strukturierte Daten zu übertragen, baue man besser auf JSON, statt auf irgendwelche Verarbeitungsreihenfolgen der serverseitigen Software zu vertrauen.

                        Soweit ich weiß müssen HTTP-Header immer in derselben Reihenfolge weitergeleitet werden. Es ist also "as designed", wenn die letzte Zuweisung gilt. Die PHP-Array-Regel immer im Hinterhirn...

                        Und auch mit PHP kann man alle übersandten Parameterwerte eines einfachen Parameters abfragen, wenn man das unbedingt will (Raw-Mode). Man braucht sie aber im Normalfall nicht! Hier stimmt also das Paradigma, dass eine höhere Programmiersprache tiefere Schichten zwar überdecken (weil es praktisch ist), aber nicht zerstören darf.

                        Glück Auf
                        Tom vom Berg

                        -- Es gibt nichts Gutes, außer man tut es!
                        Das Leben selbst ist der Sinn.
                        1. PHP macht das was man eigentlich nicht machen sollte: Es verschleppt den Transport-Layer in die Anwendungsschicht! Dadurch nämlich daß $_POST, $_GET zwei verschiedene Arrays sind, ist der Anwendungscode vom Transportlayer abhängig und somit ist dieser Layer nicht mehr transparent.

                          @TS Du weißt doch selbst, wozu Schichtenmodelle gut sind.

                          1. Tach!

                            PHP macht das was man eigentlich nicht machen sollte: Es verschleppt den Transport-Layer in die Anwendungsschicht! Dadurch nämlich daß $_POST, $_GET zwei verschiedene Arrays sind, ist der Anwendungscode vom Transportlayer abhängig und somit ist dieser Layer nicht mehr transparent.

                            Wenn es dir egal ist, über welchen Weg etwas reinkommt, dann nimm $_REQUEST. Es ist aber nicht immer sinnvoll, alle Kanäle zuzulassen und zu bündeln, weil das unter anderem sicherheitstechnische Auswirkungen haben kann. Beispielsweise nimmt man an, man bekommt Daten per POST, ein Hijacker schafft es aber die URL zu manipulieren und sendet sein Zeugs im Querystring. Wenn die Anwendung nun auf $_REQUEST zugreift, hat sie sich ein Problem eingehandelt. Beim expliziten Zugriff auf $_POST ignoriert sie den Versuch, über $_GET etwas einzuschleusen.

                            PHP kann nicht entscheiden, ob der Anwendung die Quelle egal ist oder auf diese Quelle Wert legt. Das kann nur die Anwendung selbst wissen und muss deshalb Zugriff auf die Transportinformation haben.

                            dedlfix.

                            1. Du ich sprach von transparenten Layern und nicht von Security!

                              1. Hello pl,

                                Du ich sprach von transparenten Layern und nicht von Security!

                                Genau deshalb muss ja auch eine Nachricht, die im Layer 7 (HTTP) abgesandt wurde, beim Empfänger wieder adäquat bis Layer 7 (HTTP) ausgepackt und bewertet werden.

                                Die Layer darunter müssen die gekapselte Nachricht unverändert durchreichen und dürfen sie nicht verfremden. Das nennt man dann Transparenz, denn für die Anwendung (HTTP) auf Layer 7 sind diese unsichtbar.

                                Das PHP hier trotzdem zusätzlich auf Informationen aus tieferen Layern zugrweifen kann, ist legitim.

                                @Matthias Apsel: Ich hätte gerne das Tag "OSI-Modell"

                                Glück Auf
                                Tom vom Berg

                                -- Es gibt nichts Gutes, außer man tut es!
                                Das Leben selbst ist der Sinn.
                              2. Tach!

                                Du ich sprach von transparenten Layern und nicht von Security!

                                Ja, das hatte ich gemerkt, dass du wesentliche Aspekte einer Anwendung unterschlagen hast. Es hilft dir nichts, wenn dir jemand transparent Daten unterjubelt, die du nicht haben möchtest.

                                dedlfix.

                          2. Hello pl,

                            PHP macht das was man eigentlich nicht machen sollte: Es verschleppt den Transport-Layer in die Anwendungsschicht! Dadurch nämlich daß $_POST, $_GET zwei verschiedene Arrays sind, ist der Anwendungscode vom Transportlayer abhängig und somit ist dieser Layer nicht mehr transparent.

                            Da irrst Du vermutlich. Ich denke, dass die RAW-Daten noch zur Verfügung stehen, sollte man sie brauchen. Die Bewertung der Daten wird aber in der Darstellungsschicht (6) vorgenommen.

                            @TS Du weißt doch selbst, wozu Schichtenmodelle gut sind.

                            Und wie wir beide wissen, sind die Schichten 5, 6 und 7 im DoD-Modell ohnehin zusammengefasst.

                            Und noch eins: HTTP findet nicht im Transport-Layer statt, sondern "irgendwo" darüber, eher in Layer 7 als in Layer 4 :-P

                            Glück Auf
                            Tom vom Berg

                            -- Es gibt nichts Gutes, außer man tut es!
                            Das Leben selbst ist der Sinn.
                            1. Hallo Tom,

                              es gibt den Begriff Transportschicht nicht nur im OSI-Modell. Auch Anwendungen haben Schichten, und auch da gibt's Transport (als Infrastrukturkomponente, die einen HTTP Request in Variablen oder Objekte übersetzt).

                              Dass man sich im Business-Teil einer Anwendung nicht darum kümmern MÜSSEN sollte, ob die Daten in $_POST oder $_GET stehen, ist durchaus ein valider Einwand. Seine Berechtigung sieht man sehr schön in diesem Beispiel vom Erklärbären, wo aufwändig zwischen GET und POST unterschieden wird um dann mittels $helper auf $_GET oder $_POST zuzugreifen, statt $_REQUEST zu verwenden.

                              Rolf

                              -- sumpsi - posui - clusi
                              1. hallo

                                Hallo Tom,

                                es gibt den Begriff Transportschicht nicht nur im OSI-Modell. Auch Anwendungen haben Schichten, und auch da gibt's Transport (als Infrastrukturkomponente, die einen HTTP Request in Variablen oder Objekte übersetzt).

                                In Perl hast du die Freiheit, in welcher Phase (das wäre der relevante Begriff) du ein Modul einbindest, das sich mit Datenentgegennahme befasst.

                                Das hat nichts mit Schichten zu tun.

                                Und optimaler Weise muss man ein Modul nicht mal benutzen, sondrn kann es immer noch umgehen.

                                Demgegenüber ist doch eine Schicht etwas, das sich nicht ersetzen lässt, oder?

                                -- https://beat-stoecklin.ch/pub/index.html
                                1. Hello,

                                  In Perl hast du die Freiheit, in welcher Phase (das wäre der relevante Begriff) du ein Modul einbindest, das sich mit Datenentgegennahme befasst.

                                  Das hat nichts mit Schichten zu tun.

                                  Schon, aber nicht mit OSI-Schichten :-P

                                  Und optimaler Weise muss man ein Modul nicht mal benutzen, sondrn kann es immer noch umgehen.

                                  Demgegenüber ist doch eine Schicht etwas, das sich nicht ersetzen lässt, oder?

                                  Im OSI-Modell zumindest nicht mehr, wenn die Schicht bereits durchlaufen wurde.

                                  Glück Auf
                                  Tom vom Berg

                                  -- Es gibt nichts Gutes, außer man tut es!
                                  Das Leben selbst ist der Sinn.
                              2. @@Rolf B

                                Auch Anwendungen haben Schichten

                                Auch Ogers have layers.

                                LLAP 🖖

                                -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                            2. hi,

                              PHP macht das was man eigentlich nicht machen sollte: Es verschleppt den Transport-Layer in die Anwendungsschicht! Dadurch nämlich daß $_POST, $_GET zwei verschiedene Arrays sind, ist der Anwendungscode vom Transportlayer abhängig und somit ist dieser Layer nicht mehr transparent.

                              Da irrst Du vermutlich.

                              POST und GET gehören zum Transport Layer. Und Transparenz heißt, der Layer wird durchsichtig. Das heißt, daß der ganze Layer respektive die Requestmethode in der Anwendung überhaupt keine Rolle mehr zu spielen haben.

                              Das Perlmodul CGI.pm, so fehlerhaft es auch sein mag, es unterstützt dieses Schichtenmodell. Und macht natürlich auch den Transport Layer transparent.

                              Im Übrigen wurde der ganze CGI/1.1 Standard dafür entwickelt, HTTP für nachgelagerte Prozesse transparent zu machen!

                              .

                              1. hallo

                                POST und GET gehören zum Transport Layer. Und Transparenz heißt, der Layer wird durchsichtig. Das heißt, daß der ganze Layer respektive die Requestmethode in der Anwendung überhaupt keine Rolle mehr zu spielen haben.

                                Das Gute an https ist doch, dass ich weiss, wo POST und GET nicht hingehören.

                                -- https://beat-stoecklin.ch/pub/index.html
                              2. POST und GET gehören zum Transport Layer.

                                Nein. Die Daten werden via HTTP übertragen. POST und GET gehören zum HTTP-Protokoll.

                                Das Hypertext Transfer Protocol (HTTP, englisch für Hypertext-Übertragungsprotokoll) ist ein zustandsloses Protokoll zur Übertragung von Daten auf der Anwendungsschicht über ein Rechnernetz.

                                Wikipedia::Hypertext Transfer Protocol

                                Auch der Artikel zum OSI-Schichtenmodell verortet HTTP in den Schichten 5 bis 7, also ganz klar oberhalb der Transportschicht (Transport Layer). Die hat die Nummer 4.

                                1. Im Übrigen ist die Requestmethode nur ein String der beliebig gewählt werden kann. Selbst die moderne FetchAPI läßt das zu. Ebenso wird Standard CGI/1.1 diesem Sachverhalt gerecht:

                                  Sofern ein Request-Header Content-Length > 0 gesendet wurde, legt der Webserver den im Message Body ankommenden Datenstrom um nach STDOUT. Ein nachgelagerter Prozeß liest somit den Message Body aus STDIN. Für ebendiesen Prozeß setzt der Webserve o.g. Header in die Umgebungsvariable CONTENT_LENGTH.

                                  Wir sehen also, die Requestmethode spielt überhaupt keine Rolle bei der Frage woher die Daten kommen. Darin begründet sich auch der Begriff Transparenz.

                                  .

                                  1. Hello,

                                    Im Übrigen ist die Requestmethode nur ein String der beliebig gewählt werden kann. Selbst die moderne FetchAPI läßt das zu. Ebenso wird Standard CGI/1.1 diesem Sachverhalt gerecht:

                                    Sofern ein Request-Header Content-Length > 0 gesendet wurde, legt der Webserver den im Message Body ankommenden Datenstrom um nach STDOUT. Ein nachgelagerter Prozeß liest somit den Message Body aus STDIN. Für ebendiesen Prozeß setzt der Webserve o.g. Header in die Umgebungsvariable CONTENT_LENGTH.

                                    Wir sehen also, die Requestmethode spielt überhaupt keine Rolle bei der Frage woher die Daten kommen. Darin begründet sich auch der Begriff Transparenz.

                                    Was hat das mit Transparenz zu tun?

                                    Die Requestmethode gehört hier ins HTTP-Protokoll und durch die Kennzeichnung der Methode wird dem Empfänger angezeigt, welche Datenstrukturen wo zu erwarten (und auszuwerten) sind. Ein GET-Request hat demnach keinen Request-Body, ein POST-Request schon.

                                    Glück Auf
                                    Tom vom Berg

                                    -- Es gibt nichts Gutes, außer man tut es!
                                    Das Leben selbst ist der Sinn.
                      2. hi,

                        Seien wir aber ehrlich, um strukturierte Daten zu übertragen, baue man besser auf JSON,

                        Nein. Vielmehr senden wir einen zur Struktur passenden Content-Type-Header damit der serverseitige Prozess weiß wie der die strukturierten Daten wiederherzustellen hat!

                        Und so schlecht ist Enctype application/x-www-form-urlencoded nun auch wieder nicht. Worauf es ankommt sind einheitliche Prozesse und einheitliche Datenstrukturen, dafür gibt es Standards. Und JSON Datenstrukturen sind alles andere als einheitlich!

                        MfG

                        1. hallo

                          hi,

                          Seien wir aber ehrlich, um strukturierte Daten zu übertragen, baue man besser auf JSON,

                          Nein. Vielmehr senden wir einen zur Struktur passenden Content-Type-Header damit der serverseitige Prozess weiß wie der die strukturierten Daten wiederherzustellen hat!

                          Ach was weiss der Content-Type von einer Datenreihenfolge,

                          Das Problem ist doch folgendes: Frontenddesigner überarbeitet ein Template. Backend-Designer macht blödsinnige Annahmen betreffs Reihenfolgen der Daten.

                          Das schreit dann nach esoterischen Bugs.

                          -- https://beat-stoecklin.ch/pub/index.html
                          1. Ach was weiss der Content-Type von einer Datenreihenfolge,

                            Der Content-Type beschreibt ja nicht die Reihenfolge sondern die Struktur!

                            Das Problem ist doch folgendes: Frontenddesigner überarbeitet ein Template. Backend-Designer macht blödsinnige Annahmen betreffs Reihenfolgen der Daten.

                            Natürlich spielt auch die Reihenfolge der <input>-Felder eine Rolle. Aber der Enctype darf sie nicht verändern und das ist ganz Wesentlich! Enctype application/x-www-form-urlencoded und multipart/form-data verändern die Reihenfolge nicht.

                            Das schreit dann nach esoterischen Bugs.

                            Wenn man sich nicht auf einen bestimmten Enctype einigen kann ist klar daß Müll dabei rauskommt.

                            .

                            1. Natürlich spielt auch die Reihenfolge der <input>-Felder eine Rolle.

                              Auf diese Reihenfolge kann man sich aber nie verlassen. Weil der Frontender …

                              Aber der Enctype darf sie nicht verändern und das ist ganz Wesentlich! Enctype application/x-www-form-urlencoded und multipart/form-data verändern die Reihenfolge nicht.

                              Der "Frontender" aber schon. Der soll ja ein Design umsetzen - und da gilt "form follows function" nicht in Bezug auf die Programmierung des Backends. Also sendet man nicht "on" sondern vereinbart dass die Checkboxen (um die es hier geht) jeweils einen markanten und sprechenden Value haben und denkt (als "Backender") daran, eben diese Werte vor einer Auswertung, einem Vergleich oder einer Suche (z.B. in_array()) a) zu trimmen und b) mit etwas wie strtolower() zu behandeln um wenigstens solchen Schreibfehlern zu begegnen.

                              Ich bin auch bei meinem eigenen Zeug kein Freund von solchen Reihenfolgen. Beispiel aus dem PHP-Manual:

                              ### Zuordnung nach Reihenfolge: $sth = $dbh->prepare('SELECT name, colour, calories FROM fruit WHERE calories < ? AND colour = ?'); $sth->execute(array(150, 'red'));

                              ... und da hätte ich die Reihenfolge selbst in der Hand.

                              Lieber notiere ich etwas mit Namen:

                              ### Zuordnung mit Namen/Keys/Variablen: $sql = 'SELECT name, colour, calories FROM fruit WHERE calories < :calories AND colour = :colour'; $sth = $dbh -> prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY)); $sth -> execute(array(':calories' => 150, ':colour' => 'red'));

                              oder, erst jetzt "gut":

                              $sql = ' SELECT name, colour, calories FROM fruit WHERE calories < :calories AND colour = :colour'; $stmt = $dbh -> prepare( $sql ); $stmt -> bindParam( ':calories', $calories ); $stmt -> bindParam( ':colour' , $color ); $calories = 150; $color = 'red'; $stmt -> execute();

                              Ich fürchte mich nämlich davor, SELBST die Reihenfolge zu verwechseln und dann gegen "esoterischen Bugs" (beatovich) kämpfen zu müssen. Wer das (wie ich) schon mal hatte, der weiß sehr genau, wie garstig diese Käfer täuschen und tricksen damit man sie nicht erkennt. Aus dem Grund bin ich auch ein Freund einer nicht zeilensparenden, maximal übersichtlichen Notation.

                              Ansonsten bin ich nicht so überzeugt davon, durch den User-Agent Formulardaten in json zu packen und dann abzusenden. Jedenfalls nicht in jedem Fall. Grund: Mehr Code -> mehr Fehler.

                              1. Lieber ursus,

                                und da gilt "form follows function"

                                das hat Dir bestimmt eine fast verbrauchte hobby-hergestellte Seife gesagt.

                                Liebe Grüße,

                                Felix Riesterer.

                              2. Was Dein Frontenddesigner macht ist eine ganz andere Geschichte.

                                Enctype application/x-www-form-urlencoded und multipart/form-data verändern die Reihenfolge nicht. Da kannst Du Dich 100%ig darauf verlassen!

                                MfG

              2. Oder so?

                ⦿ Ich bestätige, die AGB gelesen zu haben und erkenne diese an.
                ◯ Ich erkenne die AGB nicht an.

                Das dürfte juristisch schief gehen - falls die Vorauswahl dem Kunde so präsentiert wird. Das mag jetzt nebensächlich erscheinen aber damit sind wir bei bei dem Umstand, dass nur der Sachzusammenhang entscheidend für die Frage ist, ob Checkboxen oder Radiobuttons verwendet werden sollten.

                Beide haben eine Berechtigung.

                1. @@ursus contionabundo

                  Oder so?

                  ⦿ Ich bestätige, die AGB gelesen zu haben und erkenne diese an.
                  ◯ Ich erkenne die AGB nicht an.

                  Das dürfte juristisch schief gehen - falls die Vorauswahl dem Kunde so präsentiert wird.

                  Da hast du recht. Die Checkbox hatte ich aus dem Grund auch nicht angehakt. Bei den Radiobuttons anderen hätte ich die anderen vorauswählen sollen.

                  Das mag jetzt nebensächlich erscheinen aber damit sind wir bei bei dem Umstand, dass nur der Sachzusammenhang entscheidend für die Frage ist, ob Checkboxen oder Radiobuttons verwendet werden sollten.

                  Beide haben eine Berechtigung.

                  Darauf wollte ich hinaus.

                  LLAP 🖖

                  -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                2. Hello,

                  oder noch besser so?

                  ◯ Ich bestätige, die AGB gelesen zu haben und erkenne diese an.
                  ◯ Ich erkenne die AGB nicht an.
                  ⦿ bitte lesen Sie meine Anmerkugnen zu Ihren AGB: -> Textfeld

                  SO sollte das gesetzlich vorgeschrieben werden. Das würde nämlich dazu führen, dass Leute die AGB tatsächlich manchmal lesen und AGB-Bereitsteller diese möglichst knapp und verständlich halten, weil sonst ca. 50-70% der Antworten mit Anmerkungen zurückkommen werden.

                  Man kann in papierenen Kaufverträgen durchaus Abwehrklauseln gegen bestimmte AGBs geltend machen. Die "Digitalisierung", die hier eher eine "Binärisierung" ist, versucht aber diese legitime Verhandlungssituation auszuschalten. Es findet also eine ungleiche Gewichtung in Richtung des wirtschaftlich Stärkeren statt. Das sollte das Gesetz ausschließen!

                  Glück Auf
                  Tom vom Berg

                  -- Es gibt nichts Gutes, außer man tut es!
                  Das Leben selbst ist der Sinn.
                  1. Hallo TS,

                    hast Du schon einmal mit einem Unternehmen erfolgreich über AGB-Klauseln verhandelt? Hat Dir ein Händler schon einmal anerkannt, dass Du im Kaufvertrag einer AGB Klausel widersprochen hast? Käme mir jetzt als die große Ausnahme vor, gerade im Einzelhandel. Im Großhandel mag es anders sein.

                    Wenn die AGB dir nicht passen, bleibt nach meiner Erfahrung eigentlich nur der Lieferantenwechsel. Oder das Vertrauen darauf, dass eine unangenehme Klausel eh unwirksam ist und vor Gericht durchfällt.

                    Rolf

                    -- sumpsi - posui - clusi
                    1. Hello,

                      hast Du schon einmal mit einem Unternehmen erfolgreich über AGB-Klauseln verhandelt?

                      Ich habe einfach meine Wünsche in den Einzelvertrag als wichtigen Vertragsgegenstand aufgenommen. Die Geschäftspartner haben dies meistens klaglos akzepiert. Es gilt dann immer die im Einzelvertag vermerkte Abweichung.

                      Hat Dir ein Händler schon einmal anerkannt, dass Du im Kaufvertrag einer AGB Klausel widersprochen hast? Käme mir jetzt als die große Ausnahme vor, gerade im Einzelhandel. Im Großhandel mag es anders sein.

                      Ja. Oft.
                      Und diese Möglichkeit sollte auch keinem Rechtsgechäft im Wege stehen.

                      Wenn die AGB dir nicht passen, bleibt nach meiner Erfahrung eigentlich nur der Lieferantenwechsel. Oder das Vertrauen darauf, dass eine unangenehme Klausel eh unwirksam ist und vor Gericht durchfällt.

                      Dann hast Du es vermutlich nicht versucht, oder aber Du hattest gar nicht erst die Möglichkeit, es zu versuchen - was ich hier im Thread dargelegt hatte!

                      Glück Auf
                      Tom vom Berg

                      -- Es gibt nichts Gutes, außer man tut es!
                      Das Leben selbst ist der Sinn.
                    2. Oder das Vertrauen darauf, dass eine unangenehme Klausel eh unwirksam ist und vor Gericht durchfällt.

                      Nicht grundlos sind die deutschen Gerichte für mich denkbar merkwürdige Organisationen, denen ich höchstes Misstrauen entgegen bringe. (Mal ehrlich: Wenn das alles, was mir über Jahre hinweg seitens diverser Richter als Fehlurteil oder auf leicht ersichtlich nicht zutreffenden Tatsachenbehauptungen (der Richter!) basierender Beschluss präsentiert wurde, nur "Fehler" sein sollen, dann müssten sehr viele Richter jedenfalls für den Job zu dumm sein. Wenn die Richter aber nicht derart dämlich sind wie es nunmehr aus den Beschlüssen hervorgeht, dann bleibt nur Rechtsbeugung - was aber alle "Organe der Rechtspflege" entgegen der Logik ganz einhellig verneinen - und versuchen sogar, mich nach berechtigter Kritik an diesen frechen Rechtsbrüchen zu verfolgen. und auch dabei das Gesetz (hier den insoweit klar zutreffenden §193 StGB) "mal ganz kurz zu vergessen".

                      • Wenn mir also AGB nicht gefallen, dann kaufe ich einfach nicht.
    3. hallo

      Lieber Linuchs,

      für eine JA / NEIN Aussage ist input type checkbox geeignet.

      richtig. Aber der besseren UX wegen ist ein Paar von zwei Radio-Buttons geeigneter, von denen einer mit einer Vorselektierung versehen ist.

      Das kommt darauf an, welche Folgen aus ja/nein entstehen.

      Zum Beispiel ist ein Unterschied zwischen den Fragen

      • Sind Sie schwul?
      • Möchten Sie diese Option aktivieren?

      Eventuell ist unset die gewünschte Antwort.

      Und die sollte auch wieder herstellbar sein.

      -- https://beat-stoecklin.ch/pub/index.html
      1. Lieber beatovich,

        Zum Beispiel ist ein Unterschied zwischen den Fragen

        • Sind Sie schwul?
        • Möchten Sie diese Option aktivieren?

        Eventuell ist unset die gewünschte Antwort.

        Und die sollte auch wieder herstellbar sein.

        was hat das mit @Linuchs' OP zu tun?

        Für Deinen speziellen Fall würde ich ein <select> verwenden, mit drei(!) <option>s:

        <select name="settings"> <option value="">nicht benutzen</option> <option value="on">aktivieren</option> <option value="off">deaktivieren</option> </select>

        Liebe Grüße,

        Felix Riesterer.

        1. @@Felix Riesterer

          Für Deinen speziellen Fall würde ich ein <select> verwenden, mit drei(!) <option>s:

          <select name="settings"> <option value="">nicht benutzen</option> <option value="on">aktivieren</option> <option value="off">deaktivieren</option> </select>

          Vergleichen wir mal:

          1. nicht benutzen ↕️
            • Optionen nicht erkennbar, sondern erst nach Öffnen des Auswahlmenüs
            • zum Ändern der Auswahl 2 Clicks erforderlich
          2. ⦿ nicht benutzen
            ◯ aktivieren
            ◯ deaktivieren

            • alle Optionen sofort auf einen Blick erkennbar
            • Ändern der Auswahl durch einen Click

          Ich sehe nichts, was für <select> spricht; ein <fieldset> mit einer Gruppe von Radiobuttons sollte das bevorzugte UI-Element sein.

          LLAP 🖖

          -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
          1. Hallo Gunnar Bittersmann,

            Für Deinen speziellen Fall würde ich ein <select> verwenden, mit drei(!) <option>s:

            <select name="settings"> <option value="">nicht benutzen</option> <option value="on">aktivieren</option> <option value="off">deaktivieren</option> </select>

            Vergleichen wir mal:

            1. nicht benutzen ↕️
              • Optionen nicht erkennbar, sondern erst nach Öffnen des Auswahlmenüs
              • zum Ändern der Auswahl 2 Clicks erforderlich

            size existiert.

            Damit sind wie bei

            1. ⦿ nicht benutzen
              ◯ aktivieren
              ◯ deaktivieren

            ebenfalls

            • alle Optionen sofort auf einen Blick erkennbar
            • Ändern der Auswahl durch einen Click

            und auch der Platzbedarf sollte ähnlich sein, solange du die Radiobuttons nicht nebeneinander setzen möchtest, was mMn. der Zugänglichkeit nicht entgegenkäme.

            Bis demnächst
            Matthias

            -- Pantoffeltierchen haben keine Hobbys.
            1. @@Matthias Apsel

              size existiert.

              Mit size="3" sieht’s dann so aus:

              Die Funktion des UI-Elements ist nicht ersichtlich.

              Wenn man der ersten option ein selected-Attribut verpasst:

              Selbst damit ist die Funktion des UI-Elements immer noch nicht so gut zu erkennen wie bei Radiobuttons. Radiobuttons bleiben immer noch das Mittel der Wahl.

               

              solange du die Radiobuttons nicht nebeneinander setzen möchtest

              Möchte ich nicht. Das sollte allgemein nicht tun; höchstens in wohl überlegten Ausnahmefällen.

              LLAP 🖖

              -- „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
              1. Hallo Gunnar Bittersmann,

                Selbst damit ist die Funktion des UI-Elements immer noch nicht so gut zu erkennen wie bei Radiobuttons. Radiobuttons bleiben immer noch das Mittel der Wahl.

                Ich würde mich im speziellen Fall auch für Radiobuttons entscheiden. Deine Argumente

                • Optionen nicht erkennbar, sondern erst nach Öffnen des Auswahlmenüs
                • zum Ändern der Auswahl 2 Clicks erforderlich

                sind aber aus meiner Sicht nicht haltbar, zumal sicher in beiden Fällen ein fieldset mit einer entsprechenden legend verwenden würde.

                Bis demnächst
                Matthias

                -- Pantoffeltierchen haben keine Hobbys.