1UnitedPower: input oder button für submit-Elemente?

Beitrag lesen

Hakuna matata!

Ferner kann auf diese Weise der wechselseitige Ausschluss der Optionen schon bei der Übermittlung der Daten sichergestellt werden. Wenn man mehrere Submit-Buttons mit unterschiedlichen Namen auszeichnet ist das nicht möglich. Der Server müsste immer auch den Fall prüfen, was ist wenn zwei Optionen gesetzt sind, die eigentich nicht beide gleichzeitig aktiv sein sollten.

Hier hast du mich verloren.
Wenn der User einen Button anklickt, sollte nur einer am Server ankommen, ok.
Wird der Request beispielsweise von einem Skript abgeschickt oder manipuliert man sonst irgendwie die Parameter, kann man mehrere Submit-Buttons simulieren.
Das ist aber bei beiden Varianten möglich.
also action=Abbrechen&action=Speichen ist genauso möglich wie submit.cancel=1&submit.save=1

In jedem Fall muss geprüft werden. Bzw. der Server nimmt einfach einen von beiden.
Die zugehörigen Parameter müssen ja in jedem Fall geprüft werden.

Damit hast du natürlich recht. Defakto muss der PHP-Programmierer sich im ersten Fall aber nicht selbst darum kümmern, weil nur ein Wert im $_GET bzw. $_POST-Array landet. In anderen Serverumgebungen sieht das eventuell anders aus.

Eine Auswertung des Wertes zu einem immer gleichen Schlüssel kann zudem in vielen Fällen generisch gestaltet sein. Sollte irgendwann ein dritter Submit-Button (oder eine dritte Radiobox) hinzukommen, muss kein serverseitiger Code geschrieben werden, der die Formulardaten auf einen neuen Schlüssel überprüft, evtl. muss sogar gar kein neuer Code geschrieben werden.

Verstehe ich auch nicht. Wenn ein neuer Submitbutton hinzukommt, ist der entweder nur zur
Deko oder er hat eine bestimmte Funktion.
In beiden Varianten kann ich ihn auswerten und muss dafür Code anpassen oder eben nicht.

Man kann sich das einem Bestellformular gut vorstellen: Beim Checkout-Vorgang kann der Kunde wählen, mit welcher Bezahlmethode er den Kauf abschließen möchte, es gibt entsprechende Buttons für "Überweisung" und "Lastschrift". Die könnten so aussehen:

<button name="payment_method" value="assignment">Überweisung</button>  
<button name="payment_method" value="debit">Lastschrift</button>

Irgendwo im Backend-Code, wird es eine Routine geben, die den Wert des Buttons ausliest und für die Buchhaltung in eine Datenbank einträgt.

$checkout->bindValue(':payment_method', $_POST['payment_method']);

Eine Alternative wäre:

<button name="assignment">Überweisung</button>  
<button name="debit">Lastschrift</button>

Im Backend-Code, wird es irgendwo eine Fallunterscheidung geben:

if ( isset( $_POST['assignment'] ) ) {  
   $checkout->bindValue(':payment_method', 'assignment');  
} elseif ( isset( $_POST['debit'] ) {  
   $checkout->bindValue(':payment_method', 'debit');  
}  
  
$checkout->bindValue(':payment_method', 1);

Wenn irgendwann Paypal als neue Zahlungsart eingeführt wird, dann würde es im ersten Fall reichen, nur den neuen Button für Paypal einzufügen, der Backend-Code könnte unangetastet bleiben.

<button name="payment_method" value="paypal">Paypal</button>
Im zweiten Fall, müsste der Button hinzugefügt werden und der Servercode müsste angepasst werden:

<button name="paypal">Paypal</button>

if ( isset( $_POST['assignment'] ) ) {  
   $checkout->bindValue(':payment_method', 'assignment');  
} elseif ( isset( $_POST['debit'] ) {  
   $checkout->bindValue(':payment_method', 'debit');  
} elseif ( isset( $_POST['paypal'] ) {  
   $checkout->bindValue(':payment_method', 'paypal');  
}

Ich weiß, ich weiß das hab der Kuh schon sehr schön auf die Haut geschneidert und mit ein wenig biegen und brechen so herbeikonstruiert. Ein besseres Beispiel viel mir leider gerade nicht ein. Wenn du das Argument nicht gelten lassen willst, kann ich das auch verstehen. Das Totschalgargument pro value-Attribut auf den Submitbuttons ist für mich ohnehin, dass die Handhabung von Buttons somit analog zu Radiobuttons und Selectboxen erfolgt. Wenn man sich später entscheiden sollte, doch lieber Radiobuttons anstatt mehrerer Submitbuttons zu verwenden, ist das mit weniger Aufwand verbunden.

Im übrigen: die Auswertung kann, wenn man ein hübsches Framework hat, z.B. so gestaltet werden:
Alle submit-Buttons haben das Prefix "submit.".
Der Framework-Code sammelt die Buttons beim Einlesen der Parameter.

Das ginge selbstvertändlich auch, damit hättest du das Problem mit den Bezahlmethoden, das ich gerade versucht habe zu erklären, auch gelöst.

Mal umgekehrt gefragt, wo liegt denn der Vorteil darin, das value-Attribut zu vermeiden und nur auf das name-Attribut zu reagieren? Vorallem wenn man dann im Nachhinein versucht wieder Schlüssel/Werte-Paare nachzubstalen, sowie bei deiner Idee mit den gemeinsamen Prefixen?

--
“All right, then, I'll go to hell.” – Huck Finn