nicht angemeldet
Rolf B
Gunnar Bittersmann
dedlfix
dedlfix
Gunnar Bittersmann
Matthias Apsel
dedlfix
dedlfix
Hallo,
durch einen klick bei Ganztags auf Ja, geht ein weiteres Feld auf. Klappt wunderbar. Jetzt habe ich ein Problem. Wenn ich mein Eintrag bearbeite, zu erkennen wenn in der URL $_GET['code'] vorkommt, möchte ich je nachdem das Feld direkt geöffnet haben Wie könnte ich dieses umsetzten? Denn ein Click gibt es dort ja nicht. Das heißt die Funktion müsste vorher ausgeführt werden? Ich weiß es leider nicht.
<div class="textfeld" id="ganztags">
<label for="k_ganztags">Ganztags</label>
<input name="k_ganztags"
type="radio"
value="1" <?php echo ($k_ganztags == '1'?'checked="checked"':NULL) ?>/>
<span style="margin-left:8px; margin-right:10px;">Ja</span>
<input name="k_ganztags"
type="radio"
value="0" <?php if(!isset($_GET['code'])) {echo "checked";}?> <?php echo ($k_ganztags == '0'?'checked="checked"':NULL) ?>/>
<span style="margin-left:8px;">Nein</span>
</div>
<div class="textfeld abstand_2" id="zeitraum_b">
<label for="firma">Zeitraum</label>
<input type="text"
name="k_von"
id="k_von"
style="width: 6em; margin-right: 0.5em;"
value="<?php echo htmlspecialchars($k_von);?>" > bis
<input type="text"
name="k_bis"
id="k_bis"
style="width: 6em; margin-left: 0.5em"
value="<?php echo htmlspecialchars($k_bis);?>" > Uhr
</div>
<script>
$(document).ready(function(){
$(':radio[name=k_ganztags]').click(function(){
if($(this).val() == '1'){
$('div#zeitraum_b').hide();
$("#ganztags").addClass("abstand_2");
}
else{
$('div#zeitraum_b').show();
$("#ganztags").removeClass("abstand_2");
}
});
});
</script>
Bis bald!
Meowsalot (Bernd)
Hallo Bernd,
zunächst würde ich annehmen, dass dein Ganztags-Radio genauso gut eine Checkbox sein könnte. Aber es gibt auch Designer, die unbedingt wollen, dass der User was klickt... von daher mag es unvermeidlich sein.
Zweitens ist deine Registrierung des Ready-Handlers veraltet. JQuery möchte nur noch die Form
$(function(){...});
sehen.
Drittens solltest Du die inline-Styles der input-Felder ins CSS verlegen.
Zu deiner Aufgabenstellung: Du musst dann das in PHP tun, was das JavaScript bei click tut: Die Klasse setzen und das einstellen, was show/hide in jQuery macht. WAS das ist, kann ich dir hier vom Handy aus nicht sagen...
Ob Layoutklassen wie abstand_2 sinnvoll sind, ist ein anderes Thema, da halte ich mich jetzt mal zurück.
Rolf
Hallo Rolf,
zunächst würde ich annehmen, dass dein Ganztags-Radio genauso gut eine Checkbox sein könnte. Aber es gibt auch Designer, die unbedingt wollen, dass der User was klickt... von daher mag es unvermeidlich sein.
ich persönlich finde Radio-Buttons schöner. Der User muss dadurch kein Klick mehr machen, da "nein" standardmäßig ausgewählt ist.
Zweitens ist deine Registrierung des Ready-Handlers veraltet. JQuery möchte nur noch die Form
$(function(){...});sehen.
Danke, habe ich geändert.
$(function(){
$(':radio[name=k_ganztags]').click(function(){
if($(this).val() == '1'){
$('div#zeitraum_b').hide();
$("#ganztags").addClass("abstand_2");
} else{
$('div#zeitraum_b').show();
$("#ganztags").removeClass("abstand_2");
}
});
});
Drittens solltest Du die inline-Styles der input-Felder ins CSS verlegen.
Zu deiner Aufgabenstellung: Du musst dann das in PHP tun, was das JavaScript bei click tut: Die Klasse setzen und das einstellen, was show/hide in jQuery macht. WAS das ist, kann ich dir hier vom Handy aus nicht sagen...
Ok, habe ich nun so gelöst
$test = "1";
$anzeigen = "";
if(isset($_GET['code'])) {
if ($test == 1) {
$anzeigen = 'style="display: none;';
} else {
$anzeigen = 'style="display: block;';
}
}
Und im weiteren wird $anzeigen dann so aufgerufen
<div class="textfeld abstand_2" id="zeitraum_b" <?php echo $anzeigen;?>>
......
</div>
Ob Layoutklassen wie
abstand_2sinnvoll sind, ist ein anderes Thema, da halte ich mich jetzt mal zurück.
Wenn man die Klasse kennt und damit schon lange arbeitet ist sie sinnvoll da sie jeder kennt. Aber stimmt, ich sollte diese irgendwann mal umbenennen, spätestens wenn ich das Projekt auf SCSS umstelle.
Bis bald!
Meowsalot (Bernd)
@@Meowsalot
$test = "1"; $anzeigen = ""; if(isset($_GET['code'])) { if ($test == 1) { $anzeigen = 'style="display: none;'; } else { $anzeigen = 'style="display: block;'; } }Und im weiteren wird $anzeigen dann so aufgerufen
<div class="textfeld abstand_2" id="zeitraum_b" <?php echo $anzeigen;?>> ...... </div>
Zum Nichtanzeigen gibt es das hidden-Attribut. Das sollte im Markup stehen, nicht style="display: none" als Inline-Style.
<div class="textfeld" id="zeitraum_b"
<?php if ($test == 1): ?>
hidden=""
<?php endif; ?>
>
Ob Layoutklassen wie
abstand_2sinnvoll sind, ist ein anderes Thema, da halte ich mich jetzt mal zurück.
Ich bin da weniger zurückhaltend: Nein, sie sind nicht sinnvoll.
LLAP 🖖
Tach!
Zum Nichtanzeigen gibt es das
hidden-Attribut. Das sollte im Markup stehen, nichtstyle="display: none"als Inline-Style.
Ja, gibt es. Nur muss man beachten, dass der OP mit jQuery arbeitet, und jQuery die Anzeige von Elementen nicht über hidden sondern über element.style.display mit "none" und "" steuert. Ein hidden-Attribut wird dabei nicht berücksichtigt.
dedlfix.
@@dedlfix
Nur muss man beachten, dass der OP mit jQuery arbeitet, und jQuery die Anzeige von Elementen nicht über hidden sondern über element.style.display mit "none" und "" steuert. Ein hidden-Attribut wird dabei nicht berücksichtigt.
Wenn Methoden in jQuery fehlerhaft implementiert sind, muss man die ja nicht verwenden. Man könnte sich ja eigene Methoden schreiben.
Außerdem spricht heutzutage sehr wenig dafür, überhaupt jQuery zu verwenden.
LLAP 🖖
Tach!
Nur muss man beachten, dass der OP mit jQuery arbeitet, und jQuery die Anzeige von Elementen nicht über hidden sondern über element.style.display mit "none" und "" steuert. Ein hidden-Attribut wird dabei nicht berücksichtigt.
Wenn Methoden in jQuery fehlerhaft implementiert sind, muss man die ja nicht verwenden. Man könnte sich ja eigene Methoden schreiben.
Etwas das lediglich anders funktioniert, aber zum gleichen Ziel kommt, kann nicht per se fehlerhaft sein. Da sehe ich leider wieder den Absolutheitsanspruch zum Vorschein kommen. Ist denn irgendwo definiert, dass das Umschalten der Sichtbarkeit nicht mehr mit display zu erfolgen hat? Dass das hidden-Attribut Vorteile haben kann, ist eine Sache, aber die negiert ja nicht die Verwendbarkeit von display:none/"" grundlegend.
Außerdem spricht heutzutage sehr wenig dafür, überhaupt jQuery zu verwenden.
Das sind Fragen, die der OP mit sich selbst und seinen Gegebenheiten klären muss. Es ist nur nicht hilfreich bei der Lösungspräsentation die aktuellen Gegebenheiten beim OP auszublenden. Ich gehe aber davon aus, dass dir die konkrete Arbeitsweise von jQuery nur nicht bekannt war.
dedlfix.
@@dedlfix
Etwas das lediglich anders funktioniert, aber zum gleichen Ziel kommt, kann nicht per se fehlerhaft sein.
Doch, das kann es. Ist es in dem Fall auch:
Ein zunächst verstecktes Element
<div id="hide-and-seek" hidden>hide-and-seek</div>
wird mit jQuery
$('#hide-and-seek').show();
sichtbar gemacht. jQuery setzt style="display: block", was das display: none aus dem Browserstylesheet überschreibt. Ergebnis:
Ein sichtbares Element, welches ein hidden-Attribut trägt. Semantischer Blödsinn. Die show()-Methode müsste ein eventuell vorhandenes hidden-Attribut löschen. Dass sie es nicht tut, ist ein jQuery-Bug.
Und bevor du jetzt mit „man muss ja nicht das HTML-hidden-Attribut verwenden“ um die Ecke kommst: Eine JavaScript-Bibliothek, die bestimmen will, was vernünftiges HTML ist?? Finde den Fehler!
LLAP 🖖
Tach!
Etwas das lediglich anders funktioniert, aber zum gleichen Ziel kommt, kann nicht per se fehlerhaft sein.
Doch, das kann es. Ist es in dem Fall auch:
Ein zunächst verstecktes Element
Das hast du mit hidden versteckt. Beim OP war das nicht der Fall.
Und bevor du jetzt mit „man muss ja nicht das HTML-
hidden-Attribut verwenden“ um die Ecke kommst: Eine JavaScript-Bibliothek, die bestimmen will, was vernünftiges HTML ist?? Finde den Fehler!
Gefunden. Es ist die Aussage, dass jQuery so etwas bestimmen möchte, wenn es lediglich ein Hilfsmittel bereitstellt, das man nutzen kann, aber nicht muss.
dedlfix.
@@dedlfix
Das hast du mit hidden versteckt.
Mein gutes Recht. Die HTML-Spec sieht das so vor. Empfielt es sogar. Eine JavaScript-Bibliothek sollte damit umgehen können.
… wenn [jQuery] lediglich ein Hilfsmittel bereitstellt, das man nutzen kann, aber nicht muss.
Das war ja meine Rede: Man muss fehlerhaft implementierte jQuery-Methoden nicht nutzen.
LLAP 🖖
Tach!
Das hast du mit hidden versteckt. Mein gutes Recht.
Ja, hat nur dazu geführt, dass die Anwendung an anderer Stelle kaputtgegangen ist. "Das Bild hängt schief."
… wenn [jQuery] lediglich ein Hilfsmittel bereitstellt, das man nutzen kann, aber nicht muss. Das war ja meine Rede: Man muss fehlerhaft implementierte jQuery-Methoden nicht nutzen.
Es fehlt jetzt noch der Beweis für die Behauptung, dass das fehlerhaft sei.
Die HTML-Spec sieht das so vor. Empfielt es sogar.
Für mich wohnt in der Bedeutung vom Empfehlung jedenfalls nicht inne, dass alles andere fehlerhaft sei.
dedlfix.
@@dedlfix
Das hast du mit hidden versteckt. Mein gutes Recht.
Ja, hat nur dazu geführt, dass die Anwendung an anderer Stelle kaputtgegangen ist.
Wenn eine Anwendungan anderer Stelle kaputtgeht, dann ist wohl nicht die Schuld von korrektem Markup.
Das war ja meine Rede: Man muss fehlerhaft implementierte jQuery-Methoden nicht nutzen.
Es fehlt jetzt noch der Beweis für die Behauptung, dass das fehlerhaft sei.
Den hatte ich geliefert. In diesem Thread.
Die HTML-Spec sieht das so vor. Empfielt es sogar.
Für mich wohnt in der Bedeutung vom Empfehlung jedenfalls nicht inne, dass alles andere fehlerhaft sei.
Hat auch niemand behauptet. Es ging nicht darum, dass es ein Fehler wäre, Elemente mit display: none auszublenden. Es ging darum, dass jQuery fehlerhaft arbeitet.
LLAP 🖖
Tach!
Es ging nicht darum, dass es ein Fehler wäre, Elemente mit
display: noneauszublenden. Es ging darum, dass jQuery fehlerhaft arbeitet.
Es arbeitet gemäß seiner Beschreibung. Dass es nicht zu deinem Anwendungsfall passt, heißt nur, dass es nicht zu deinem Anwendungsfall passt. Von diesem Standpunkt aus auf global fehlerhaft zu schließen halte ich für unangemessen.
dedlfix.
@@dedlfix
Dass es nicht zu deinem Anwendungsfall passt, heißt nur, dass es nicht zu deinem Anwendungsfall passt. Von diesem Standpunkt aus auf global fehlerhaft zu schließen halte ich für unangemessen.
Einen allgemeinen Fall von korrektem Markup als „meinen Anwendungsfall“ zu bezeichnen halte ich für unangemessen.
LLAP 🖖
Hallo Gunnar Bittersmann,
Die
show()-Methode müsste ein eventuell vorhandeneshidden-Attribut löschen. Dass sie es nicht tut, ist ein jQuery-Bug.
Das sehe ich auch so. Hast du ihn schon gemeldet?
Bis demnächst
Matthias
Hallo Gunnar,
Ein sichtbares Element, welches ein
hidden-Attribut trägt. Semantischer Blödsinn. Dieshow()-Methode müsste ein eventuell vorhandeneshidden-Attribut löschen. Dass sie es nicht tut, ist ein jQuery-Bug.
und was spricht dagegen das hidden manuell raus zu löschen?
$('#zeitraum_b').removeAttr('hidden');
Bis bald!
Meowsalot (Bernd)
Tach!
und was spricht dagegen das hidden manuell raus zu löschen?
Dagegen spricht, dass es in deinem Fall nicht sinnvoll ist, es überhaupt zu setzen. Zumindest solange du weiterhin mit jQuerys show() und hide() arbeiten möchtest. Dann solltest du stattdessen display:none als style setzen, damit jQuery damit umgehen kann. Alternativ kannst du natürlich auch auf das hidden-Attribut wechseln, dann musst du aber auch statt show()/hide() zu verwenden, dieses Attribut setzen oder löschen.
dedlfix.
Hallo Gunnar,
Zum Nichtanzeigen gibt es das
hidden-Attribut. Das sollte im Markup stehen, nichtstyle="display: none"als Inline-Style.<div class="textfeld" id="zeitraum_b" <?php if ($test == 1): ?> hidden="" <?php endif; ?> >
also so?
$test = 1;
$anzeigen = "";
if(isset($_GET['code'])) {
if ($test == 1) {
$anzeigen = 'hidden=""';
} else {
$anzeigen = '';
}
}
und im HTML dann so?
<div class="textfeld abstand_2" id="zeitraum_b" <?php echo $anzeigen;?>>
.....
</div>
Ich bin da weniger zurückhaltend: Nein, sie sind nicht sinnvoll.
wie würdest du dann die Klasse benennen die ein Abstand nach unten hat?
Bis bald!
Meowsalot (Bernd)
Tach!
<div class="textfeld abstand_2" id="zeitraum_b" <?php echo $anzeigen;?>> ..... </div>Ich bin da weniger zurückhaltend: Nein, sie sind nicht sinnvoll.
wie würdest du dann die Klasse benennen die ein Abstand nach unten hat?
Du hast keine Notwendigkeit, einen g16n-Absolutheitsanspruch befriedigen zu müssen. Wenn es für dich sinnvoll erscheint, den Abstand auf eine andere Weise zu realisieren, dann kommt da auch kein Besucher der Seite daher und beschwert sich darüber. Auch Browser beklagen sich nicht über die Klassennamen. Es ist technisch gesehen egal, welchen Namen du vergibst (Syntaxregeln einhaltend). Der Unterschied ist philosophischer Natur. Folgt man der Philosophie, Angaben zur Darstellung aus dem HTML-Teil herauszuhalten oder nicht?
Alternativen zur präsentationsbezogenen Benennung sind zum Beispiel
Das kann klappen, wenn man andere Regeln hat, an denen man sich orientieren kann, und für die es einen Selector gibt. Beispielsweise, wenn es sich immer um das letzte Element einer List handelt, geht auch li:last-child.
Wenn beispielsweise alle Fehlermeldungen einen Abstand bekommen sollen, bekommen die Fehlermeldungselemente die Klasse "error" und unterscheiden sich dadurch von den anderen Meldungen. Die anderen können ihre eigene Klasse bekommen je nach Wichtigkeit. Aber auch andere Organisationskriterien entsprechend dem Bedarf deiner Anwendung sind möglich.
Eine Benennung nach Semantik/Sinn hat Vorteile, die man nicht unterschätzen sollte, aber es gibt kein Gesetz dazu und auch keine verbindliche Stelle, die Un-/Sinnigkeit festlegt. Ein Vorteil wäre zum Beispiel, wenn du bisher Meldungen der Sorte Fehler und Warnung in rot dargestellt hast, und dafür eine Klasse "rot" vergeben hättest, dann könntest du nun schwer unterscheiden, welche davon nun Fehler sind und rot bleiben, und welche davon Warnungen sind, die nun ein freundlicheres Orange bekommen sollen. Wären deine Meldungen hingegen als "error" oder "warning" klassifiziert, wäre es ein leichtes, eine solche Änderung umzusetzen, die aufgrund der Bedeutung der Elemente vorgenommen werden soll.
dedlfix.
@@dedlfix
Du hast keine Notwendigkeit, einen g16n-Absolutheitsanspruch befriedigen zu müssen.
Dass separation of concerns ein sinnvolles Konzept ist, haben auch andere erkannt. Daraus einen „g16n-Absolutheitsanspruch“ zu machen, ist Bullshit.
LLAP 🖖
Tach!
Du hast keine Notwendigkeit, einen g16n-Absolutheitsanspruch befriedigen zu müssen.
Dass separation of concerns ein sinnvolles Konzept ist, haben auch andere erkannt. Daraus einen „g16n-Absolutheitsanspruch“ zu machen, ist Bullshit.
Ich habe nichts gegen das Konzept an sich gesagt, nur gegen seine Präsentation deinerseits, die keinerlei andere Konzepte zu dulden scheint.
dedlfix.
@@Meowsalot
wie würdest du dann die Klasse benennen die ein Abstand nach unten hat?
Gar nicht. „Abstand“ hat nichts im Markup zu suchen.
Wenn das Element mit der ID zeitraum_b Abstand nach oben haben soll, dann steht halt
#zeitraum_b { margin-top: 3em } im Stylesheet.
Wenn sich die Trennung (Trennung, nicht Abstand) im Markup widerspiegeln soll, ist <hr> dafür geeignet. Das kann man so stylen, dass keine Linie angezeigt, aber ein Abstand gelassen wird.
LLAP 🖖
Tach!
zunächst würde ich annehmen, dass dein Ganztags-Radio genauso gut eine Checkbox sein könnte. Aber es gibt auch Designer, die unbedingt wollen, dass der User was klickt... von daher mag es unvermeidlich sein.
ich persönlich finde Radio-Buttons schöner. Der User muss dadurch kein Klick mehr machen, da "nein" standardmäßig ausgewählt ist.
Eine unangehakte Checkbox repräsentiert auch ein Nein. Zudem kann sie hervorragend die beiden Zustände Ja/Nein annehmen. Oder dachtest du jetzt an zwei Checkboxen, eine für Ja, eine für Nein? Das wäre in dem Fall logisch unsinnig, weil "ganztags" nicht gleichzeitig und unabhängig voneinander Ja und Nein sein kann. Über "nichts angehakt" als Ausdruck für "ich weiß noch nicht" kann man nochmal reden, wenn eine solche Anforderung besteht.
dedlfix.
hallo
Tach!
zunächst würde ich annehmen, dass dein Ganztags-Radio genauso gut eine Checkbox sein könnte. Aber es gibt auch Designer, die unbedingt wollen, dass der User was klickt... von daher mag es unvermeidlich sein.
ich persönlich finde Radio-Buttons schöner. Der User muss dadurch kein Klick mehr machen, da "nein" standardmäßig ausgewählt ist.
Eine unangehakte Checkbox repräsentiert auch ein Nein.
Und was wird da an den Server übertragen?
Tach!
Eine unangehakte Checkbox repräsentiert auch ein Nein.
Und was wird da an den Server übertragen?
Das was schon immer in dem Fall übertragen wurde: nichts.
dedlfix.
hallo
Eine unangehakte Checkbox repräsentiert auch ein Nein.
Und was wird da an den Server übertragen?
Das was schon immer in dem Fall übertragen wurde: nichts.
nichts und nein sind sehr verschiedene Dinge.
Das folgende sollte das verdeutlichen
Tach!
Eine unangehakte Checkbox repräsentiert auch ein Nein.
Und was wird da an den Server übertragen?
Das was schon immer in dem Fall übertragen wurde: nichts.
nichts und nein sind sehr verschiedene Dinge.
Das folgende sollte das verdeutlichen
- Eigenschaft setzen
- Eigenschaft löschen
- keine Angabe (keine Änderung)
"Keine Änderung" erkennt man auch daran, dass der Wert vor und nach der Bearbeitung derselbe ist. Wie bei einem Textfeld, da braucht man auch kein Zusatzkriterium, um eine Nicht-Änderung festzustellen.
Üblicherweise macht man es sich serverseitig einfach, indem man eine Prüfung auf Änderung nicht vornimmt, sondern alle übergebenen Daten zur DB schickt. Das fachliche Ergebnis, ob man einen nicht geänderten Wert nochmal schreibt oder den Schreibvorgang unterlässt, ist dasselbe.
dedlfix.
hallo
"Keine Änderung" erkennt man auch daran, dass der Wert vor und nach der Bearbeitung derselbe ist. Wie bei einem Textfeld, da braucht man auch kein Zusatzkriterium, um eine Nicht-Änderung festzustellen.
Üblicherweise macht man es sich serverseitig einfach, indem man eine Prüfung auf Änderung nicht vornimmt, sondern alle übergebenen Daten zur DB schickt. Das fachliche Ergebnis, ob man einen nicht geänderten Wert nochmal schreibt oder den Schreibvorgang unterlässt, ist dasselbe.
Eben, da musst du in der Lage sein, ein explizites nein zu senden.
Tach!
Üblicherweise macht man es sich serverseitig einfach, indem man eine Prüfung auf Änderung nicht vornimmt, sondern alle übergebenen Daten zur DB schickt. Das fachliche Ergebnis, ob man einen nicht geänderten Wert nochmal schreibt oder den Schreibvorgang unterlässt, ist dasselbe.
Eben, da musst du in der Lage sein, ein explizites nein zu senden.
Nicht das Senden, sondern das Erkennen ist der Punkt.
Die Information "keine Änderung" gibt es nicht. Bei keinem der Eingabelemente.
Eine eventuelle Änderung von dem was der Server (nicht) empfängt zu dem Wert, der in der Datenhaltung stehen soll, ist Teil der Eingabeprüfung.
dedlfix.
hallo
Tach!
Üblicherweise macht man es sich serverseitig einfach, indem man eine Prüfung auf Änderung nicht vornimmt, sondern alle übergebenen Daten zur DB schickt. Das fachliche Ergebnis, ob man einen nicht geänderten Wert nochmal schreibt oder den Schreibvorgang unterlässt, ist dasselbe.
Eben, da musst du in der Lage sein, ein explizites nein zu senden.
Nicht das Senden, sondern das Erkennen ist der Punkt.
- Wert da: Ja,
- Wert nicht da: Nein.
Die Information "keine Änderung" gibt es nicht. Bei keinem der Eingabelemente.
Ich habe geschrieben
Natürlich gibt es das: bei Checkboxen im ungecheckten Zustand.
Tach!
Nicht das Senden, sondern das Erkennen ist der Punkt.
- Wert da: Ja,
- Wert nicht da: Nein.
Die Information "keine Änderung" gibt es nicht. Bei keinem der Eingabelemente.
Ich habe geschrieben
- keine Angabe (keine Änderung)
Ja, wird aber nicht besser dadurch.
Aber wenn du so willst (in PHP-Pseudo-Code):
Das ist äquvalent zu einem Text-Eingabefeld, bei dem man das so prüfen müsste:
Aber wie gesagt, das Wissen um Änderung oder nicht, ist meist nicht gefragt, sondern wie der zu schreibende Wert aussehen muss. Und den bekommt man mit: isset(checkbox). (Oder in überflüssig ausführlich: isset(checkbox) ? true : false)
Natürlich gibt es das: bei Checkboxen im ungecheckten Zustand.
Eine Checkbox (in HTML) hat nur zwei Zustände: angehakt oder nicht. Die Information "keine Änderung" ist damit nicht darstellbar (kein Unterschied zu den anderen Elementen).
dedlfix.
hallo
Tach!
Nicht das Senden, sondern das Erkennen ist der Punkt.
- Wert da: Ja,
- Wert nicht da: Nein.
Die Information "keine Änderung" gibt es nicht. Bei keinem der Eingabelemente.
Ich habe geschrieben
- keine Angabe (keine Änderung)
Ja, wird aber nicht besser dadurch.
Aber wenn du so willst (in PHP-Pseudo-Code):
- $keine_Änderung = isset(checkbox) == $boolescher_wert_in_datenhaltung
Das ist äquvalent zu einem Text-Eingabefeld, bei dem man das so prüfen müsste:
- $keine_Änderung = textbox_value == $string_wert_in_datenhaltung
Aber wie gesagt, das Wissen um Änderung oder nicht, ist meist nicht gefragt, sondern wie der zu schreibende Wert aussehen muss. Und den bekommt man mit: isset(checkbox). (Oder in überflüssig ausführlich: isset(checkbox) ? true : false)
Natürlich gibt es das: bei Checkboxen im ungecheckten Zustand.
Eine Checkbox (in HTML) hat nur zwei Zustände: angehakt oder nicht. Die Information "keine Änderung" ist damit nicht darstellbar (kein Unterschied zu den anderen Elementen).
Richtig, deshalb darfst du gern mal einen Lichtschalter für Raumbeleuchtung via Checkbox gestalten.
Tach!
Eine Checkbox (in HTML) hat nur zwei Zustände: angehakt oder nicht. Die Information "keine Änderung" ist damit nicht darstellbar (kein Unterschied zu den anderen Elementen).
Richtig, deshalb darfst du gern mal einen Lichtschalter für Raumbeleuchtung via Checkbox gestalten.
Wo ist das Problem? Ich schalte um, oder lasse es. Es ist nicht üblich, dem Schalter mitteilen zu müssen, dass er so bleiben soll, wie er ist.
dedlfix.
hallo
Tach!
Eine Checkbox (in HTML) hat nur zwei Zustände: angehakt oder nicht. Die Information "keine Änderung" ist damit nicht darstellbar (kein Unterschied zu den anderen Elementen).
Richtig, deshalb darfst du gern mal einen Lichtschalter für Raumbeleuchtung via Checkbox gestalten.
Wo ist das Problem? Ich schalte um, oder lasse es. Es ist nicht üblich, dem Schalter mitteilen zu müssen, dass er so bleiben soll, wie er ist.
Also so?
[X] Licht einschalten
später
[X] Licht ausschalten
Tach!
Wo ist das Problem? Ich schalte um, oder lasse es. Es ist nicht üblich, dem Schalter mitteilen zu müssen, dass er so bleiben soll, wie er ist.
Also so?
[X] Licht einschalten
später
[X] Licht ausschalten
Geht auch, wenn es ein Taster ist, der im Hintergrund einen Zustandsmerker umschaltet. Aber beim Lichtschalter mit Wippe habe ich ja nicht den Zustand "unberührt" zusammen mit dem Zustand "ich möchte ändern", sondern er befindet sich bereits in einer der beiden Positionen An oder Aus. Die Bedienhandlung schaltet den Zustand direkt um, ohne über die Zwischeninformation "Änderungswunsch" zu gehen.
Bei der Präsentation des Webformulars wird die Checkbox je nach Inhalt in der Datenhaltung auch als angehakt (checked) oder nicht präsentiert. Diesen Zustand ändere ich als Anwender, oder ich lasse ihn wie er ist. Egal was ich mache, beim Absenden des Formulars wird der gewünschte neue (oder immer noch derselbe) Zustand übertragen: vorhanden für checked oder nicht vorhanden für unchecked. Und das kommt direkt in die Datenhaltung. Die Information, ob sich zu vorher etwas geändert hat, braucht es nicht. Die kann bei Bedarf immer noch durch einen Vergleich mit der Datenhaltung ermittelt werden.
dedlfix.
@@Meowsalot
<div class="textfeld" id="ganztags"> <label for="k_ganztags">Ganztags</label> <input name="k_ganztags" type="radio" value="1" <?php echo ($k_ganztags == '1'?'checked="checked"':NULL) ?>/> <span style="margin-left:8px; margin-right:10px;">Ja</span> <input name="k_ganztags" type="radio" value="0" <?php if(!isset($_GET['code'])) {echo "checked";}?> <?php echo ($k_ganztags == '0'?'checked="checked"':NULL) ?>/> <span style="margin-left:8px;">Nein</span> </div>
<label for="k_ganztags"> bezieht sich auf ein Eingabe-Element (bzw. Ausgabe-Element) mit der ID k_ganztags. Ein solches gibt es bei dir nicht.
<input name="k_ganztags" type="radio" …> – der Radiobutton hat keine Beschriftung.
Und auch der zweite Radiobutton muss ein eigenes label haben.
Die Beschriftung für die Gruppe von Radiobuttons wäre als legend eines fieldset-Element gut aufgehoben.
Das Ganze sollte so aussehen:
<fieldset>
<legend>Ganztags</legend>
<label>
<input name="k_ganztags" type="radio" value="0"
<?php if ($k_ganztags == '1'): ?>
checked=""
<?php endif; ?>
/>
<span>Ja</span>
</label>
<label>
<input name="k_ganztags" type="radio" value="1"
<?php if ($k_ganztags == '0'): ?>
checked=""
<?php endif; ?>
/>
<span>Nein</span>
</label>
</fieldset>
(Bekommt die nächste Version des CForums einen brauchbaren Syntaxhighlighter spendiert, @Christian Kruse?)
Ob die Bedingungen so sein sollen, musst du wissen. Wie du es hattest, macht das keinen Sinn; dass checked-Attribut darf nicht doppelt gesetzt werden.
<div class="textfeld abstand_2" id="zeitraum_b"> <label for="firma">Zeitraum</label> <input type="text" name="k_von" id="k_von" style="width: 6em; margin-right: 0.5em;" value="<?php echo htmlspecialchars($k_von);?>" > bis <input type="text" name="k_bis" id="k_bis" style="width: 6em; margin-left: 0.5em" value="<?php echo htmlspecialchars($k_bis);?>" > Uhr </div>
Auch hier muss jedes Eingabefeld ein zugehöriges label haben:
<fieldset>
<legend>Zeitraum</legend>
<label for=k_von">von <span class="visually-hidden">(Uhrzeit)</span></label>
<input name="k_von" id="k_von" value="<?php echo htmlspecialchars($k_von); ?>"/>
<label for=k_von">bis <span class="visually-hidden">(Uhrzeit)</span></label>
<input name="k_von" id="k_von" value="<?php echo htmlspecialchars($k_von); ?>"/>
Uhr
</fieldset>
„(Uhrzeit)“ gehört in die labels; kann aber visuell vesteckt werden:
.visually-hidden
{
position: absolute !important;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);
}
LLAP 🖖
Hallo Gunnar Bittersmann,
(Bekommt die nächste Version des CForums einen brauchbaren Syntaxhighlighter spendiert, @Christian Kruse?)
Du kannst ja schon mal nach geeigneten Ausschau halten.
Bis demnächst
Matthias
Hallo Gunnar,
(Bekommt die nächste Version des CForums einen brauchbaren Syntaxhighlighter spendiert, @Christian Kruse?)
Pygments ist schon ziemlich state of the art.
LG,
CK
Tach!
(Bekommt die nächste Version des CForums einen brauchbaren Syntaxhighlighter spendiert, @Christian Kruse?)
Wenn du PHP-Code als HTML auszeichnest, ist das nicht unbedingt ein Fehler des Syntaxhighlighters.
dedlfix.
Hallo dedlfix,
(Bekommt die nächste Version des CForums einen brauchbaren Syntaxhighlighter spendiert, @Christian Kruse?)
Wenn du PHP-Code als HTML auszeichnest, ist das nicht unbedingt ein Fehler des Syntaxhighlighters.
Anders herum wird es auch nicht besser 😉 nein, ich finde auch, dass der da kaputt ist. Gibt nur halt auch nichts besseres. Die sind alle irgendwo kaputt.
LG,
CK
Tach!
Wenn du PHP-Code als HTML auszeichnest, ist das nicht unbedingt ein Fehler des Syntaxhighlighters.
Anders herum wird es auch nicht besser 😉 nein, ich finde auch, dass der da kaputt ist. Gibt nur halt auch nichts besseres. Die sind alle irgendwo kaputt.
HTML:
<fieldset>
<legend>Ganztags</legend>
<label>
<input name="k_ganztags" type="radio" value="0"
<?php if ($k_ganztags == '1'): ?>
checked=""
<?php endif; ?>
/>
<span>Ja</span>
</label>
<label>
<input name="k_ganztags" type="radio" value="1"
<?php if ($k_ganztags == '0'): ?>
checked=""
<?php endif; ?>
/>
<span>Nein</span>
</label>
</fieldset>
PHP:
<fieldset>
<legend>Ganztags</legend>
<label>
<input name="k_ganztags" type="radio" value="0"
<?php if ($k_ganztags == '1'): ?>
checked=""
<?php endif; ?>
>
<span>Ja</span>
</label>
<label>
<input name="k_ganztags" type="radio" value="1"
<?php if ($k_ganztags == '0'): ?>
checked=""
<?php endif; ?>
>
<span>Nein</span>
</label>
</fieldset>
Also ich finde schon, dass es besser ist. Aber nicht perfekt. Ab der PHP-Einfügung gibts Probleme. Zumindest die roten Stellen sind weg. Dass der Rest ein paar Macken hat, finde ich weniger tragisch als das Ergebnis bei falscher Auszeichnung.
dedlfix.