HTML/HTTP und der ewige K(r)ampf mit den Checkboxen
Geizhals » Forum » Programmierung » HTML/HTTP und der ewige K(r)ampf mit den Checkboxen (11 Beiträge, 158 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
HTML/HTTP und der ewige K(r)ampf mit den Checkboxen
07.01.2005, 15:06:06
Hallo Leute!

Wie man weiß, werden "ungecheckte" Checkboxen (bzw. deren Values), nicht an den Server übermittelt.
D.h. man weiß eigentlich nicht, ob eine Checkbox jemals angeboten wurde, oder ob sie bloß "uncheckt" wurde.

Zur Verdeutlichung - ein kleines Beispiel:
Ein Programm zeigt Rechnungen an.
Ein Filter-Formular bietet diverseste Felder für die Selektion an (Zeitraum, Kunde, Name, Betragsbereich etc).
Je nach gesetztem Filter, bekommt man einen bestimmten Auszug aller Rechnungen.
Bei jeder Rechnung befindet sich eine Checkbox, die angibt, ob die Rechnung noch "offen" oder bereits "bezahlt" ist.
Wird eine noch "offene" Rechnung als "bezahlt" gekennzeichnet (checked), ist alles klar. Das Formularfeld "e_InvoiceId_4711=true" wird an den Server übertragen.
Wird eine "bezahlte" Rechnung auf "offen" gesetzt (unchecked), erfährt der Server davon gar nichts. Es wäre ja großartig, wenn der HTTP-Request zumindest "e_InvoiceId_4711=" übertragen würde. Dem ist aber nicht so.

Man ist also gezwungen, mit Tricks zu arbeiten, damit der Server erfährt, daß es "e_Invoice_4711" im Formular zur Auswahl gab, dieses aber nicht gecheckt wurde.

Ein solcher Trick wäre, alle angeboteten Rechnungen, nochmals als hidden-Fields mitzuführen. Was natürlich die Request-Größe verdoppelt.

Ein anderer wäre, vor dem Submit, via Javascript, alle ungecheckten Ckeckboxen auf "gecheckt" zu stellen, und deren Value auf "False" zu setzen.
Was natürlich nur noch mit aktivem Javascript funktioniert.

Ein gänzlich andere Methode ist die, Serverseitig sich die übertragenen Felder via Sessions zu merken und darauf zu referenzieren.
Was (zumindest an meiner) Ideologie verbeigeht, daß HTTP-Sessions völlig autonom sein müssen.

Kennt jemand von Euch vielleicht einen "Schmäh", der weniger "ja aber" mit sich bringt? ;-)

lg
Ingenico

Antworten PM Übersicht Chronologisch
 
Melden nicht möglich
.
Re: HTML/HTTP und der ewige K(r)ampf mit den Checkboxen
08.01.2005, 16:52:17
Ich hatte diese Problemstellung auch schon mal.

Mein problem war, dass diese Checkboxen im Formular dynamisch generiert wurden, und der Name jeder Checkbox dadurch natürlich nix statisch ist, und man weiß beim Skript dass die Formulareingaben empfängt nicht, ob eine checkbox einfach nicht angehakt wurde, oder überhaupt nicht existiert hat (die selbe Problemstellung wie bei dir).

Ich habe das folgendermaßen gelöst (PHP):
Die Checkboxen im Eingabeformular werden ja nach einem bestimmten *TRÖT*us erstellt. Nun musst du den selben *TRÖT*us verwenden, um beim Empfangenden Skript abzufragen, ob die Variable gesetzt ist, oder nicht.

Hier ein Beispiel, eine for Schleife rennt durch, und generiert verschiedene Checkboxen (sinnlos, aber sollte verständlich sein):

formular.php

for($i=1; $i<=5; $i++)
{
    echo "%lt;input type=\"checkbox\" name=\"bestellung".$i."\" /> Bestellung".$i." \n";
}

Das Formular sieht dann in etwa so aus (HTML):

[formular kopf hier]
<input type="checkbox" name="bestellung1" /> Bestellung1
<input type="checkbox" name="bestellung2" /> Bestellung2
<input type="checkbox" name="bestellung3" /> Bestellung3
<input type="checkbox" name="bestellung4" /> Bestellung4
<input type="checkbox" name="bestellung5" /> Bestellung5
[formular ende]


Und so siehts jetzt beim Empfangenden Skript aus:
auswertung.php

for($i=1; $i<=5; $i++)
{
    // Schleife Läuft 5 mal durch, auf die selbe weise wie im Formular
    if(isset($_POST['bestellung'.$i]))
    {
        //Die Variable bestellungX existiert -> Checkbox angehakt
    }
    else
    {
        // Die Checkbox bestellungX hat im vorherigen Formular zwar existiert, aber ist _nicht_ angehakt
    }
}


So, ich hoffe das ist einigermaßen verständlich.
Kurz gesagt: Angenommen du erstellst in einer Schleife das Formular, dann musst du die selbe Schleife beim Empfänger-Skript durchlaufen lassen, nur eben mit dem Unterschied, dass du das Formular nicht generierst, sondern abfragst ob die Variable gesetzt ist.

Alles klar? ;)
--


DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.


Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
..
Re(2): HTML/HTTP und der ewige K(r)ampf mit den Checkboxen
09.01.2005, 18:48:05
Hallo Dr. Watson!

Zunächst, Danke fürs mitdenken ;-)

Ich habe das folgendermaßen gelöst (PHP):
Die Checkboxen im Eingabeformular werden ja nach einem bestimmten *TRÖT*us
erstellt. Nun musst du den selben *TRÖT*us verwenden, um beim Empfangenden
Skript abzufragen, ob die Variable gesetzt ist, oder nicht.


Bei Feldern, die mit einer Logik, oder als Serie gekennzeichnet werden können, ist das sicherlich ein Lösung.

Wenn die Felder aber mit Schlüsseln aus der DB referenzieren müssen, hat man keine Logik mehr.
Das Feld "e_InvoiceId_4711" referenziert mit der Rechnung Nr. 4711, die eher "zufällig" auf Grund der letzten Selektion übertragen wurde.
Was ich immer vermeiden möchte ist, daß der Server sich Referenzen des letzen Response merken muß (also Sessions).
Ein Request muß - meiner Meinung nach - in sich so Vollständig sein, daß er ohne jegliche Informationen über seine "Herkunft" verarbeitet werden kann.

Würde ich bei jeder generierten Seite, die Felder und deren Values als Session zusammenfassen und diese in der DB abspeichern, könnte ich mit Hilfe der zurückgelieferten SessionKennung die fehlenden Checkboxen ermitteln und diese als "uncheckt" akzeptieren.
Sehr viele Web-Anwendungen arbeiten auch nach einem solchen oder ähnlichen Prinzip.

Der Nachteil dabei ist aber, daß bei jedem Request Schreibzugriffe auf der DB erfolgen.
Weiters muß man sich darum kümmern, daß nach einer gewissen Zeit die unbenutzten Sessions wieder ausgemistet werden.
Man muß auch ständig entscheiden, ob eine Session mehrmals, oder nur einmal verwendet werden darf (History-Back und nochmals submitten).
Und man nimmt sich die Möglichkeit, Transaktionen zu verarbeiten, die man selber gar nicht "ausgeliefert" hat.

Ich schätze, es wird außer dem Mitführen der Referenzdaten via "hidden-Fields" nicht viele brauchbaren Methoden geben.

lg
Ingenico

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung