JS auf Elemete in Tabellenzeile zugreifen
der henry
- javascript
0 Tabellenkalk
0
Rolf B
Hallo,
ich erzeuge mit PHP eine dynamische Tabelle. Anzahl der Zeilen, je nach Records in der Datenbank (überschaubar .. 1-10 Zeilen). Anbei die Tabelle, stark reduziert ...
<table id="plclist">
<tr>
<th>PLC-Name</th><th>IP</th>
</tr>
<tr>
<td><input class="plcname" type="text" id="plcname" value=T1></td>
<td><input class="ip" type="text" id="ip" value=192.168.10.11></td>
</tr>
<tr>
<td><input class="plcname" type="text" id="plcname" value=T2></td>
<td><input class="ip" type="text" id="ip" value=192.168.10.11></td>
</tr>
....
Jetzt möchte ich mit JS beim speichern (Button speichern wird gedrückt) die Tabelle auslesen, per json an ein weiteres PHP Script senden, das die Daten in die Datenbank schreibt.
Aktuell bin ich soweit ...
const table = document.getElementById('plclist')
let json_data = [];
for (let i = 1; i < table.rows.length; i++)
{
console.log(table.rows[i]);
.....
Wie kann ich jetzt über die table.rows[i] gezielt den value der id="plcname" auslesen.
document.getElementById('plcname').firstChild.nodeValue
ist mir bei einem statischen Element mit eindeutiger id bekannt, aber die Kombination per Schleife die Tabelle auslesen .... da hapert es gewaltig 🙄
Vielen Dank !!!
Hallo,
document.getElementById('plcname').firstChild.nodeValueist mir bei einem statischen Element mit eindeutiger id bekannt, aber die Kombination per Schleife die Tabelle auslesen .... da hapert es gewaltig 🙄
Der Funktionsname hilft beim Erkennen des Fehlers: getElementById holt genau ein Element (singular), denn Ids müssen eindeutig sein. Du musst auf die Klasse plcname zugreifen und deine Tabelle ohne ids aufbauen
Gruß
Kalk
Hallo Henry,
denk dran, dass input-Elemente ein Label brauchen. In einer Tabelle ist das lästig, aber du kannst eine thead-Zeile mit den Labels machen und von den inputs mit aria-labelledby darauf verweisen.
Aber warum willst Du über JSON senden? Musst Du die Datenfelder noch vorverarbeiten?
Wenn nicht, nimm den Standardmechanismus von Browser und PHP.
new FormData(event.sender) ein FormData-Objekt und sende es per Ajax-POST an PHP. PHP sollte damit direkt umgehen können, als hättest Du das Form selbst gepostet, d.h. du findest die Daten in $_POST[].Das habe ich jetzt nicht ausprobiert, aber ich meine, so klappt das.
Rolf
Hallo,
das hörte sich so gut an, das ich es gleich getestet habe.
Ein Beispiel habe ich angepasst und erweitert.
document.addEventListener('DOMContentLoaded', function()
{
const form = document.getElementById("Formular");
form.addEventListener('submit', function(event) {
event.preventDefault(); // Verhindert das Standard-Formular-Absenden
const formData = new FormData(form);
fetch("writeplclist.php", {
method: "POST",
body: formData // Der gesamte Formularinhalt wird gesendet
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));
});
});
Am PHP "plclist.php" nur zu Testzwecken ...
<?php
if (isset($_POST[])) {
$post_data = file_get_contents('php://input');
echo "<div> POST BODY <br>".$post_data."</div>";
}
?>
Es kommt ein "HTTP/1 500 Internal Server Error 23ms"
Die Anfrage (es sind natürlich mehr Felder in der form) im Debugger von Firefox sieht so aus ..
Content-Disposition: form-data; name="plcname[]"
T1
...... usw.
Ich bin mir jetzt nicht sicher, ich vermute aber das JS sendet, nur die Rückantwort von PHP gefällt Ihm nicht.
Hat jemand eine Idee, vielen Dank !!
Hi,
<?php if (isset($_POST[])) { $post_data = file_get_contents('php://input');
einerseits guckst Du auf $_POST (also auf das Array, in dem sich der Body des Requests wiederfinden sollte bei 'formdata'), andererseits willst Du den input direkt selbst lesen (der dürfte ja schon weg sein, weil er in $_POST gelandet ist)?
Paßt irgendwie nicht zusammen …
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
genau. Darum schrieb ich ja: verarbeiten wie einen normalen POST. Und nicht wie einen JSON-Upload.
Rolf
Hi,
Es kommt ein "HTTP/1 500 Internal Server Error 23ms" Ich bin mir jetzt nicht sicher, ich vermute aber das JS sendet, nur die Rückantwort von PHP gefällt Ihm nicht.
nein, der Internal Server Error entsteht auf dem Server (daher ja Internal Server Error).
Ein Blick ins Error-Log des Servers könnte helfen.
cu,
Andreas a/k/a MudGuard
Hallo
Am PHP "plclist.php" nur zu Testzwecken ...
<?php if (isset($_POST[])) { $post_data = file_get_contents('php://input'); echo "<div> POST BODY <br>".$post_data."</div>"; } ?>Es kommt ein "HTTP/1 500 Internal Server Error 23ms"
Die Fehlermeldung kommt, wie MudGuard schon schrieb, vom Server. Er wird von einem Syntax-Fehler im PHP-Skript ausgelöst. Wenn der Code-Schnipsel, den du zeigst, das ganze Skript ist, dürfte es sich um die Formulierung der Bedingung if (isset($_POST[])) handeln. Die eckigen Klammern gehören da definitiv nicht hin. Korrekt ist if (isset($_POST)).
Ein weiterer Fehler ist, dass du im JavaScript-Skript ansagst, dass die Rückmeldung JSON anliefert (.then(response => response.json())), aber im PHP-Skript einen HTML-Schnipsel erzeugst. Das sollte, wenn das PHP-Skript eine nicht-HTTP-Fehler-behaftete Antwort zurückliefert, einen JS-Fehler auslösen, den du in der Browserkonsole „bewundern“ können wirst.
Tschö, Auge
Hallo Auge,
dürfte es sich um die Formulierung der Bedingung if (isset($_POST[])) handeln. Die eckigen Klammern gehören da definitiv nicht hin. Korrekt ist if (isset($_POST)).
Jein.
isset($_POST[]) ist definitiv falsch:
Fatal error: Cannot use [] for reading in ***.php on line 2
Hingegen ist isset($_POST) zwar syntaktisch richtig, aber nicht zielführend und deswegen auch nicht korrekt. Denn $_POST ist immer gesetzt. Eine isset-Abfrage im Zusammenhang mit $_POST muss auf einen konkreten Eintrag in $_POST gerichtet sein, um zu prüfen, ob ein Wert mit diesem Namen übergeben wurde.
Wenn also bspw. im HTML ein <input type="text" name="foo"> steht, dann kannst Du mit isset($_POST["foo"]) prüfen, ob das Feld tatsächlich übertragen wird. Das ist eine Basisaufgabe für jedes Formular, weil man keiner Eingabe vertrauen darf.
Und bei Checkboxen ist es notwendig, um zu erkennen, ob die Checkbox markiert wurde oder nicht. Es sei denn, man weicht auf Patterns wie ein vorgeschaltetes hidden input mit gleichem Namen aus…
Rolf
Hallo
Jein.
isset($_POST[])ist definitiv falsch:Fatal error: Cannot use [] for reading in ***.php on line 2Hingegen ist
isset($_POST)zwar syntaktisch richtig, aber nicht zielführend und deswegen auch nicht korrekt.
Ich habe, vom gezeigten Testcode ausgehend, angenommen[1], dass später, also unter Produktionsbedingungen, mit isset($_POST) nur der Eingang in die Verarbeitung gewählt wird, um dann die mögliche Felder einzeln zu prüfen.
Denn $_POST ist immer gesetzt.
Auch dann, wenn keine Daten mit POST übertragen werden? <rumkram /><ausprobier />: Nein Ja[2].
Eine isset-Abfrage im Zusammenhang mit $_POST muss auf einen konkreten Eintrag in $_POST gerichtet sein, um zu prüfen, ob ein Wert mit diesem Namen übergeben wurde. Wenn also bspw. im HTML ein <input type="text" name="foo"> steht, dann kannst Du mit isset($_POST["foo"]) prüfen, ob das Feld tatsächlich übertragen wird.
Wenn man einen konkreten Wert zu verarbeiten wünscht, stimmt die Aussage natürlich. Ich würde halt vermeiden wollen, in die Verzweigungen der Prüfungen einzusteigen, wenn überhaupt keine Daten angeliefert wurden. Deshalb ein umschließendes isset($_POST).
if (isset($_POST)) {
if (isset($_POST['wert1'])) {
// prüfen, verarbeiten, speichern, was auch immer
}
// und so weiter
}
Und bei Checkboxen ist es notwendig, um zu erkennen, ob die Checkbox markiert wurde oder nicht. Es sei denn, man weicht auf Patterns wie ein vorgeschaltetes hidden input mit gleichem Namen aus…
Ich habe mir tatsächlich angewöhnt, mit einem Hidden-Input einen Standardwert vorzudefinieren, der übertragen wird, wenn kein anderer Wert ausgewählt wurde. Validieren muss ich den Wert sowieso, aber er ist zuverlässig vorhanden. Wenn nicht, kann ich von einer grundsätzlich invaliden Eingabe ausgehen.
Tschö, Auge
Hallo Auge,
Ich würde halt vermeiden wollen, in die Verzweigungen der Prüfungen einzusteigen, wenn überhaupt keine Daten angeliefert wurden.
Das ist ein guter Plan.
Deshalb ein umschließendes isset($_POST).
Das hast Du nicht mit editiert?
$_POST ist immer gesetzt, wie Du gemerkt hast. Das genutzte HTTP Verb (was außer GET und POST auch ein PUT, DELETE, HEAD oder mehr sein kann) erhält man gemäß CGI-Standard mit $_SERVER['REQUEST_METHOD'].
Ich habe mir tatsächlich angewöhnt, mit einem Hidden-Input einen Standardwert vorzudefinieren,
Okay... ich bin kein PHP Profi, deswegen habe ich mich nicht getraut, das als good practice vorzustellen.
Man könnte ja auch das Form so generieren, dass man in einer Wiederholgruppen die Feldnamen nicht mit name="feldXY[]" benennt, sondern beim Generieren einen Zeilenzähler mitlaufen lässt und ihn pro Zeile mit ausgibt, als name="feld[47]". Dann ist der Zeilenzusammenhang sicher gewahrt.
Bei Einzelcheckboxen reicht meiner Meinung nach ein isset($_POST['cbFoo']), oder bei Radiogruppen ganz modern:
$fooSelection = $_POST['rbFoo'] ?? 'nothing';
Denn der ?? Operator beinhaltet ein isset().
Rolf
Hallo
Ich würde halt vermeiden wollen, in die Verzweigungen der Prüfungen einzusteigen, wenn überhaupt keine Daten angeliefert wurden.
Das ist ein guter Plan.
Deshalb ein umschließendes isset($_POST).
Das hast Du nicht mit editiert?
Öööhhhm, … nein. 🤦♂️
Jaja, groß erklären und dann im umherkopierten Code den Fehler nicht korrigieren. So issa. Also nochmal: „ein umschließendes !empty($_POST)“.
Ich habe mir tatsächlich angewöhnt, mit einem Hidden-Input einen Standardwert vorzudefinieren,
Okay... ich bin kein PHP Profi, deswegen habe ich mich nicht getraut, das als good practice vorzustellen.
Das war auch nur „my practice“. Funktioniert halt.
$fooSelection = $_POST['rbFoo'] ?? 'nothing';Denn der ?? Operator beinhaltet ein isset().
Oh, der ist schon seit PHP 7 verfügbar und gänzlich an mir vorbei gegangen. Beruflich nur noch selten zu programmieren, lässt mich offensichtlich zu viel verpassen. 😒
Tschö, Auge
Hallo,
euch allen vielen Dank !!
... wird bei mir langsam 😉