nicht angemeldet dedlfix
Felix Riesterer
Rolf B
Rolf B
Gunnar Bittersmann
Der Martin
Rolf B
Der Martin
Rolf B
Der Martin
Felix Riesterer
Rolf B
Rolf B
Hallo,
ich muss eine ganze Reihe Radiobuttons vorbelegen und weils so viele sind, dachte ich mir, mach ichs über eine Schleife. Die Werte zu den Radios kommen aus der db.
Tabellenkalk $arr_ioWerte = array('spalte1','spalte2','spalte3',... usw.);
$row = mysqli_fetch_assoc($result);
foreach($arr_ioWerte AS $Einzelwert) {
if ($row[$Einzelwert] == 1) {
$row[$Einzelwert][1] = ' checked="checked"';
$row[$Einzelwert][0] = '';
} else {
$row[$Einzelwert][0] = ' checked="checked"';
$row[$Einzelwert][1] = '';
}
}
...
<input type=radio name=\"sp1\" value=\"1\" ".$row['spalte1'][1]." >iO
<input type=radio name=\"sp1\" value=\"0\" ".$row['spalte1'][0]." >iO
Ich kann mir in der foreach-Schleife schon $row[$Einzelwert] ausgeben lassen. Aber irgendwie ist wohl mein assoziatives Array falsch, denn im Quettext des HTML kommt folgendes raus:
<input type=radio name="spalte1" value="1" >iO
<input type=radio name="spalte1" value="0" 1>nIO
Soll heißen, mein assoziatives Array funkt nicht.
Jochen
Tach!
if ($row[$Einzelwert] == 1) { $row[$Einzelwert][1] = ' checked="checked"'; $row[$Einzelwert][0] = '';
Die Werte aus dem DBMS werden als String geliefert, auch Zahlen. Wenn du auf den String in $row[$Einzelwert] mit der Array-Notation zugreifst, werden einzelne Zeichen angesprochen. Wenn du den String mit einem Array austauschen möchtest, musst du ein Array an $row[$Einzelwert] zuweisen.
dedlfix.
Die Werte aus dem DBMS werden als String geliefert, auch Zahlen. Wenn du auf den String in
$row[$Einzelwert]mit der Array-Notation zugreifst, werden einzelne Zeichen angesprochen. Wenn du den String mit einem Array austauschen möchtest, musst du ein Array an$row[$Einzelwert]zuweisen.
Hi dedlfix.
Ich fürchte, hier verstehe ich nicht gamz, was Du meinst. Es sollte doch analog zu
$array_A[] = "test";
möglich sein,
$array[A][] = "test2";
ein assoziatives Array zu bilden, oder?
Und so wollte ich meinem
$row[$Einzelwert] einfach eine 2. Ebene hinzufügen, also $row[$Einzelwert][].
Warum geht das nicht?
Jochen
Tach!
Ich fürchte, hier verstehe ich nicht gamz, was Du meinst. Es sollte doch analog zu
$array_A[] = "test";möglich sein,
$array[A][] = "test2";ein assoziatives Array zu bilden, oder?
Ja, aber dein Fall ist geringfügig anders. Mit einem leeren Klammernpaar [] wird zwar erwartungsgemäß ein neues Feld angelegt, wenn die Variable nicht existent oder null oder ein Array wäre. Du hast aber bereits einen String darin und verwendest außerdem [0] und [1] und greifst damit auf die bereits bestehenden Elemente zu. Und das sind bei einem String die einzelnen Zeichen.
Und so wollte ich meinem
$row[$Einzelwert]einfach eine 2. Ebene hinzufügen, also$row[$Einzelwert][].Warum geht das nicht?
Das ist nicht der Code aus dem Eingangsposting, wegen [] versus [0] und [1]. Der würde aber auch einen Fatal Error werfen, weil der Operator []für Strings nicht unterstützt wird.
dedlfix.
Hi dedlfix,
Ja, aber dein Fall ist geringfügig anders. Mit einem leeren Klammernpaar
[]wird zwar erwartungsgemäß ein neues Feld angelegt, wenn die Variable nicht existent oder null oder ein Array wäre. Du hast aber bereits einen String darin und verwendest außerdem[0]und[1]und greifst damit auf die bereits bestehenden Elemente zu. Und das sind bei einem String die einzelnen Zeichen.
Ok.
Warum geht das nicht?
Das ist nicht der Code aus dem Eingangsposting, wegen
[]versus[0]und[1]. Der würde aber auch einen Fatal Error werfen, weil der Operator[]für Strings nicht unterstützt wird.
Stimmt. Das ist etws anders als in der Einstiegsfrage.
Aber dann müsste es ja so funktionieren?
if ($row[$Einzelwert] == 1) {
$arr[$row[$Einzelwert]][1] = ' checked';
$arr[$row[$Einzelwert]][0] = '';
} else {
$arr[$row[$Einzelwert]][0] = ' checked';
$arr[$row[$Einzelwert]][1] = '';
}
Jochen
Tach!
Aber dann müsste es ja so funktionieren?
if ($row[$Einzelwert] == 1) { $arr[$row[$Einzelwert]][1] = ' checked'; $arr[$row[$Einzelwert]][0] = ''; } else { $arr[$row[$Einzelwert]][0] = ' checked'; $arr[$row[$Einzelwert]][1] = ''; }
Probier es und überprüf das Ergebnis mit var_dump(). (Davor ein <pre> ausgeben oder in den Quelltext schauen, dann ist das lesbar formatiert.)
Das Ergebnis hängt jedenfalls davon ab, ob $arr existierte und wenn ja, was sich darin befand. Abgesehen davon ist $arr ein schlechter Name, weil der nicht beschreibt, wofür die Variable da ist.
dedlfix.
Das Ergebnis hängt jedenfalls davon ab, ob $arr existierte und wenn ja, was sich darin befand. Abgesehen davon ist $arr ein schlechter Name, weil der nicht beschreibt, wofür die Variable da ist.
Hi dedlfix,
ok, das ist der entscheidende Satz, jetzt verstehe ich es. UNd $arr war nur ein Beispiel, ich setze das eher so um, wie von Rolf vorgeschlagen. Aber mir war wichtig, das mit dem assoziativen Array zu verstehen. Meine "Zuweisung" war nämlich gar keine, sondern es war ein Zugriff auf das vorhandene Array, in dem sich ein String befand. Insofern hatte ich auf ein Element, in diesem Fall ein Zeichen des Strings zugegriffen.
Danke, Jochen
Lieber Jochen,
ich muss eine ganze Reihe Radiobuttons vorbelegen
das klingt für mich einigermaßen nach Formularinhalte vorbelegen. Jetzt sehe ich aber, dass diese Methode eben genau keine Radio-Buttons vorbelegt. Lass uns mal überlegen, wie wir das am geschicktesten hinzufügen. Dadurch würde der Artikel im Wiki auch gewinnen.
Grundidee: In einem Array stehen die Werte, die auf die Eingabe-Elemente des Formulars aufgebracht werden sollen.
[type="text"] ist ja klar, da schreibt man den Wert in ein value-Attribut.[type="checkbox"] setzt man genau dann ein checked-Attribut, wenn es einen passenden Array-Schlüssel gibt, dessen zugewiesener Wert wie true interpretiert werden kann.[type="radio"] bräuchten wir ein passendes Element, dessen name-Attribut passt und dessen value-Attribut ebenso passt.Kriegst Du das selbst hin, oder brauchst Du dafür Hilfe?
Liebe Grüße
Felix Riesterer
Hallo Felix,
das Ding anzupassen dürfte schon anspruchsvoll sein, und es wirft das aktuelle Design der Seite über den Haufen. Es setzt voraus, dass man ein PHP Script schreibt, dass ein vollständiges DOMDokument Objekt aufbaut und ausgibt, statt - wie in PHP eher üblich - das HTML selbst Schritt für Schritt auszugeben. Braucht eine Template-Sprache ein Template-System? Häufiger Diskussionspunkt in PHP.
Ich weiß auch nicht, wie exakt man mit DOMDocument das generierte HTML beeinflussen kann, vor allem, wenn Scripte oder anderes dazu kommen. Hast Du da Erfahrungen?
Der Artikel macht es einem auch nicht leicht, die dargestellten Informationen richtig einzuordnen. Der Abschnitt "Formularinhalte vorbelegen" hat mit der Metavariablen-Ersetzung inhaltlich nichts zu tun, bezieht aber Techniken aus dem vorigen Abschnitt "Metavariablen" mit ein, ohne das ausdrücklich zu benennen
Sodann scheint mir, als wäre der Artikel überarbeitungswürdig. Ich habe ihn nicht vollständig gelesen, sondern nur erstmal die beiden jetzt angesprochenen Teile angeschaut.
(1) move_nodes. Fehlt da im backwards-Modus nicht das ->importNode? Und wieso wird ein "backwards" Modus verwendet, wenn es doch eigentlich darum geht, die Kinder von $from entweder als Geschwister vor $to zu setzen (insertBefore) oder an die Kinder von $to anzuhängen (appendChild). API und Arbeitsweise dieser Funktion scheinen mir sehr suspekt.
(2) preselect_form_values. Ein Monster, das "zerlege mich" schreit, und das sehr ungeschickt nach seinen Daten sucht. Warum so:
function preselect_form_values ($node, $data) {
foreach ($node->getElementsByTagName('*') as $n) {
if ($n->hasAttribute('name')) {
foreach (array_keys($data) as $key) {
if ($n->getAttribute('name') === $key) {
switch ($n->tagName) {
...
}
}
}
}
}
}
In $data kann es maximal einen Key mit dem Namen des Node geben. Wieso dann die Keys sequenziell durchlaufen? isset reicht völlig. Eine hasAttribute-Abfrage auf dem DOM Node ist auch überflüssig. getAttribute liefert einen Leerstring, wenn das Attribut nicht existiert. Bei mir sähe das - wenn überhaupt - so aus:
function preselect_form_values ($formNode, $data) {
foreach ($formNode->getElementsByTagName('*') as $elementNode) {
$name = $elementNode->getAttribute('name');
if ($name && isset($data[$name])
preselect_form_element($elementNode, $data[$name]);
}
}
Und der eigentlich Job wird ausgelagert. Lies: Robert Martin, Clean Code.
function preselect_form_element($elementNode, $value) {
switch ($elementNode->tagName) {
case "input":
switch ($elementNode->getAttribute("type")) {
case "text":
return preselect_form_input_text($elementNode, $value);
case "number":
return preselect_form_input_number($elementNode, $value);
case "checkbox":
return preselect_form_input_checkbox($elementNode, $value);
case "radio":
return preselect_form_input_radio($elementNode, $value);
}
break;
}
case "textarea":
return preselect_form_textarea($elementNode, $value);
case "select":
return preselect_form_select($elementNode, $value);
}
}
Am besten passt das in eine Mapper-Klasse.
Rolf
Hi Felix,
danke für Deine Antwort, aber ich habe mich bisher immer erfolgreich von Templates weit weg gehalten. Vielleicht ein Fehler, aber ich hatte in früheren zeiten mal in einem Webforum herum gecoded, was mit Templates arbeitete, das fand ich gräuslich.
Also für mich lieber ohne Templates, trotzdem danke.
Jochen
Lieber Jochen,
aber ich habe mich bisher immer erfolgreich von Templates weit weg gehalten.
das habe ich auch. Mittlerweile frage ich mich, ob das Hantieren mit den DOM-Klassen schon zum Arbeiten mit Templates zählt. Wenn man HTML und PHP streng trennen will, dann muss man die Frage mit "ja" beantworten. Das Beispiel nimmt ja eine "fertige" HTML-Datei als Vorlage (also "Template"), um dann etwas mit ihr zu tun.
Vielleicht ein Fehler, aber ich hatte in früheren zeiten mal in einem Webforum herum gecoded, was mit Templates arbeitete, das fand ich gräuslich.
Wie immer kommt es darauf an, wie etwas umgesetzt wird. Und ja, da gibt es die tollsten Sachen. PHP war selbst einmal "nur" als Template-Sprache gedacht...
Also für mich lieber ohne Templates, trotzdem danke.
Ist das wirklich so? Wenn Du so wirklich brutal ehrlich bist, dann sind doch Deine Konstrukte auch nur etwas andere Templates. Findest Du nicht? Wo ist denn da der wirklich große Unterschied?
Mit den DOM-Klassen kann ich komplexere Änderungen am späteren HTML-Code vornehmen, weil ich eben nicht mehr auf String-Ebene arbeite. Vor Jahren habe ich die tollsten RegExp in PHP gebaut, um mein HTML passend zu verändern. Aber wo ist die Garantie, dass da keine syntaktischen Fehler entstehen, die zunächst nicht auffallen, weil das Ergebnis im Browser korrekt angezeigt wird? Mit den DOM-Klassen habe ich automatisch eine Validierung des HTML-Codes. Neben so bequemen Sachen wie die vorgeschlagene Funktion "preselect_form_values"...
Liebe Grüße
Felix Riesterer
Hallo Jochen,
wenn Du mehrfach eine Radiobutton-Gruppe für "iO" / "niO" erzeugen musst, dann kann es sich anbieten, das in eine Funktion auszulagern.
Natürlich kannst Du Dich auch mit der von Felix angesprochenen Template-Technik auseinandersetzen. Aber zum einen ist das unfertig, zum anderen mag es sein, dass Dir das zu komplex ist.
Statt ARRAY() kann man übrigens auch [ ] schreiben.
Ob Du die Spaltennamen für die ioWerte als Array brauchst, hängt davon ab, ob es sich tatsächlich lohnt, die Radiogruppen in einer Schleife aufzubereiten. Hat deine Seite eine Art Checkliste, bestehend aus Frage und iO/nIO Gruppe? In dem Fall wäre eine Funktion sinnvoll, die eine vollständige Zeile der Checkliste ausgibt und man kann sich Gedanken über eine Steuertabelle für diese Checkliste machen.
Wenn sich die iO/niO-Gruppen durch das Formular verteilen, genügt eventuell eine Funktion, die nur diese beiden input-Elemente ausgibt. Beachte dabei: Der Text für ein input-Element muss als <label> ins HTML. Um dabei nicht in id-Attributen abzusaufen, bietet es sich an, das input-Element als Kind des Label zu schreiben. Also so, zum Beispiel:
<label><input type="radio" name="spalte1" value="1" checked> iO</label>
<label><input type="radio" name="spalte1" value="0"> niO</label>
Die Schreibweise 'checked="checked"' ist für XHTML notwendig. Verwendest Du das? Andernfalls reicht ein einfaches 'checked'.
Dann fehlt noch die Überlegung, wie sich das für Assistenztechniken darstellt. Je nachdem, wie einheitlich der Rest deines HTML aussieht, könnte eine Funktion für Radiogruppen auch noch den Text ausgeben, der Auskunft über die Bedeutung dieser Radiogruppe gibt. Darauf gehe ich jetzt nicht ein, dafür kenne ich deine Rahmenbedingungen zu wenig.
Eine Funktion, die das oben stehende Fragment ausgibt, könnte so aussehen:
function erzeugeIORadiogruppe($name, $wert) {
?>
<label>
<input type="radio" name="<?= $name ?>"
value="1" <?= $wert == 1 ? "checked" : "" ?>> iO
</label>
<label>
<input type="radio" name="<?= $name ?>"
value="0" <?= $wert == 1 ? "" : "checked" ?>> niO
</label>
<?php
}
Beachte, dass die Funktion die PHP Umgebung verlässt, um HTML auszugeben. Nur bei Bedarf wird mit <?= ... ?> mal kurz nach PHP zurückgekehrt, um einen Wert aus PHP zu holen. Vor allem, wenn man einen Editor mit Syntax-Highlighting hat, ist das deutlich besser lesbar. Das doppelte > am Ende des input-Elements sieht zwar erstmal merkwürdig aus, aber eins davon gehört zum ?> von PHP und das andere gehört zum Input-Element.
Wenn Du dein Dokument allerdings erstmal in einem String zusammenbaust, ist dieser Ansatz umständlich. Dann musst Du doch einen String erzeugen und zurückgeben (oder mit ob_start die Ausgabe abfangen - das wäre lästig).
Die vielen Zeilenumbrüche sind der Lesbarkeit im Forum geschuldet, das kannst Du nach Wunsch wieder auf eine Zeile ziehen.
Diese Funktion rufst Du überall da auf, wo Du derzeit deine input-Elemente erzeugst. Eine Vorab-Umwandlung der booleschen Werte entfällt. Die Funktion steuert das intern, an genau einer Stelle im Programm.
erzeugeIORadioGruppe("spalte1", $row["spalte1"]);
erzeugeIORadioGruppe("spalte2", $row["spalte2"]);
erzeugeIORadioGruppe("spalte3", $row["spalte3"]);
erzeugeIORadioGruppe("spalte4", $row["spalte4"]);
Sicherlich wird das so nicht allein da stehen, da muss noch PHP drum herum für weitere Texte und Strukturelemente. Aber, wie gesagt, je nach Einheitlichkeit deines HTML kann auch einiges davon von erzeugeIORadioGruppe mit erledigt werden.
Rolf
@@Rolf B
Die Schreibweise 'checked="checked"' ist für XHTML notwendig. Verwendest Du das? Andernfalls reicht ein einfaches 'checked'.
Ein einfaches checked="" sollte für XHTML-Kompitibilität auch reichen.
😷 LLAP
Hallo,
wenn Du mehrfach eine Radiobutton-Gruppe für "iO" / "niO" erzeugen musst, dann kann es sich anbieten, das in eine Funktion auszulagern.
vor allem bietet es sich meines Erachtens an, diese Information mit einer Checkbox abzubilden. Die ist für solche binären Zustände eigentlich prädestiniert.
Live long and pros healthy,
Martin
Hallo Martin,
ja, hab ich auch überlegt, aber mein Posting war schon zu lang um das auch noch zu diskutieren.
Das muss Jochen mit seinem Auftraggeber abklären. Vermutlich führt das zu einem ganztägigen Workshop, weil man dem Auftraggeber erstmal verständlich machen muss, dass eine Radiobutton-Eingabe für "Ja"/"Nein" nur dann sinnvoll ist, wenn es auch die dritte Option "unbekannt" gibt. Die muss man nicht als dritten Radiobutton haben, aber es muss sie zumindest in der DB geben und die Programmierlogik muss es beachten.
Man kann auf diese Weise erzwingen, dass zu jeder iO/niO Frage eine Antwort gegeben wird. Bei einer Checkbox kann man auch eine vergessen und das gilt dann als niO.
Zwei Radiobuttons, von denen einer immer vorbelegt wird, KÖNNTEN sinnvoll sein wenn sie etwas anderes als ja/nein auswählen, z.B. rot oder blau. Eine Checkbox würde Extratext benötigen, um die Semantik von "Haken" und "kein Haken" darzustellen.
Rolf
Hallo Rolf,
Das muss Jochen mit seinem Auftraggeber abklären. Vermutlich führt das zu einem ganztägigen Workshop, weil man dem Auftraggeber erstmal verständlich machen muss, dass eine Radiobutton-Eingabe für "Ja"/"Nein" nur dann sinnvoll ist, wenn es auch die dritte Option "unbekannt" gibt.
oder "teilweise", oder "nicht zutreffend". Ja, richtg - das geht aber aus Jochens Beispieldaten und -code nicht hervor, die lassen auf reine Ja/Nein-Aussagen schließen.
Man kann auf diese Weise erzwingen, dass zu jeder iO/niO Frage eine Antwort gegeben wird. Bei einer Checkbox kann man auch eine vergessen und das gilt dann als niO.
Das Problem ist mir bewusst. Etwas ganz Ähnliches lacht uns gerade bei der Arbeit an: Aus einer Datenbank kommt ein Prüfplan für jedes Produkt. Der enthält je nach Art des Produkts so 20..50 einzelne Testfälle. Eine Spalte (derzeit Boolean) gibt an, ob dieser Testfall für das Produkt individuell zutrifft (z.B. muss ich an einem Produkt, das mit 24VDC versorgt wird, keine Eigenschaften eines 230V-Netzanschlusses testen). In der Vorlage soll diese Spalte aber weder mit Ja, noch mit Nein vorbelegt sein, weil der Prüfer jeden Testfall einzeln bewerten soll. Es wäre blöd, wenn einfach durch Vergessen fälschlicherweise die Aussage entsteht: Trifft nicht zu.
Zwei Radiobuttons, von denen einer immer vorbelegt wird, KÖNNTEN sinnvoll sein wenn sie etwas anderes als ja/nein auswählen, z.B. rot oder blau. Eine Checkbox würde Extratext benötigen, um die Semantik von "Haken" und "kein Haken" darzustellen.
Das stimmt allerdings.
Live long and pros healthy,
Martin
Hallo Rolf, hallo Martin,
Das muss Jochen mit seinem Auftraggeber abklären.
Ich habe eine Vorlage, die es 1:1 umzusetzen gilt. Da ist also kein Spielraum.
Jochen
Hallo Jochen,
okay - du weißt, was da fachlich zu bauen ist und kannst damit von uns hier am besten beurteilen, ob das UI und sein Verhalten für die Anwender eine gute Lösung darstellt. Wir können nur grundsätzliche Maßstäbe beschreiben, an denen Du das messen kannst.
Aber das Argument "das ist die Vorlage, die muss 1:1 umgesetzt werden" ist ungültig. Es setzt nämlich voraus, dass die Vorlage von jemandem erstellt wurde, der sich mit sinnvollem UI Design auskennt. Und DAS ist längst nicht immer der Fall.
Die häufigere Vorgehensweise ist diese: Jemand im Fachbereich, der von IT, Usability und korrektem Design von UIs keine Ahnung hat, möchte einen Vorgang automatisieren. Anstatt den Gesamtprozess zu betrachten und zu überlegen, wie man ihn geeignet per IT umsetzt, nimmt dieser Mensch Excel her, malt damit die Papierformulare ab, benutzt dabei die UI Controls, die Excel für eigene Automatisierung anbietet und nennt das ein Mockup der zu realisierenden Oberfläche. Dazu noch eine oberflächliche Beschreibung dessen, was im Fachbereich gemacht wird, fertig ist die Vorgabe. Das geht dann an die Koordinationsabteilung. Dort sitzt irgendwer, der mangels anderweitiger Verwendbarkeit dorthin abgeschoben wurde, in der Annahme, dort würde er (oder sie - auch Frauen können unfähig sein) den geringsten Schaden anrichten, und gibt diesen Auftrag unreflektiert an die Programmierung.
Ein Projekt, an dem sich Prozess- und UI-Designer beteiligen, wird nicht aufgesetzt. Eine exakte Analyse dessen, was im Fachbereich gemacht wird, findet nicht statt. Ist doch "nur ein Kleinauftrag".
Der IT-Mensch, der mal auf der Uni was von Prozessen und Usability gehört haben mag, kommt mit Rückmeldungen wie "aber das könnte man so und so besser machen". Die werden vom Koordinator abgeschmettert mit der Begründung: der Fachbereich will das genau so haben. Der Versuch einer Klärung scheitert, weil der Koordinator dann zugeben müsste, keine Ahnung zu haben. Das direkte Gespräch mit dem Fachbereich ist verboten, bzw. der Fachbereich ist komplett unbekannt, wenn die IT extern ist.
Die erste Programmversion macht dann genau das, was in der Vorgabe stand. Leider ist das etwas ganz anderes, als der Auftraggeber sich vorgestellt hat. Mit Glück gibt es nun Klärungsrunden. Zumeist hagelt es aber dann Defect-Tickets, aus denen sich die tatsächlich gewünschte Fachlichkeit dann herauskristallisiert. Als externer Lieferant kann man sich dann die Hände reiben, weil man eine Menge Change Requests abrechnen kann.
Und am Ende steht eine halbwegs funktionale und schlecht bedienbare Anwendung, die aber immerhin genau so aussieht wie der Excel-Albtraum des Auftraggebers. Die User meckern über den Mist, den die IT mal wieder geliefert hat. Der Einkauf meckert über den teuren Lieferanten.
Phantasie? Nein, 35 Jahre Berufserfahrung...
Rolf
Hallo Rolf,
Und am Ende steht eine halbwegs funktionale und schlecht bedienbare Anwendung
, die aber immerhin genau so aussieht wie der Excel-Albtraum des Auftraggebers. Die User meckern über den Mist, den die IT mal wieder geliefert hat. Der Einkauf meckert über den teuren Lieferanten.
entschuldige bitte die Manipulation des Zitats, aber wenn man den gestrichenen Nebensatz mal weglässt, ist das eine nahezu perfekte Beschreibung von SAP.
Phantasie? Nein, 35 Jahre Berufserfahrung...
Dem habe ich nichts mehr hinzuzufügen.
Live long and pros healthy,
Martin
Hallo Rolf,
Aber das Argument "das ist die Vorlage, die muss 1:1 umgesetzt werden" ist ungültig. Es setzt nämlich voraus, dass die Vorlage von jemandem erstellt wurde, der sich mit sinnvollem UI Design auskennt. Und DAS ist längst nicht immer der Fall.
Gebe ich Dir völlig Recht, aber es war grad für mich die schnellste und einfachste Antwort und die, bei der ich am wenigsten Rückfragen und Diskussion erwartet hatte 😉
Also: Ich habe eine Papiervorlage und einigermaßen große Narrenfreiheit bei der Umsetzung und unter dem Aspekt, dass hier nicht nur io/nIo Radios verwendet werden, einem einheitlichen Formular- und entsprechend auch Druckbild im PDF habe ich mich für die beibehaltung der Radios entschieden. Es gäbe auch Gründe für Checkboxen, ja, aber eine Diskussion hierüber erübrigt sich vor dem Hintergrund des Volumens dieses Auftrages und meiner Argumente für die Radios.
Du hast u.a. in einem Punkt recht: Ich muss den Platz auf dem PDF sinnvoll nutzen und die Radios sind in diesem Fall etwas selbsterklärender als Checkboxen es wären. Ich könnte natürlich die Checkboxen im HTML nutzen und dann als Radios im PDF darstellen, aber da ist mir in diesem Fall das einheitlichere Bild zwischen HTML und PDF wertvoller.
Und dann "last not least" gibt es 2-3 Punkte, bei denen ich Sorge habe, dass eine Checkbox, obwohl technisch ggf. sinnvoller, zu weniger Usability im Gesamtprozess führen wird, weil hier ein "habe ich vergessen, ein Häkchen zu setzen" einen komplett anderen Input darstellen würde. Und ich kann hier nicht kontrollieren, ob vergessen oder bewußt nicht angehakt. Das kann ich aber bei einem Radiobutton durchaus aber machen, wenn ich ihn nicht selber vorbelege.
Jochen
Lieber Jochen,
Und dann "last not least" [...] weil hier ein "habe ich vergessen, ein Häkchen zu setzen" einen komplett anderen Input darstellen würde.
<select>?Und ich kann hier nicht kontrollieren, ob vergessen oder bewußt nicht angehakt. Das kann ich aber bei einem Radiobutton durchaus aber machen, wenn ich ihn nicht selber vorbelege.
Im Dropdown kann man auch "erzwingen", dass da ein Wert stehen muss, wenn man keine leere Option (wie z.B. >-- bitte wählen --<) anbietet. Es ist natürlich eine Frage der Übersicht, ob man die (eventuell sehr vielen) Optionen zusammen klappt, oder als Liste mit Radio-Buttons präsentiert.
Liebe Grüße
Felix Riesterer
Hi Felix,
- Sind Radio-Buttons dann wirklich "besser" als ein Dropdown mit
<select>?
Definitiv. Die Seite wird ausschließlich über ein Tablet bedient und überlege Dir selber, ob Du lieber 30 Radios "touchen" willst oder jedesmal über ein Dropdown gehen willst. 😉
Jochen
Hallo Jochen,
Das kann ich aber bei einem Radiobutton durchaus aber machen, wenn ich ihn nicht selber vorbelege.
Ja. Damit sind wie aber genau am Trigger der Diskussion: Genau das tust Du. Du belegst sie vor. Den Zustand "noch nicht ausgewählt" lässt Du mit dem Code, den Du gezeigst hast, nicht zu.
Du hast nun klargestellt, dass der Trigger so nicht zutrifft, und damit können wir ein Häkchen an die Diskussion machen 😀
Rolf
Hallo Rolf,
Das kann ich aber bei einem Radiobutton durchaus aber machen, wenn ich ihn nicht selber vorbelege.
Ja. Damit sind wie aber genau am Trigger der Diskussion: Genau das tust Du. Du belegst sie vor. Den Zustand "noch nicht ausgewählt" lässt Du mit dem Code, den Du gezeigst hast, nicht zu.
Du hast nun klargestellt, dass der Trigger so nicht zutrifft, und damit können wir ein Häkchen an die Diskussion machen 😀
Das ist doch jetzt wirklich das Suchen nach dem Haar in der Suppe. Wenn ich 99 Radiobuttons vorbelege und den 100. nicht, muss ich mich dann hier dafür rechtfertigen? Du darfst mir schon zutrauen, eine Änderung ala "nicht vorbelegen" selber in die Funktion einzufügen.
Du hast nun klargestellt, dass der Trigger so nicht zutrifft, und damit können wir ein Häkchen an die Diskussion machen 😀
Nein, nicht "und damit", sondern "ohnehin", weil längst umgesetzt!
Jochen
Hallo Jochen,
Das ist doch jetzt wirklich das Suchen nach dem Haar in der Suppe.
? Du bist ziemlich aggressiv.
Wenn ich 99 Radiobuttons vorbelege und den 100. nicht, muss ich mich dann hier dafür rechtfertigen?
Nein. Aber wenn Du Code vorzeigst, in dem Radiobuttons so vorbelegt werden, dass man sie eigentlich besser durch Checkboxen ersetzt, dann brauchst Du Dich nicht zu wundern, wenn es dazu eine Rückmeldung gibt.
Ich wollte nur abschließend feststellen, dass Du mich davon überzeugt hast, dass meine Überlegung für deinen Fall irrelevant war, und mich dafür rechtfertigen, warum ich überhaupt angefangen habe zu überlegen. Dass Du daraus nun ein Nachtreten konstruiert hast, damit habe ich nicht gerechnet. Das war so nicht gemeint.
Rolf
Hallo,
? Du bist ziemlich aggressiv.
Äh? Nein.
Gruß
Kalk
Hallo,
? Du bist ziemlich aggressiv.
Äh? Nein.
Danke, ich fand mich nämlich auch nicht aggressiv. Vielleicht hätte ich das durch einen Smilie betonen können/sollen, jedenfalls war es nicht aggressiv gemeint. 😉
Ich empfand (und -finde) die Diskussion um eine Checkbox/Radiobutton nur wirklich als zu müßig, als dass man darüber mehr als 2 Sätze verliert.
Trotzdem wollte ich Dich nicht "anmachen" und hatte meinen Post auch nicht so empfunden, zudem dank ich Dir (und auch den anderen) für Deine (ihre) Anregungen zum Thema.
Jochen
Hallo Rolf,
wenn Du mehrfach eine Radiobutton-Gruppe für "iO" / "niO" erzeugen musst, dann kann es sich anbieten, das in eine Funktion auszulagern.
Ja, das könnte ich machen.
aufzubereiten. Hat deine Seite eine Art Checkliste, bestehend aus Frage und iO/nIO Gruppe? In dem Fall wäre eine Funktion sinnvoll, die eine vollständige Zeile der Checkliste ausgibt und man kann sich Gedanken über eine Steuertabelle für diese Checkliste machen.
Ganz genau so ist es. Eine Zeile besteht aus einer Frage und/oder einem Messwert und der anschließenden Beurteilung, ob das als iO oder niO zu beurteilen ist.
Beachte dabei: Der Text für ein input-Element muss als <label> ins HTML.
Stimmt.
Eine Funktion, die das oben stehende Fragment ausgibt, könnte so aussehen:
function erzeugeIORadiogruppe($name, $wert) { ?> <label> <input type="radio" name="<?= $name ?>" value="1" <?= $wert == 1 ? "checked" : "" ?>> iO </label> <label> <input type="radio" name="<?= $name ?>" value="0" <?= $wert == 1 ? "" : "checked" ?>> niO </label> <?php }
Beachte, dass die Funktion die PHP Umgebung verlässt, um HTML auszugeben. Nur bei Bedarf wird mit <?= ... ?> mal kurz nach PHP zurückgekehrt, um einen Wert aus PHP zu holen.
Ich versteh den Code schon, aber klar, Du weißt natürlich nicht, wo ich wissenstechnisch gerade stehe. Ich mag nur den Syntaxwechsel zwischen php und html gar nicht. Ich mag viel lieber, wenn php den html-Code generiert. Das sollte aber erstmal nebensächlich sein.
Ich knabbere grad erstmal daran, warum mein assoziatives Array nicht so will, wie ich wollen würde 😉
Jochen