nicht angemeldet MB
Matthias Apsel
MB
dedlfix
Rolf B
Rolf B
moin,
…ist das schon einmal behandelt worden und mir kam da ein einfall wie ich HTML-Formulare für administrative Funktionen verstecken kann, sodass es - finde ich - optisch eleganter aussieht und einfacher zu handhaben ist.
Gunnar Bittersmann<table>
<tr>
<th>
<form method="post" action="">
<input type="hidden" name="foo[open]">
<input value="open" type="submit">
</form>
<form method="post" action="">
<input type="hidden" name="foo[delete]">
<input value="delete" type="submit">
</form>
</th>
<td>
<!-- Foo Datensatz-->
</td>
</tr>
<!-- n Datensätze-->
</table>
…allerdings müsste in der Tabelle n Datensätze auch (n × 2) Formulare geben anstatt "OldSchool" Formular wie hier…
<form method="post" action="">
<table>
<tr>
<th>
<input type="radio" name="user" id="foo[open]" value="open">
<input type="radio" name="user" id="foo[delete]" value="delete">
</th>
<td>
<!-- Foo Datensatz-->
</td>
</tr>
<!-- n Datensätze -->
<tr>
<input type="submit">
</tr>
</table>
</form>
lgmb
Hallo MB,
ich verstehe nicht, was du damit sagen möchtest. Da sind auch keine versteckten Formulare. Die Verwendung von Tabellen für solche Formulare ist zumindest grenzwertig, aber ganz sicher sind die Formualare keine (noch dazu die einzige) Überschrift. Statt input type="submit" könntest du besser button verwenden.
Bis demnächst
Matthias
ich verstehe nicht, was du damit sagen möchtest. Da sind auch keine versteckten Formulare. Die Verwendung von Tabellen für solche Formulare ist zumindest grenzwertig, aber ganz sicher sind die Formualare keine (noch dazu die einzige) Überschrift. Statt
input type="submit"könntest du besserbuttonverwenden.
Ein Versuch einer Interpretation Deiner Antwort: Die Verwendung von Tabellen für keine versteckten Formulare ist grenzwertig. Formulare sind keine Überschrift und für keine versteckten Formulare die keine Überschrift sind könnte man statt input type submit besser button verwenden. WTF++
Hallo pl,
Ein Versuch einer Interpretation Deiner Antwort:
Du solltest dringend deine Parameterkontrollstruktur überprüfen.
Bis demnächst
Matthias
Tach!
ich verstehe nicht, was du damit sagen möchtest. Da sind auch keine versteckten Formulare. Die Verwendung von Tabellen für solche Formulare ist zumindest grenzwertig, aber ganz sicher sind die Formualare keine (noch dazu die einzige) Überschrift. Statt
input type="submit"könntest du besserbuttonverwenden.Ein Versuch einer Interpretation Deiner Antwort: Die Verwendung von Tabellen für keine versteckten Formulare ist grenzwertig.
Die Tabelle besteht aus Headerzellen th und Datenzellen td. Es gibt in HTML keine anderen Zelltypen, aber Headerzellen sind da, um die Überschrift einer Spalte oder Zeile zu kennzeichnen. Aktionselemente sind keine Überschrift und sollten stattdessen in einer td zu liegen kommen.
Falls man überhaupt Tabellen als das geeignete Auszeichnungselement ansieht. In dem Fall sieht es mir jedoch danach aus, dass Datensätze angezeigt werden sollen. Das ist durchaus ein passender Anwendungsfall für Tabellen. Es sieht mir eher danach aus, als ob Matthias den Awendungsfall nicht richtig verstanden hat, was er ja auch mit seinem ersten Satz eingeräumt hat.
Formulare sind keine Überschrift und für keine versteckten Formulare die keine Überschrift sind könnte man statt input type submit besser button verwenden.
Nicht alles, was nacheinander geschrieben steht, baut auch kausal aufeinander auf. Die Button-statt-input-Empfehlung war ein allgemeiner Zusatz ohne Bezug auf die Tabelle oder das Formular.
dedlfix.
Abstrakt geht es bei Webanwendungen immer darum, wie man den Transportlayer so transparent wie möglich macht. Und zwar so, daß der Anwender eine Webanwendung genauso benutzt wie eine Desktopanwendung, also da keinen Unterschied findet.
Das handwerkliche Geschick besteht also darin, nicht nur Daten sondern die ganze Programmierlogik über HTTP zu schleifen.
MFG
allerdings müsste in der Tabelle n Datensätze auch (n × 2) Formulare geben
Was ja auch nicht unbedingt sinnvoll ist. Die Lösung heißt, den richtigen Umgang mit Schlüsselparametern lernen. Z.b. denkst Du Dir eine Spalte aus und setzt dort einen Parameter, etwa die Spalte ID, da setzt Du edit=1, edit=2 usw.
Bei einem Klick auf den Link mit edit=1 holst Du die Daten ab für den Datensatz mit der ID=1 und übernimmst diese Daten in ein Formular, so daß sie da bearbeitet werden können. Dieses Formular hat neben einem submit~update auch ein submit~delete, also mehrere Submit-Buttons mit verschiedenen Namen (Schlüsselparameter). Und ggf. auch einen Button mit dem Namen ~neu womit Du einen neuen Eintrag ezeugen kannst. Dieses Formular brauchst Du also nur einmal.
Denkbar ist aber auch, die Löschoption als Link zu setzen, z.B. delete=$id. Idealerweise macht man so etws über ein Template im Browser und serverseitig hat Du eine entsprechende Parameterkontrollstruktur über Deine Schlüsselparameter. MFG
Das Formular über die gesamte Tabelle hinweg hat aber Vorteile:
Bevor die Frage kommt: Ja. Dass ist ein "Schnellschrieb" für diesen Thread.
<!DOCTYPE html>
<html>
<head>
<title>Table - Multiform</title>
<style>
.jsOnly_inline { display:none; }
</style>
</head>
<body>
<form method="POST" action="https://home.fastix.org/phpinfo.php#_POST">
<button type="button" class="jsOnly_inline" name="selectAll" id="selectAll" value="1">Alle auswählen</button>
<button name="deleteSelected" id="deleteSelected" value="1">Gewählte Löschen</button>
<table>
<tr>
<td>
<input class="MultiSelectors" name="selector[1]" type="checkbox" id="selections[1">
</td>
<td>
Daten 1
</td>
<td>
<button name="edit" value="1">edit</button>
<button name="delete" value="1">delete</button>
</td>
</tr>
<tr>
<td>
<input class="MultiSelectors" name="selector[2]" type="checkbox" name="" id="selections[2]">
</td>
<td>
Daten 2
</td>
<td>
<button name="edit" value="2">edit</button>
<button name="delete" value="2">delete</button>
</td>
</tr>
</table>
</form>
<script>
var ar = document.getElementsByClassName('jsOnly_inline');
for (var i = 0; i < ar.length; i++) {
ar[i].style.display="inline"
}
function selectAllMultiSelectors() {
var ar = document.getElementsByClassName('MultiSelectors');
for (var i = 0; i < ar.length; i++) {
ar[i].checked=true;
}
var o = document.getElementById('selectAll');
o.removeEventListener("click", selectAllMultiSelectors, true );
o.addEventListener("click", unSelectAllMultiSelectors, true );
o.innerHTML="Auswahl aufheben";
}
function unSelectAllMultiSelectors() {
var ar = document.getElementsByClassName('MultiSelectors');
for (var i = 0; i < ar.length; i++) {
ar[i].checked=false;
}
var o = document.getElementById('selectAll');
o.removeEventListener("click", unSelectAllMultiSelectors, true );
o.addEventListener("click", selectAllMultiSelectors, true );
o.innerHTML="alle auswählen";
}
var o = document.getElementById('selectAll');
o.addEventListener("click", selectAllMultiSelectors, true );
</script>
</body>
</html>
Das Formular über die gesamte Tabelle hinweg hat aber Vorteile:
Der Nachteil ist: Nach einem Submit wird die ganze Seite neu geladen. Wenn Einträge weiter unten zu bearbeiten sind ist das äußerst unschön. MFG
Das Formular über die gesamte Tabelle hinweg hat aber Vorteile:
Der Nachteil ist: Nach einem Submit wird die ganze Seite neu geladen. Wenn Einträge weiter unten zu bearbeiten sind ist das äußerst unschön. MFG
Wie ich schon schrieb:
Bevor die Frage kommt: Ja. Dass ist ein "Schnellschrieb" für diesen Thread.
Verschönerungen, Tabellensortierer, Pagination, Aria-Attribute und weitere Funktionalitätserweiterungen durch "XmlHttpRequests" sind also selbst hinzuzufügen...
Verschönerungen, Tabellensortierer, Pagination, Aria-Attribute und Funktionalitätserweiterungen durch "XmlHttpRequests" sind also selbst hinzuzufügen...
Ja natürlich. Die Umsetzung: Programmierlogik über HTTP zu schleifen ist jedoch dieselbe. Auch über Ajax wird mit Schlüsselparametern gearbeitet.
Interessant übrigens sind modale Dialoge bei großen Tabellen. Oder ein ganzes modales Formular was beim Klick auf eine Zeile nach vorne geholt wird. MFG
Ja natürlich. Die Umsetzung: Programmierlogik über HTTP zu schleifen ist jedoch dieselbe.
Na und? So lange man Zeug nicht bei tencent in China hostet sollte das Benutzern kaum auffallen.
Demgegenüber steht der Mehraufwand dafür, dass man allerhand Zeug zweimal (mit und ohne JS) programmiert.
Demgegenüber steht der Mehraufwand dafür, dass man allerhand Zeug zweimal (mit und ohne JS) programmiert.
Nein. Serverseitig gibt es keinen Mehraufwand wenn clientseitig auf XHR erweitert wird. MFG
Bildanlage:
Für dieses Backend habe ich auf Submit komplett verzichtet wg. der Benutzerfreundlichkeit. Das ist nur mit XHR gebaut und dient der Verwaltung gemeinsamer Dokumente. Upload, Download, Edit, Delete und eine Mailfunktion womit man alle Benutzer anschreiben kann wenn es was Neues gibt.
Für dieses Backend habe ich auf Submit komplett verzichtet wg. der Benutzerfreundlichkeit.
Hat nicht funktioniert. Muss ich dazu etwa Java-Script aktivieren?
Demoversion, code: demo
Diese Anwendung wird zum Backend über ein einziges Attribut in der Konfiguration. Aber das Backend zeige ich hier nur als Screenshot.
Demgegenüber steht der Mehraufwand dafür, dass man allerhand Zeug zweimal (mit und ohne JS) programmiert.
Nein. Serverseitig gibt es keinen Mehraufwand wenn clientseitig auf XHR erweitert wird. MFG
Bildanlage:
Für dieses Backend habe ich auf Submit komplett verzichtet wg. der Benutzerfreundlichkeit. Das ist nur mit XHR gebaut und dient der Verwaltung gemeinsamer Dokumente. Upload, Download, Edit, Delete und eine Mailfunktion womit man alle Benutzer anschreiben kann wenn es was Neues gibt.
Wie der Screenshot zeigt, ist das Beschreibungsfeld gleich als <textandrea> ausgezeichnet. Alternative wäre contenteditable und konzeptionell ist da jede Zeile ein eigenständiges <form> mit 2 Buttons (delete, update). Fürs Download gibt es ein href mit der jeweiligen ID auf das Feld mit dem Original Dateinamen.
Schlüsselparameter: upload, mailsend, delete, update, checkall, download, getlist
Über den Parameter checkall wird bei einer Dateiauswahl fürs Upload für jede Datei geprüft ob sie bereits auf dem Server vorliegt. Wenn ja wird die Beschreibung angezeigt und die checkbox für Upload disabled, der Anwender entscheidet.
Parameter getlist fragt die Repository ab und sendet die Dateiliste welche über ein JS Template in den client gerendert wird. MFG
Tach!
Das Formular über die gesamte Tabelle hinweg hat aber Vorteile:
Der Nachteil ist: Nach einem Submit wird die ganze Seite neu geladen. Wenn Einträge weiter unten zu bearbeiten sind ist das äußerst unschön.
In einem Projekt, in dem kein Javascript eingesetzt werden soll, bleibt es sich gleich, ob der Submit im einzigen oder in einem vom vielen Forms ausgelöst wird.
dedlfix.
Tach!
In einem Projekt, in dem kein Javascript eingesetzt werden soll, bleibt es sich gleich, ob der Submit im einzigen oder in einem vom vielen Forms ausgelöst wird.
Der Unterschied ist der, daß bei einem Form je Datensatz nur ein Datensatz gesendet wird und bei einem Formular für alle Datensätze eben alles. MFG
Tach!
In einem Projekt, in dem kein Javascript eingesetzt werden soll, bleibt es sich gleich, ob der Submit im einzigen oder in einem vom vielen Forms ausgelöst wird.
Der Unterschied ist der, daß bei einem Form je Datensatz nur ein Datensatz gesendet wird und bei einem Formular für alle Datensätze eben alles.
Nicht bei Buttons, da werden nur die Daten des ausgelösten gesendet. Es ging jedoch in deinem Argument um die Antwortmenge, die stets das gesamte Dokument ist.
dedlfix.
Nicht bei Buttons, da werden nur die Daten des ausgelösten gesendet.
Ein Button submittet IMMER das gesamte Formular! Also alle Felder die mit name/value belegt sind. Das kann bei vielen Datensätzen ineffizient werden.
Es ging jedoch in deinem Argument um die Antwortmenge, die stets das gesamte Dokument ist.
Muss nicht, auch bei einem native submit gib es die Möglichkeit mit einem Status 204 No Content zu antworten. MFG
Tach!
Nicht bei Buttons, da werden nur die Daten des ausgelösten gesendet.
Ein Button submittet IMMER das gesamte Formular! Also alle Felder die mit name/value belegt sind. Das kann bei vielen Datensätzen ineffizient werden.
Es gibt Ausnahmen, wie disabled Felder. Und eben die Buttons. Wenn die Actions also nur aus Buttons bestehen und der Rest der Tabelle keine Input-Felder sind, ist das kein Problem. Editieren soll ja auf einer anderen Seite stattfinden.
Zudem hängt die Menge von der Größe der Tabelle ab. Wenn die so groß ist, dass es viele Eingabedaten zu übertragen gäbe, dann ist bereits die Tabelle ziemlich groß und die Antworten sind eine deutlich größere Datenmenge.
Muss nicht, auch bei einem native submit gib es die Möglichkeit mit einem Status 204 No Content zu antworten.
Unwahrscheinlich, wenn Daten bearbeitet werden sollen.
dedlfix.
Es gibt Ausnahmen, wie disabled Felder. Und eben die Buttons. Wenn die Actions also nur aus Buttons bestehen und der Rest der Tabelle keine Input-Felder sind, ist das kein Problem. Editieren soll ja auf einer anderen Seite stattfinden.
Dann brauchst Du auch kein Formular über die gesamte Tabelle! MFG
Tach!
Es gibt Ausnahmen, wie disabled Felder. Und eben die Buttons. Wenn die Actions also nur aus Buttons bestehen und der Rest der Tabelle keine Input-Felder sind, ist das kein Problem. Editieren soll ja auf einer anderen Seite stattfinden.
Dann brauchst Du auch kein Formular über die gesamte Tabelle!
Das war ja die Frage des OP. Die Alternative dazu ist ein Formular pro Zelle. Ohne gehts nicht, wenn/weil es ohne Javascript laufen soll.
dedlfix.
Dann brauchst Du auch kein Formular über die gesamte Tabelle!
Das war ja die Frage des OP.
Genau! Meine Antwort steht ja hier MFG
Hallo Jörg,
dein Vorschlag lässt an „Schönheit“ zu wünschen übrig. Es gibt Redundanzen und unnötige Komplexität.
Der selectAll Button wird nicht gepostet. Er braucht also weder name noch value. Das mag ein Relikt aus der Zeit sein, wo ein Select All noch einen HTTP Fallback hatte 😀
Die Sichtbarmachung von selectAll über eine Style-Zuweisung display:inline ist unschön. Du forcierst einen bestimmten Display-Stil. Bzw. wenn Du unterschiedliche Stile hast, musst Du mehrere Klassen nutzen. Oder data-Attribute. Oder oder. Sinnvoller wäre eine Klasse js-only, die ein display:none !important hinzufügt und die vom JavaScript einfach entfernt wird. Schwups, ist das Element da. Man könnte sogar am Body eine Klasse "no-js" setzen und im CSS den Selektor .no-js .js-only verwenden, um das display:none zu setzen. Und das Script muss dann nicht suchen, sondern kann einfach die no-js Klasse am Body entfernen. Das ist aber jetzt eine Korinthe...
Ob die MultiSelector Checkboxen eine ID brauchen, glaube ich nicht. Für den Postback ist das name-Attribut relevant. Im Zweifelsfall findet man sie mit querySelector. Eine ID mit eckigen Klammern drin macht die Handhabbarkeit ohnehin schwieriger. Paralleles Setzen von name und id scheint mir ohnehin ein Relikt aus der Zeit zu sein, wo es querySelector noch nicht gab (vor IE 8). Man kann bei Nutzung von Namenskonvention sogar auf eine Klasse verzichten, die die Zeilenselektoren identifiziert...
Das Umregistrieren des click-Handlers halte ich für sehr unbeholfen, vor allem weil beide Handler so ähnlich sind. Sowas macht man mit einem einzigen Handler, und um festzustellen, ob man Select All oder Clear Selection auszuführen hat, kann man ein data-Attribut oder eine Klasse am Button nutzen. Wenn man's mit einer Klasse macht, könnte man sogar per CSS den Text austauschen.
Mein HTML sähe so aus (mit ein paar Zeilenumbrüchen weniger um vertical space im Posting zu sparen):
<form method="POST" action="/handle_the_form.php">
<button type="button" class="js-only" id="selectAll"><span>Alles auswählen</span><span>Auswahl aufheben</span></button>
<button name="deleteSelected" value="1">Gewählte Löschen</button>
<table>
<tr>
<td><input type="checkbox" name="selector[1]"></td>
<td>Daten 1</td>
<td><button name="edit" value="1">edit</button><button name="delete" value="1">delete</button></td>
</tr>
<tr>
<td><input type="checkbox" name="selector[2]"></td>
<td>Daten 2</td>
<td><button name="edit" value="2">edit</button><button name="delete" value="2">delete</button></td>
</tr>
</table>
</form>
und das CSS dazu so:
.no-js .js-only { display: none !important; }
#selectAll.all-selected span:first-child { display: none; }
#selectAll:not(.all-selected) span:last-child { display: none; }
mit diesem JavaScript
if (!document.querySelector || !document.body.classList) return; /* Browser zu alt */
document.body.classList.remove("no-js");
var o = document.getElementById('selectAll');
o.addEventListener("click", handleMultiSelectClick);
function handleMultiSelectClick(e) {
var btn = locateButton(e.target);
var newCheckedState = !btn.classList.contains('all-selected');
var ar = document.querySelector("input[type=checkbox][name^=selector]");
for (var i = 0; i < ar.length; i++) {
ar[i].checked=newCheckedState;
}
btn.classList.toggle('all-selected');
btn.textContent = newCheckedState ? "Auswahl aufheben" : "Alles auswählen";
}
function locateButton(e) {
// Element.prototype.closest wäre einfacher, braucht aber Polyfill im IE
while (e && e.tagName != "BUTTON") e = e.parentElement;
return e;
}
Wenn man Browser vor IE10 unterstützen will, braucht's noch einen Polyfill oder eine alternative Implementierung für die classList Operationen. locateButton habe ich als Ersatz für closest('button') genommen. Statt dessen geht auch ein Polyfill für closest.
Rolf
@@Rolf B
Sinnvoller wäre eine Klasse js-only, die ein display:none !important hinzufügt und die vom JavaScript einfach entfernt wird. Schwups, ist das Element da. Man könnte sogar am Body eine Klasse "no-js" setzen und im CSS den Selektor
.no-js .js-onlyverwenden, um das display:none zu setzen. Und das Script muss dann nicht suchen, sondern kann einfach die no-js Klasse am Body entfernen.
Wenn es denn das Script gibt. Mitunter gibt es aber mehrere, die womöglich unabhängig voneinander geladen werden – oder eben nicht. Da sollte dann jedes Script seine eigene Klasse (bzw. sein eigenes data-Attribut) bekommen.
LLAP 🖖
Status:
Ich habe einen Button mit Hintergrundbild, kein Text - das aria-label sei "Aktion".
Vorhaben:
Ich will diesem Button (in der Variable o) mit JS einen anderen EventListener (Neue Aktion) verpassen. Das klappt. Es "klappt" auch das Folgende, ich weiß nur nicht, ob ich das Richtige mache.
Meine Frage lautet:
Ist
o.setAttribute('aria-label', 'Neue Aktion');
oder
o.setAttribute('aria-alert', 'Neue Aktion');
angebracht? Oder beides? Oder was anderes?
Hallo Jörg,
Was ist aria-alert, welche Spec definiert das? Ich finde es weder in WAI-ARIA 1.0 noch 1.1. Es gibt die alert-Rolle, die dazu führt, dass ein Screenreader aktiv wird wenn Du das Element einblendest.
Dein JavaScript hat nun noch weitere Kritikpunkte bekommen. Hast Du meinen Kommentar von 17:04 Uhr noch nicht entdeckt? Oder hältst Du ihn für Unsinn?
// Deins (ab IE 9 übrigens. getElementsByClassName gibt's im IE8 noch nicht)
function allSelected( className ) {
var flag = true;
var ar = document.getElementsByClassName( className );
for ( var i = 0; i < ar.length; i++) {
if ( false == ar[i].checked ) {
var flag = false;
i = 1 + ar.length;
}
}
return flag;
}
// Weniger umständlich
// (Ausstieg aus einer Schleife ist in kleinen Methoden durchaus legitim)
function allSelected( className ) {
var ar = document.getElementsByClassName( className );
for ( var i = 0; i < ar.length; i++) {
if ( !ar[i].checked ) return false;
}
return true;
}
// Kompakte Lösung (auch IE9, wegen :checked und :not() )
function allSelected( className ) {
return document.querySelector("."+className+":not(:checked)") == null
}
// Und eigentlich sollte man das nicht über's Dokument machen, sondern über den Container,
// der die Tabelle enthält
Zwei Klassen zu verwenden (Activated/notActivated) ist ebenfalls umständlich. Verwende nur eine, benutze :not(.activated) statt .notActivated.
Dass es unnötig umständlich ist, den Eventhandler umzuregistrieren, hatte ich vorher schon erwähnt.
Es ist ebenso umständlich, einen change Handler auf jede einzelne Checkbox zu legen. Registriere einen einzigen Change-Handler auf die Table und prüfe, ob das event.target ein input[type=checkbox].MultiSelectors ist. Entweder ausprogrammiert über tagName, type und classList, oder matches-Methode in Element.prototype (und einem kleinen Polyfill, weil die Methode in älteren Browsern matchesSelector heißt und ggf. Vendor-Präfixe hat)
Übrigens fände ich row-selector als Klassenname eine viel bessere Wahl als MultiSelectors. Aber das mag Geschmackssache sein.
Rolf
Sei Dir zunächst mal sicher, dass ich Deine Anmerkungen (auch die von Dedlfix sowie Gunnar) mindestens gelesen habe. Aber ich mache das mit der Tabelle nur als Überbrückungs-Experiment weil ich auf zwei Notebooks gerade 3 (virtuelle) Windows 2016-Server (1 x Domaincontroller, 1 x Member + PKI-Server, 1 x Member + Apache) und einen Windows-7 Client aufsetze — also recht ordentlich mit etwas beschäftigt bin was ich eigentlich "Wer, BITTE, macht denn SOWAS?" quittieren würde. Entsprechend groß ist der Aufwand mich in dieses Windows-Zeug hineinzudenken und mich also an Sachen zu erinnern, von denen ich jahrelang hoffte, diese straflos vergessen zu können. Und vieles davon ist wirklich "im tiefsten Keller" gelandet…
Genau am Mittwoch morgen werden diese Server (und das alte nebst ein wenig neuem Wissen) aus niedrigen (pekunären) Gründen dringend (Penunze!) benötigt.
Was jetzt die Adressierung und das Aufräumen des Codes angeht:
Das muss sowieso aufgeräumt werden. Aber da das ein Schnellschrieb ist habe ich die Planungsphase schlicht übersprungen, was sich natürlich rächt. So ist mir u.a. eingefallen, dass es in einem HTMl-Dokument durchaus auch mehrere solcher Formulare geben kann. Mein Zeug unterstützt das derzeit nicht- was ein sehr grober und vorrangig zu behebender Mangel ist. Außerdem steht (auch deshalb) noch die Kapselung in einer Klasse also Objekt(en) an. Folge: Ich muss den Kram ohnehin gewaltig umbauen. Wenn ich mich da ran setze werde ich Deine Hinweise beachten.
moin,
tut mir leid liebe Community: Ich hab vergessen zu sagen das nojs als voraussetzung gilt 😟.
ich wollte im ersten Beispiel versuchen in einer Tabelle (z.B. Users in dem Fall) aufzeigen, wie es möglich sein könnte, einfache Operationen (delete, open) durch zu führen. Es würden <input>-Buttons mit jeweiligem dazugehörigen umschließenden <form>'s existieren, vor der eigentlichen Anzeige des Users in der Tabellen Zeile.
<table>
<caption>Users</caption>
<thead>
<tr>
<th>Operation</th>
<td>User</td>
</tr>
</thead>
<tbody>
<tr> <!-- es folgt der erste user Manfred -->
<th> <!-- Es folgt Operationen Buttons für Manfred -->
<form ...>
<input type="hidden" ... >
<input type="submit" value="open">
</form>
<form ...>
<input type="hidden" ... >
<input type="submit" value="delete">
</form>
</th>
<td> <!-- Hier der User Manfred -->
Manfred
</td>
</tr>
<!-- es folgt der zweit User -->
</tbody>
</table>
Pro: einfacher. Kontra: Zuviele Formulare
Im zweiten Beispiel wollte ich eigentlich nur den "umständlichen" Bedien-Kontrast aufzeigen. Pro: Ein Formular. Kontra: umständlicher
Schlussendlich laute die Frage: "kann man das in diesem ersten Bespiel machen oder ist das ein absolutes NoGo?"
ich hoffe es wird klarer.
lgmb
Tja, entweder hast Du je Tabellenzeile ein Formular oder nur ein Formular ganz unten oder ganz oben. Nehmen wir mal an, Du hast ein Formular ganz unten. Dazu gehört ein href in jeder Zeile und wenn Du da draufklickst wird der jeweilige Rekord in das Formular geladen. Da kannst Du dann damit machen was Dir gefällt.
Hab ich Dir aber auch vorgestern schon geschrieben
ich hoffe es wird klarer.
ich auch.
Tach!
Du scheinst mir nach wie vor seinen ersten Satz und meine mehrfachen Hinweise zu missachten, dass er kein Javascript verwenden möchte.
dedlfix.
Tja, entweder hast Du je Tabellenzeile ein Formular oder nur ein Formular ganz unten oder ganz oben. Nehmen wir mal an, Du hast ein Formular ganz unten. Dazu gehört ein href in jeder Zeile und wenn Du da draufklickst wird der jeweilige Rekord in das Formular geladen. Da kannst Du dann damit machen was Dir gefällt.
Hab ich Dir aber auch vorgestern schon geschrieben
ich hoffe es wird klarer.
ich auch.
PS: Die Programmierlogik bildest Du auf Schlüsselparametern ab: edit (open), update, insert, delete.
Und Ja: Das geht alles ohne JavaScript!
Tach!
Tja, entweder hast Du je Tabellenzeile ein Formular oder nur ein Formular ganz unten oder ganz oben. Nehmen wir mal an, Du hast ein Formular ganz unten. Dazu gehört ein href in jeder Zeile und wenn Du da draufklickst wird der jeweilige Rekord in das Formular geladen.
Und Ja: Das geht alles ohne JavaScript!
Da kann ich dir grad nicht folgen. Wie bekommt man ein Formular abgesendet, dass sich außerhalb der Tabelle befindet, mit href-Attributen, die sich darinnen befinden? Und wie soll sich dann was in das Formular laden?
dedlfix.
Tja, entweder hast Du je Tabellenzeile ein Formular oder nur ein Formular ganz unten oder ganz oben. Nehmen wir mal an, Du hast ein Formular ganz unten. Dazu gehört ein href in jeder Zeile und wenn Du da draufklickst wird der jeweilige Rekord in das Formular geladen. Da kannst Du dann damit machen was Dir gefällt.
Hab ich Dir aber auch vorgestern schon geschrieben
ich hoffe es wird klarer.
ich auch.
PS: Die Programmierlogik bildest Du auf Schlüsselparametern ab: edit (open), update, insert, delete.
Und Ja: Das geht alles ohne JavaScript!
PS: Du kannst auch Anker setzen damit beim Klick auf einen Eintrag in der Liste/Tabelle der Browser zum Formular scrollt. Das href sieht dann so aus: ?edit=123#form wobei 123 die ID eines Rekords ist dessen Daten in das Formular kommen.
Unmgekehrt setzt Du einen Anker in das action Attribut: action="%url%#123" damit beim Absenden der Browser wieder in die Liste kommt.
MFG
Tja, entweder hast Du je Tabellenzeile ein Formular oder nur ein Formular ganz unten oder ganz oben. Nehmen wir mal an, Du hast ein Formular ganz unten. Dazu gehört ein href in jeder Zeile und wenn Du da draufklickst wird der jeweilige Rekord in das Formular geladen. Da kannst Du dann damit machen was Dir gefällt.
Hab ich Dir aber auch vorgestern schon geschrieben
ich hoffe es wird klarer.
ich auch.
Eine andere Möglichkeit: Du hast eine Tabelle/Liste und setzt ein href='%url%?open=123' auf jeden Eintrag (ID sei 123). Beim Klick darauf wird ganz einfach ein anderes Template geladen, nämlich das Template mit dem Formular und da stehen dann die Daten drin für update//delete. Nach dem Submit wird wieder das Template mit der Tabelle//Liste geladen.
Und mit einem Formular unter der Tabelle könntest Du einen neuen Eintrag erzeugen (insert).
Auch ohne JS gibt es mehrere Möglichkeiten.
Tach!
Im zweiten Beispiel wollte ich eigentlich nur den "umständlichen" Bedien-Kontrast aufzeigen. Pro: Ein Formular. Kontra: umständlicher
Wenn du von allen Zeilen und von mehreren Möglichkeiten pro Zeile letztlich nur eine einzelne Aktion ausführen möchtest, dann reicht auch ein Formular mit vielen eindeutig benannten (sprich Name-Value-Paaren) Submit-Buttons. Dann wird lediglich dieses eine Name-Value-Paar (zuzüglich eventueller weiterer Input-Felder in dem Formular) zum Server übertragen. Dort kannst du somit eindeutig erkennen, was gewünscht ist.
Wenn du zusätzlich noch Matthias' Hinweis beachtest, Button- statt Input-mit-Type-Submit-Elemente zu verwenden, bekommst du sowohl frei gestaltbare Name-Values als auch frei gestaltbare Beschriftung in einem Element hin.
Schlussendlich laute die Frage: "kann man das in diesem ersten Bespiel machen oder ist das ein absolutes NoGo?"
Kann man, muss man aber nicht.
dedlfix.
Tach!
Weitere Möglichkeiten sind, einfache Links zu nehmen und gar kein Formular. Die eigentliche Datenverarbeitung findet ja erst auf der Response-Seite statt. In der Tabelle musst du lediglich diese Response-Seite passend aufgerufen bekommen. Diese Methode eignet sich nicht für Aktionen, die sofort Daten ändern sollen, also beispielsweise Löschen ohne weitere Rückfrage. Besonders dann nicht, wenn die Seite öffentlich ist und Bots solchen Links folgen.
Außerdem neu in HTML5 ist das form-Attribut für Button- und Input-Elemente, mit denen man diese einem Formular explizit zuordnen kann, dass sich nicht umhüllend darum befinden muss. Damit kann das Form auch sonstwo stehen. Vorteile bringt das hier aber nicht weiter, denn statt lediglich einem umhüllenden Formular musst du nun form-Attribute in jeden Button setzen.
dedlfix.
moin,
Weitere Möglichkeiten sind, einfache Links zu nehmen und gar kein Formular. […] Diese Methode eignet sich nicht für Aktionen, die sofort Daten ändern sollen, also beispielsweise Löschen ohne weitere Rückfrage. Besonders dann nicht, wenn die Seite öffentlich ist und Bots solchen Links folgen.
Das es sich im konkreten Beispiel um eine User Tabelle handelt, ist es nicht gut wenn mn keine Formulare verwendet. Aber das hast du ja geschrieben.
Außerdem neu in HTML5 ist das form-Attribut für Button- und Input-Elemente, mit denen man diese einem Formular explizit zuordnen kann, dass sich nicht umhüllend darum befinden muss.
Wow, das wusste ich nicht! Danke für den Hinweis. aber ich verwende schon das umhüllende.
lgmb
Hallo MB,
ich fasse nochmal zusammen.
Die Lösung, die Jörg (Ursus) vorgeschlagen hat, stellt progressive enhancement dar. D.h. sie funktioniert auch ohne JavaScript, aber mit JavaScript funktioniert sie besser.
Deine "one form per row" Lösung ist ebenfalls machbar, und es ist auch kein Problem, in einer Tabellenzelle ein Form unterzubringen. Allerdings nicht als "one form per button", das ist unnötig. Ein Form pro Tabellenzelle reicht (bevor Du fragst: ein Form pro Row, also außerhalb von th oder td, ist falsches HTML und geht nicht). Das hidden input könnte man auch im action-Parameter unterbringen, niemand verbietet Query-Parameter in POST Requests. Beispielsweise so:
<tr id="4711-001-qxtt6">
<th>
<form method="post" action="/processform.php?id=4711-001-qxtt6">
<button type="submit" name="edit" value="1">Bearbeiten</button>
<button type="submit" name="delete" value="1">Löschen</button>
</form>
</th>
<td>...</td>
</tr>
Das ist nicht falsch, und der Browser wird deswegen auch nicht in die Knie gehen. Du musst nur verhindern, dass processform.php bei einer anderen Request-Methode als POST irgendwas tut ($_SERVER['REQUEST_METHOD'] == "POST"). Und type="submit" kann man beim Button auch weglassen, das ist der Default-Typ.
Oder so, mit hidden input statt Query Parameter:
<tr id="4711-001-qxtt6">
<th>
<form method="post" action="/processform.php">
<input type="hidden" name="id" value="4711-001-qxtt6">
<button name="edit" value="1">Bearbeiten</button>
<button name="delete" value="1">Löschen</button>
</form>
</th>
<td>...</td>
</tr>
oder mit einem großen Form - dann geht hidden input nicht und du musst den Value der Buttons nutzen. Deswegen <button> statt <input type="button">, weil sich im button-Element der value vom Text unterscheiden kann.
<form method="POST" action="/processform.php">
<table>
<tr id="4711-001-qxtt6">
<th>
<button name="edit" value="4711-001-qxtt6">Bearbeiten</button>
<button name="delete" value="4711-001-qxtt6">Löschen</button>
</th>
<td>...</td>
</tr>
</table>
</form>
Das ist aus reiner HTML Sicht alles gleichwertig. Solange es nur Buttons gibt, schickt das große Form genau ein Key-Value Paar an den Server.
Ohne JavaScript-Support würde jede dieser Aktionen einen Postback zum Server durchführen. Über die ID am tr Element kannst Du bei der Rückkehr aus dem Bearbeiten- oder Löschen-Dialog dafür sorgen, dass die gewünschte Zeile gleich wieder sichtbar ist (indem Du der URL ein #4711-001-qxtt6 hinzufügst)
Wenn JavaScript aktiv ist, machst Du - beispielsweise - alles mit Ajax. Und ja, dann programmierst Du doppelt. Einmal die enhanced version mit JS und einmal die basic version mit HTTP Postback. Je nach HTML sieht die JavaScript-Lösung etwas anders aus, aber bei geschickter Programmierung und Ausnutzung von Event-Bubbling ist der Programmieraufwand und Laufzeitaufwand für alle HTML Varianten gleich.
Rolf
Wenn JavaScript aktiv ist, machst Du - beispielsweise - alles mit Ajax. Und ja, dann programmierst Du doppelt.
Wenn man die Programmierlogik auf denselben Schlüsselparametern abbildet ergibt sich kein doppelter Aufwand. Hab ich aber auch schonmal geschrieben.
MFG
Hallo pl,
die Businesslogik, die entweder via Form POST oder Ajax-POST angestoßen wird, ist gleich. Ok. Aber die UI Steuerung findet einmal mittels JS gegen das DOM und einmal mit Serversprache gegen die HTTP-Nachricht statt, das ist ein anderes technisches Modell und (außer bei node.js) auch eine andere Programmiersprache.
Rolf
die Businesslogik, die entweder via Form POST oder Ajax-POST angestoßen wird, ist gleich.
Genau. Und die Daten sind auch dieselben.
Und wenn man es geschickt anstellt, bleiben auch die Responses gleich. Das Thema hatten wir hier ja sehr ausführlich vor nicht allzulanger Zeit.
Es ist nur so, daß PE nicht immer sinnvoll ist. MFG
@@pl
Es ist nur so, daß PE nicht immer sinnvoll ist.
Es ist nur so, daß PE nicht immer verstanden wird.
LLAP 🖖
Um das Thema nocheinmal aufzugreifen:
Es ist nur so, daß PE nicht immer sinnvoll ist.
Bei bestimmten Anwendungen lohnt es sich tatsächlich darüber nachzudenken ob man sie konventionell baut (native Submit) oder gleich komplett auf JS Basis. Anwendungen mit Fileupload konventionell programmiert sind für jeden Benutzer eine Zumutung! Abgesehen davon daß die moderne FileAPI Details ermöglicht die mit multipart/form-data gar nicht zu machen sind.
MFG
@@pl
Um das Thema nocheinmal aufzugreifen:
Es ist nur so, daß PE nicht immer sinnvoll ist.
Um das Thema nocheinmal aufzugreifen: Es ist so, dass der Gedanke, dass progressive enhancement nicht immer sinnvol wäre, sogut wie immer nicht sinnvoll ist.
Bei bestimmten Anwendungen lohnt es sich tatsächlich darüber nachzudenken ob man sie konventionell baut (native Submit) oder gleich komplett auf JS Basis. Anwendungen mit Fileupload konventionell programmiert sind für jeden Benutzer eine Zumutung! Abgesehen davon daß die moderne FileAPI Details ermöglicht die mit
multipart/form-datagar nicht zu machen sind.
Adam Silver widment in „Form Design Patterns“ ein ganzes Kapitel, wie man Upload Forms umsetzt – und zwar mit progressive enhancement. (Das achte, Seiten 314 bis 348.)
“Summary:
In this chapter we began by looking at the native file picker as the browser gives us quite a bit of power for free. However, we also looked at the various problems that crop up with multiple file uploads.
From there, we looked at various solutions that started with the persistent pload form, before enhancing the interface with a more ergonomic and inclusive drag-and-drop interface.”
(Hervorhebungen von mir.)
LLAP 🖖
Adam Silver widment in „Form Design Patterns“ ein ganzes Kapitel, wie man Upload Forms umsetzt – und zwar mit progressive enhancement.
Ein Upload herkömmlich programmiert: Solange ein Upload läuft ist aus der Sicht des Benutzers der Browser tot. Da gibt es nichts zum anreichern, tot ist tot. MFG