Debugging-Tipps

[Fabulit]

Hallo wehrte Glaskugel-Gemeinde,

folgende unzureichende Problembeschreibung bitte ich mit spekulativen Hinweisen zu versehen.

Gegeben ist eine durch PHP erstellte Tabelle, in der jede Zelle mit einem Input-Element bestückt ist. Die Daten stammen aus einer mySQL-Datenbank und werden anschließend auch wieder dorthin zurückgeschrieben. Um neue Datensätze hinzuzufügen, kann per JavaScript eine neue Zeile in die Tabelle eingefügt werden. Dieses Konstrukt habe ich erfolgreich in einer Testumgebung erstellt.

Nun implementiere ich den Code in einer größeren Anwendung und treffe auf folgende Schwierigkeit; die nachträglich erstellten Input-Felder werden nicht übertragen, d.h. sind nicht in $_POST auffindbar. Das PHP-Error-Reporting ist voll aufgedreht und trotzdem schweigsam. Und da ich von der Testumgebung weiß, dass meine Ansätze prinzipiell funktionieren, muss ich jetzt über Wechselwirkungen mit dem bestehenden System spekulieren. Einblick in Quellcodes des Systems kann/darf ich nicht geben.

Mir ist an dem bestehenden System aufgefallen, dass zwei Formulare in einer Datei verwendet werden. Kann es womöglich damit zusammenhängen? Oder hat jemand mal ähnliche Erfahrungen gemacht und kann mir daher einen Tipp geben? Ich bin etwas ratlos, wie ich jetzt zu debuggen habe.

Gruß Fabulit

[hotti]

Mir ist an dem bestehenden System aufgefallen, dass zwei Formulare in einer Datei verwendet werden. Kann es womöglich damit zusammenhängen?

Ja. Für einen erfolgreichen POST/Submit müssen das Input-Feld und der Submit-Button im gleichen Form sein und die action-Note muss stimmen. Stelle die Request-Method (Attribut: method='') vorübergehend auf 'GET', dann siehst Du bereits in der Adresszeile an welchen URI der Request geht.

[Fabulit]

Ja. Für einen erfolgreichen POST/Submit müssen das Input-Feld und der Submit-Button im gleichen Form sein...

Das war auch eine meiner ersten Vermutungen; allerdings werden alle input-Elemente meiner Tabelle übertragen, bis auf die nachträglich hinzugefügten. D. h. die Tabelle ist innerhalb der Form platziert (ebenso wie der Submit-Button). Ergo _muss_ die neu hinzugefügte Tabellenzeile sich ebenso innerhalb der Form befinden. Oder irre ich etwa?

Der Wechsel von POST zu GET liefert (richtigerweise) das gleiche (mangelhafte) Resultat, bringt also keine neuen Erkenntnisse.

Danke für den Tipp

Gruß Fabulit

[jobo]

Hallo,

dann hast du ein Javascript-Problem. Da solltest du mit Firebug mal schauen und dir u.u. einen kleinen Testcode schreiben, in dem du input-Felder hinzu fügst.

Gruß

jobo

[Fabulit]

dann hast du ein Javascript-Problem. Da solltest du mit Firebug mal schauen und dir u.u. einen kleinen Testcode schreiben, in dem du input-Felder hinzu fügst.

Hi Jobo,

in Firebug sieht alles wunderbar aus. Zuerst hatte ich die input-Elemente noch per innerHTML erstellt (welches auch funktioniert). Mittlerweile werden die input-Elemente nur noch vorbildlich per createElement ins DOM eingehängt. Und wie bereits im Ursprungs-Posting erwähnt; in einer Testumgebung hat mir das Modell keine Probleme bereitet.

Ich habe noch etwas entdeckt; laut Firebug endet das form-Element direkt* nach dem Submit-Button, welcher oben im Formular sitzt. Nur dann dürften (nach meinem Verständnis) gar keine Daten übertragen werden...

Gruß Fabulit

*Der Submit-Button befindet sich zusammen mit anderen Buttons in einem Fieldset. Mit Beendigung des Fieldsets wird laut Firebug auch die Form geschlossen.

[jobo]

Hallo,

dann hast du ein Javascript-Problem. Da solltest du mit Firebug mal schauen und dir u.u. einen kleinen Testcode schreiben, in dem du input-Felder hinzu fügst.

Hi Jobo,

in Firebug sieht alles wunderbar aus. Zuerst hatte ich die input-Elemente noch per innerHTML erstellt (welches auch funktioniert). Mittlerweile werden die input-Elemente nur noch vorbildlich per createElement ins DOM eingehängt.

http://forum.de.selfhtml.org/archiv/2010/3/t196541/#m1317007

http://developer.yahoo.com/yui/examples/connection/callback_customevents.html

innerHTML kann schön übersichtlich sein. Es nutzt die hervoragenden Browserfähigkeiten, html zu parsen.

Gruß

jobo

[Fabulit]

innerHTML kann schön übersichtlich sein. Es nutzt die hervoragenden Browserfähigkeiten, html zu parsen.

Für mich ist innerHTML die bequeme Möglichkeit Schreibarbeit zu sparen. Bringt aber halt andere Fallen mit sich, so dass ich während der Fehlersuche innerHTML sehr kritisch beäuge ;-)

Aber den Yahoo-Developler-Link werde ich mir mal in Ruhe zu Gemüte führen. Vielen Dank schon mal dafür.

Gruß Fabulit

[hotti]

Du möchtest spekulative Tipps.

Der Wechsel von POST zu GET liefert (richtigerweise) das gleiche (mangelhafte) Resultat, bringt also keine neuen Erkenntnisse.

Wenn zu sehen ist, dass alle Formularelemente übertragen werden (zu sehen in der Adresszeile beim GET), wird es nun Zeit, an das Backend zu gehen <= nicht spekulativer Tipp um dort die Fehlersuche fortzusetzen.

[Glaskugel]

Wenn zu sehen ist, dass alle Formularelemente übertragen werden (zu sehen in der Adresszeile beim GET), wird es nun Zeit, an das Backend zu gehen <= nicht spekulativer Tipp um dort die Fehlersuche fortzusetzen.

Hochspekulativ und falsch - der OP schrieb, dass die statisch eingesetzten Felder übertragen werden und die nachträglich per JS eingesetzten nicht. Das Problem liegt in der Invalididät der Maske, respektive der Einsetzung via JS.

Mein Tipp: Der Tagsoup-Parser biegt den (eigentlich kaputten) Originalform soweit wieder hin, dass er funktioniert. Der Ansatz für das AppendChild des OP basiert aber auf dem kaputten Form, also landen die neuen Felder irgendwo, aber nicht innerhalb des Forms.

[Fabulit]

Mein Tipp: Der Tagsoup-Parser biegt den (eigentlich kaputten) Originalform soweit wieder hin, dass er funktioniert. Der Ansatz für das AppendChild des OP basiert aber auf dem kaputten Form, also landen die neuen Felder irgendwo, aber nicht innerhalb des Forms.

Hui, das geht ja genau in die Richtung meiner Spekulationen. Das einzige Problem; der Validator kann keine Fehler feststellen. Ich hingegen stelle fest, dass das form-Element laut Firebug derart früh wieder geschlossen wird, dass gar keine Daten mehr übertragen werden sollten. Da hat der Tagsoup-Parser vielleicht verschlimm-bessert und ich kann nachträglich nichts ordentliches mehr damit anfangen?!

[dedlfix]

Hi!

[...] landen die neuen Felder irgendwo, aber nicht innerhalb des Forms.
Das einzige Problem; der Validator kann keine Fehler feststellen.

Der findet nur Fehler im ausgelieferten HTML-Code. Das was Javascript im DOM ändert, sieht er natürlich nicht mehr.

Ich hingegen stelle fest, dass das form-Element laut Firebug derart früh wieder geschlossen wird, dass gar keine Daten mehr übertragen werden sollten. Da hat der Tagsoup-Parser vielleicht verschlimm-bessert und ich kann nachträglich nichts ordentliches mehr damit anfangen?!

Wie sieht das denn aus? Die Tabelle liegt im Form, die neu hinzugefügten Elemente in der Tabelle, aber das Form ist eher geschlossen? Das sollte unmöglich sein, ohne dass auch die Tabelle beendet wurde.

Der Parser ist jedenfalls nicht mehr im Spiel, wenn Javascript arbeitet (außer bei innerHTML vielleicht). Wenn du den Parser verdächtigst, schau dir das DOM an, bevor du mit Javascript darin hantierst.

Lo!

[Fabulit]

Hi Lo!

Mich würde es zwar sehr wundern, wenn dich folgende Beschreibung weiterbringt, aber gerne schildere ich meine Beobachtungen.

Laut Firebug schaut es wie folgt aus; in dem Form-Element befindet sich nur der Submit-Button. Alles andere liegt außerhalb und wird trotzdem übertragen.

Die Ursache der form-Beendung ist vermutlich in folgender Verschachtelung zu finden.

laut Firebug:

<fieldset> //für Funktionsknöpfe
  <form>
    <input type="submit">
  </form>
</fieldset>

Das form-Element wird nicht durch ein entsprechendes Tag an der Stelle beendet, sondern durch den Parser.

Und daraus resultieren wohl auch die Folgefehler.

Ich werde wohl eine eigene Seite frü mich beanspruchen und muss mich dann nicht mehr mit den Unzulänglichkeiten des Vorsystems auseinandersetzen.

Gruß Fabulit

[dedlfix]

Hi!

Die Ursache der form-Beendung ist vermutlich in folgender Verschachtelung zu finden.
laut Firebug:
<fieldset> //für Funktionsknöpfe
  <form>
    <input type="submit">
  </form>
</fieldset>

Das form-Element wird nicht durch ein entsprechendes Tag an der Stelle beendet, sondern durch den Parser.

Dann müsste doch der Validator wegen Verschachtlungsfehler protestieren. Und wo in dem Szenario steckt dann die Tabelle? Und die anderen Formularelemente?

P.S. Da du ja Firebug hast, brauchst du die livehttpheaders-Extension nicht mehr unbedingt, denn der Firebug bietet in seiner Lasche Netzwerk bereits eine Obduktion von Request und Response an.

Lo!

[Fabulit]

Dann müsste doch der Validator wegen Verschachtlungsfehler protestieren.

Warum? So wie es da steht ist es doch korrekt.

In dem vorgelagerten PHP-Quellcode wird zwar nur das Fieldset geschlossen und das form-Element geht eigentlich noch viel weiter. Aber dieses wird anscheinend beim parsen "korrigiert".

Und wo in dem Szenario steckt dann die Tabelle? Und die anderen Formularelemente?

Folgt alles anschließend. Auf der Seite gibt es ca 10 Fieldsets. Im ersten befinden sich die Funktionsknöpfe und dann folgen die Daten (u. a. auch meine). Und es wird alles übertragen - bis auf die erwähnten nachträglich eingefügten Felder.

P.S. Da du ja Firebug hast, brauchst du die livehttpheaders-Extension nicht mehr unbedingt, denn der Firebug bietet in seiner Lasche Netzwerk bereits eine Obduktion von Request und Response an.

Mit den Chrome-Dev-Tools konnte ich auch einen Einblick nehmen; aber es ist wie es ist - meine dynamisch erzeugten Felder werden gar nicht erst verschickt.

Bitte mühe dich nicht weiter, wenn du nicht eigenen Ehrgeiz entwickelt hast. Ich werde meinem Auftraggeber eine leicht geänderte Variante geben, die dann auch in dem Murks-Umfeld läuft.

Gruß Fabulit

[dedlfix]

Hi!

Dann müsste doch der Validator wegen Verschachtlungsfehler protestieren.
Warum? So wie es da steht ist es doch korrekt.

Naja, der Browser wird sich kein fehlerhaftes DOM erzeugen, sondern die Fehler irgendwie so interpretieren, wie er es für richtig hält. Deswegen entstehen ja implizit eher als vorgesehen geschlossene Elemente.

In dem vorgelagerten PHP-Quellcode wird zwar nur das Fieldset geschlossen und das form-Element geht eigentlich noch viel weiter. Aber dieses wird anscheinend beim parsen "korrigiert".

Wenn das fieldset geschlossen wird, das form aber nicht, muss das einen Validier-Fehler ergeben, denn ein Form darf es nicht ohne schließendes Tag geben (jedenfalls HTML 4.01 und XHTML1.0 in allen Varianten)

Und wo in dem Szenario steckt dann die Tabelle? Und die anderen Formularelemente?
Folgt alles anschließend. Auf der Seite gibt es ca 10 Fieldsets. Im ersten befinden sich die Funktionsknöpfe und dann folgen die Daten (u. a. auch meine). Und es wird alles übertragen - bis auf die erwähnten nachträglich eingefügten Felder.

Wenn das alles implizit außerhalb des Forms steht - inklusive der nachträglichen Elemente? Es ist schwer vorstellbar, dass im HTML mitgelieferte Elemente zwar eigentlich außerhalb liegen, aber doch wieder zum Form gehören, die nachträglichen Quasi-Geschwister jedoch nicht.

Bitte mühe dich nicht weiter, wenn du nicht eigenen Ehrgeiz entwickelt hast.

Lohnt sich ja nicht, wenn du das Thema schon abgeschlossen hast.

Lo!

[Fabulit]

Lohnt sich ja nicht, wenn du das Thema schon abgeschlossen hast.

Naja, aus eigenem Interesse werde ich das schon noch weiter verfolgen und noch ein paar Experimente vornehmen. Sollte ich dabei eine Rekonstruktion meines Problems in einem bereinigten Umfeld erzeugen können, werde ich mich sofort wieder melden. Denn auch meines Erachtens kann es die von mir geschilderte Situation eigentlich gar nicht geben.

Vielen erneut und Gruß Fabulit

[Fabulit]

Ich habe meine Testumgebung jetzt so angepasst, dass auch hier das form-Element durch die Parser-Korrektur früh geschlossen wird. Dennoch werden die außerhalb liegenden Felder übertragen. Und die nachträglich erstellten Felder werden nicht übertragen.

Das Verhalten ist also das gleiche wie in der problematischen Produktivumgebung. Der große Unterschied ist allerdings, dass die Seite (logischerweise) nicht valide ist.

Daher habe ich mir die Validierung der Produktivumgebung mal zu Gemüte geführt, genauer gesagt habe ich mir beim Validieren den untersuchten Quelltext anzeigen lassen. Und was sehe ich; <body> ist mehr oder weniger leer. Sämtliche Inhalte werden per include in Abhängigkeit bestimmter Abfragen angezeigt und stehen dem Validator ohne die entsprechenden POST-Angaben also gar nicht zur Verfügung.

Ergo: Die Struktur ist wie vermutet falsch (wird nur nicht geprüft). Die w3c-Glaskugel kocht auch nur mit Wasser (kein Vorwurf - mein Fehler). Und ich habe einiges über die Funktionsweise des Validators gelernt.

Noch mal vielen Dank an Alle

Gruß Fabulit

[MudGuard]

Hi,

Dennoch werden die außerhalb liegenden Felder übertragen. Und die nachträglich erstellten Felder werden nicht übertragen.

Dann zeig doch endlich mal, wie Du die Felder nachträglich erzeugst.
Dabei scheint ja was falsch zu sein, denn sonst würden die nachträglich erzeugten Formular-Elemente ja auch mit übertragen ...

cu,
Andreas

[Fabulit]

Dabei scheint ja was falsch zu sein, denn sonst würden die nachträglich erzeugten Formular-Elemente ja auch mit übertragen ...

Hi Andreas,

ich vermute mal, dir ist irgendwo eine meine Antworten durch die Lappen gegangen. Der Fehler ist dahingehend eingegrenzt, dass er nicht beim Erstellen der input-Elemente zu suchen ist.

In dem Hauptprojekt liegt eine fehlerhafte Verschachtelung vor. Dadurch wird das form-Element ungewollt früh (durch Browser-Korrektur) geschlossen und alle input-Elemente stehen außerhalb des form-Elements.

Verwunderlich ist also eigentlich nicht, dass die nachträglich generierten Felder verloren gehen, sondern dass alle vom Server erstellten Felder trotzdem übertragen werden.

Ungünstig war zusätzlich, dass ich beim Validieren sehr unbedarft war. Viele Elemente der Seite (auch das kritische Formular) werden nur unter bestimmten Voraussetzungen (bestimmte $_POST-Variablen mit bestimmten Werten) included. Der Validator hat also ein fast leeres Dokument geprüft und ich habe mich auf das positive Ergebnis gestützt und mich dadurch bei der Fehlersuche etwas in die Irre führen lassen.

Meine Interpretation des gesamten Vorgangs: beim Zusammensetzen des Dokuments vom Server ist das HTML zwar nicht valide, aber die Felder stehen innerhalb des form-Elements. Dann kommt der Browser und setzt das Formular-Ende an eine gültige Stelle, die input-Elemente bleiben aber dem Formular zugeordnet, obwohl sie sich außerhalb befinden. Wenn ich nun nachträglich input-Elemente generiere und außerhalb des Formulars in das DOM einhänge, werden diese Felder richtigerweise nicht übertragen.

Meine Lösung: ich generiere per PHP in der Tabelle eine "Leerzeile" für neue Einträge. Das ist äußerst suboptimal, aber es funzt ;-) Die Entscheidung stammt vom Auftraggeber. Eine Korrektur des Vorsystems wäre zu umfangreich und würde ich mir auch nicht auflasten wollen.

Gruß Fabulit

[Fabulit]

Wenn zu sehen ist, dass alle Formularelemente übertragen werden (zu sehen in der Adresszeile beim GET), wird es nun Zeit, an das Backend zu gehen <= nicht spekulativer Tipp um dort die Fehlersuche fortzusetzen.

Aber es verhält sich ja so, dass ich (von mir aus mit GET) feststelle, dass eben nicht alle Formularelemente übertragen werden. Das Backend macht alles richtig, denn ihm wird ja gar nicht von neuen Feldern berichtet.

Also ist der Fehler wohl eher in dem form-Element zu suchen. Z.B. in der Art und Weise, dass meine Input-Felder außerhalb der Form liegen und daher nicht übertragen werden. Diese Möglichkeit habe ich bisher nur für äußerst unwahrscheinlich gehalten; denn meine Tabelle wird in ihrer Gesamtheit übertragen - ausschließlich die nachträglich erstellten inputs werden nicht übertragen, obwohl sie sich in der selben Tabelle befinden.

Gruß Fabulit

[hotti]

Aber es verhält sich ja so, dass ich (von mir aus mit GET) feststelle, dass eben nicht alle Formularelemente übertragen werden.

Nun, ich bin davon ausgegangen, dass Du das bereits im Frontend (visuell mit der Umstellung auf GET) geprüft hast.

Das Backend macht alles richtig, denn ihm wird ja gar nicht von neuen Feldern berichtet.

Dann sind offensichtlich wohl Deine neuen Felder doch nicht dabei.

Also ist der Fehler wohl eher in dem form-Element zu suchen. Z.B. in der Art und Weise, dass meine Input-Felder außerhalb der Form liegen und daher nicht übertragen werden.

Du konntest meinem ersten Tipp nicht folgen. Dann mach es jetzt ;)

[Fabulit]

Aber es verhält sich ja so, dass ich (von mir aus mit GET) feststelle, dass eben nicht alle Formularelemente übertragen werden.

Nun, ich bin davon ausgegangen, dass Du das bereits im Frontend (visuell mit der Umstellung auf GET) geprüft hast.

Genau das steht doch da, oder wo reden wir aneinander vorbei?

Das Backend macht alles richtig, denn ihm wird ja gar nicht von neuen Feldern berichtet.

Dann sind offensichtlich wohl Deine neuen Felder doch nicht dabei.

Richtig, das ist die Problematik, welche es zu klären gilt.

Du konntest meinem ersten Tipp nicht folgen. Dann mach es jetzt ;)

Wie kommst du darauf? Ich bin dem Tipp doch längst gefolgt. Sonst wüsste ich ja nicht, dass die Felder nicht mit übertragen werden, obwohl sie vorhanden sind.

Jetzt verwirr mich nicht mehr als nötig :-)

[Gunnar Bittersmann]

@@Fabulit:

nuqneH

Jetzt verwirr mich nicht mehr als nötig :-)

Hotti möchte auf gleicher Augenhöhe mit dir reden. >;->

Qapla'

[dedlfix]

Hi!

Also ist der Fehler wohl eher in dem form-Element zu suchen. Z.B. in der Art und Weise, dass meine Input-Felder außerhalb der Form liegen und daher nicht übertragen werden. Diese Möglichkeit habe ich bisher nur für äußerst unwahrscheinlich gehalten; denn meine Tabelle wird in ihrer Gesamtheit übertragen - ausschließlich die nachträglich erstellten inputs werden nicht übertragen, obwohl sie sich in der selben Tabelle befinden.

Das sollte auch unmöglich sein, denn wenn die Tabelle innerhalb des Form-Elements liegt, liegt auch alles darin in dem Formular. Es sei denn, die Elemente sind außerhalb notiert und per CSS-Positionierung nur optisch in die Zellen geschoben - aber das darf man doch wohl ausschließen.

Du schriebst zwar, dass du nichts veröffentlichen kannst, aber es sollte doch möglich sein, ein Minimalbeispiel zu erstellen, das deinem Fall nachbildet. Du hast doch schon einen Versuchsaufbau, der funktioniert hat. Bekommst du den soweit hin, dass er auch das unerwünschte Verhalten zeigt? Es dürfte doch harmlos sein, den zu veröffentlichen.

Lo!

[Fabulit]

Du hast doch schon einen Versuchsaufbau, der funktioniert hat. Bekommst du den soweit hin, dass er auch das unerwünschte Verhalten zeigt?

Das wäre noch mal eine interessante Herausforderung...

Aber auch ich sitze mehr oder weniger vor der Glaskugel, da das System umfangreich ist und mit zig Includes arbeitet und ich den PHP-Quellcode selber quasi nicht kenne (obwohl ich Zugriff habe). Ich betrachte also auch nur das, was im Browser ankommt und womöglich bereits durch den Tagsoup-Parser manipuliert wurde.

Und zu viel Aufwand soll auch nicht entstehen. Mein persönliches Interesse am Verständnis konnte ich mit eurer Hilfe schon so weit verifizieren, dass ich zufrieden bin. Und für mein Projekt habe ich schon Ausweich-Ideen.

[dedlfix]

Hi!

allerdings werden alle input-Elemente meiner Tabelle übertragen, bis auf die nachträglich hinzugefügten. D. h. die Tabelle ist innerhalb der Form platziert (ebenso wie der Submit-Button). Ergo _muss_ die neu hinzugefügte Tabellenzeile sich ebenso innerhalb der Form befinden.

Und sie haben auch alle Voraussetzungen, dass sie successfull control ergeben? Im Allgemeinen sind dafür die Attribute name und value notwendig.

Der Wechsel von POST zu GET liefert (richtigerweise) das gleiche (mangelhafte) Resultat, bringt also keine neuen Erkenntnisse.

Du sollst nicht das Resultat sondern die Elemente der Request-URL anschauen. Dort müssen zunächst einmal die neuen Elemente auftauchen.

Lo!

[Master of the Glaskugel]

folgende unzureichende Problembeschreibung bitte ich mit spekulativen Hinweisen zu versehen.

Gerade frisch geputzt!

Um neue Datensätze hinzuzufügen, kann per JavaScript eine neue Zeile in die Tabelle eingefügt werden...
Nun implementiere ich den Code in einer größeren Anwendung und treffe auf folgende Schwierigkeit; die nachträglich erstellten Input-Felder werden nicht übertragen, d.h. sind nicht in $_POST auffindbar.

Glaskugel sagt: Dein Form ist invalid, bzw. die Felder werden an einer Stelle erzeugt, wo sie nicht hingehören.

[Fabulit]

Danke für die spirituellen Mühen.

Glaskugel sagt: Dein Form ist invalid,

nein, das sieht die w3c-Glaskugel anders ;-)

bzw. die Felder werden an einer Stelle erzeugt, wo sie nicht hingehören.

Das wird es sein. Bzw. werden die Felder zwar an der gewünschten Stelle erzeugt, diese Stelle befindet sich allerdings nicht mehr in dem form-Element. Warum der Rest meiner Tabelle allerdings ohne Probleme gesendet wird, ist mir noch schleierhaft.

Ist es möglich, dass der Browser beim parsen eine "Korrektur" vornimmt und die input-Felder dem form-Element zuordnet, selbst wenn sie außerhalb der Form notiert sind? Oder anders gefragt; findet die Zuordnung zwischen input und form _ausschließlich_ durch die Position der Elemente statt, oder könnte man dieses manipulieren?

[dedlfix]

Hi!

Glaskugel sagt: Dein Form ist invalid,
nein, das sieht die w3c-Glaskugel anders ;-)
bzw. die Felder werden an einer Stelle erzeugt, wo sie nicht hingehören.
Das wird es sein. Bzw. werden die Felder zwar an der gewünschten Stelle erzeugt, diese Stelle befindet sich allerdings nicht mehr in dem form-Element. Warum der Rest meiner Tabelle allerdings ohne Probleme gesendet wird, ist mir noch schleierhaft.

Das ist eigentlich ausgeschlossen, wenn die gesamte Tabelle innerhalb von <form> und </form> steht. Ein weiteres darf auch nicht darin geschachtelt sein - aber das hätte der Validator schon angekreidet. Was der aber nicht sehen kann: das was du mit Javascript hinzufügst. Den aktuellen Elemente-Baum siehst du mit den Entwickler/Developer-Tools der einzelnen Browser - eingebaut in aktuellen Opera und Chrome, IE ab 8 (F12-Taste) und die Firebug-Extension für den Firefox.

Ist es möglich, dass der Browser beim parsen eine "Korrektur" vornimmt und die input-Felder dem form-Element zuordnet, selbst wenn sie außerhalb der Form notiert sind?

Schau nach, mit den genannten Werkzeugen.

Oder anders gefragt; findet die Zuordnung zwischen input und form _ausschließlich_ durch die Position der Elemente statt, oder könnte man dieses manipulieren?

Der Elementebaum ist entscheidend. Die "Zuordnung" ergibt sich aus der Schachtelung.

Lo!

[Fabulit]

Was der aber nicht sehen kann: das was du mit Javascript hinzufügst...

Da sagt du was. Aber wie kann ich dann mit wenig Aufwand validieren? Selber suchen hilft nichts; das einzige was feststeht, ist die Tatsache dass ich den Fehler nicht sehe. Mir fiele jetzt nur ein, die Felder per JavaScript einzufügen und die Seite danach abzuspeichern und anschließend das gespeicherte Dokument zu validieren. Klingt uncool ;-)

[ichbinich]

Hallo,

Da sagt du was. Aber wie kann ich dann mit wenig Aufwand validieren? Selber suchen hilft nichts; das einzige was feststeht, ist die Tatsache dass ich den Fehler nicht sehe. Mir fiele jetzt nur ein, die Felder per JavaScript einzufügen und die Seite danach abzuspeichern und anschließend das gespeicherte Dokument zu validieren. Klingt uncool ;-)

Firefox: Alles markieren (oder auch nur Teilbereiche) -> rechte Maustaste -> Auswahlquelltext anzeigen

vg ichbinich

[Fabulit]

Firefox: Alles markieren (oder auch nur Teilbereiche) -> rechte Maustaste -> Auswahlquelltext anzeigen

danke ichbinich. Das kannte ich noch gar nicht. Und ich bin gespannt darauf, denn überall wo Quellcode draufsteht, ist ja normalerweise nur der vom Server gelieferte Code drin.

Gruß Fabulit

[dedlfix]

Hi!

Was der aber nicht sehen kann: das was du mit Javascript hinzufügst...
Da sagt du was. Aber wie kann ich dann mit wenig Aufwand validieren?

Die Validität bezieht sich auf das HTML-Dokument, nicht auf dem DOM-Baum, den sich der Browser intern zusammenbaut. Im DOM kann man im Prinzip ungestraft Elemente ineinanderschachteln, die der Validator so nicht erlauben würde. Es kommt nur darauf an, ob der Browser das mitmacht. Und ob das eine gute Idee ist, steht auf einem anderen Blatt.

Mir fiele jetzt nur ein, die Felder per JavaScript einzufügen und die Seite danach abzuspeichern und anschließend das gespeicherte Dokument zu validieren. Klingt uncool ;-)

Damit bekommst du unter Umständen ein noch weniger valides Dokument (sprich: eins mit noch mehr Fehlern), denn der Browser kann je nach eigenem Bedarf in das DOM auch noch Elemente und Attribute hängen, die proprietär sind.

Lo!

[Master of the Glaskugel]

Glaskugel sagt: Dein Form ist invalid,
nein, das sieht die w3c-Glaskugel anders ;-)

Na gut, die haben wohl das aktuellere Modell ;-)

bzw. die Felder werden an einer Stelle erzeugt, wo sie nicht hingehören.

Das wird es sein. Bzw. werden die Felder zwar an der gewünschten Stelle erzeugt, diese Stelle befindet sich allerdings nicht mehr in dem form-Element.

Sie werden visuell an der von Dir erwarteten Stelle angezeigt, dass trügt.

Warum der Rest meiner Tabelle allerdings ohne Probleme gesendet wird, ist mir noch schleierhaft.

Soweit der Originalform valide ist, vermute ich einen Logikfehler bzgl. der Einsetzung der Elemente. Soweit dir keine schönen Debugmöglichkeiten zur Verfügung stehen, könntest Du folgendes machen:
Lass dir z.B. beim onSubmit des Formulars mal ausgeben, was der Browser aktuell vorliegen hat: alert(document.body.innerHTML). Du wirst sehen, dass dies nicht mit dem übereinstimmt, was Du vorher statisch geschickt hast, bzw. was Du erwarten würdest. Soweit Du nicht zum Ziel kommst: Online-Beispiel wäre gut.

Ist es möglich, dass der Browser beim parsen eine "Korrektur" vornimmt und die input-Felder dem form-Element zuordnet, selbst wenn sie außerhalb der Form notiert sind?

Ja, überspitzt und vereinfacht gesagt, machst Du dem Client(Browser) mit dem HTML nur einen Vorschlag.

Oder anders gefragt; findet die Zuordnung zwischen input und form _ausschließlich_ durch die Position der Elemente statt, oder könnte man dieses manipulieren?

Ja, setz die neuen Felder valide ein ;-)

[Matthias Apsel]

Om nah hoo pez nyeetz, Master of the Glaskugel!

Glaskugel sagt: Dein Form ist invalid, nein, das sieht die w3c-Glaskugel anders ;-)

Na gut, die haben wohl das aktuellere Modell ;-)

ne, die kriegen was, das du nicht hast.

Matthias

[Master of the Glaskugel]

Glaskugel sagt: Dein Form ist invalid,
nein, das sieht die w3c-Glaskugel anders ;-)
Na gut, die haben wohl das aktuellere Modell ;-)
ne, die kriegen was, das du nicht hast.

Gute Glaskugeln brauchen keine Beweise, es reicht eine vage Idee. Punkt für mein Modell!

[Fabulit]

Lass dir z.B. beim onSubmit des Formulars mal ausgeben, was der Browser aktuell vorliegen hat: alert(document.body.innerHTML).

Gute Idee, wobei ich jetzt erwarte, dass die Ausgabe mit dem im Firebug Angezeigten übereinstimmt...

Online-Beispiel wäre gut.

Leider so spontan nicht machbar, da es sich um ein CMS handelt, deren Daten euch nichts angehen (mich eigentlich auch nicht) ;-) Eine Beispiel-Umgebung aufzusetzen lohnt nicht. Eigentlich sollte sich mein ganzes Vorhaben auf 60 Minuten Arbeitseinsatz beschränken.

Ich werde zur Not einfach per PHP eine Leerzeile für neue Einträge zur Verfügung stellen. Das ist bereits getestet und würde funktionieren. Dann muss der Anwender zwar jedes Mal speichern, bevor er die Möglichkeit bekommt den nächsten Datensatz zu erfassen, aber das wäre in diesem Fall nicht weiter tragisch.

Gruß Fabulit

[Master of the Glaskugel]

Online-Beispiel wäre gut.
Leider so spontan nicht machbar, da es sich um ein CMS handelt, deren Daten euch nichts angehen

Die Daten sind irrelevant. Nimm den fehlerverursachenden Quelltext, ersetze alle kritischen _Daten_ durch Platzhalter und poste das.

[dedlfix]

Hi!

Nun implementiere ich den Code in einer größeren Anwendung und treffe auf folgende Schwierigkeit; die nachträglich erstellten Input-Felder werden nicht übertragen, d.h. sind nicht in $_POST auffindbar.

Ein erster Blick sollte dann mit solchen Tools wie der livehttpheaders-Extension für den Firefox den vom Browser gesendeten Daten gelten. Die genannte Extension kann dir die POST-Daten anzeigen. Vielleicht hast du den neuen Input-Elementen keine eindeutigen Namen gegeben. Es würde auch ein []-Anhängsel gehen, dann wird ein Array-Element erzeugt und gleichnamige Elemente überschreiben sich nicht.

Das PHP-Error-Reporting ist voll aufgedreht und trotzdem schweigsam.

Solange du nicht auf nicht ungeprüft auf nicht Vorhandenes zugreifst, bleibt das auch still.

Und da ich von der Testumgebung weiß, dass meine Ansätze prinzipiell funktionieren, muss ich jetzt über Wechselwirkungen mit dem bestehenden System spekulieren.

Du hast das auch möglichst produktivumgebungsnah getestet? Also beispielsweise mit einem Tabellenrest, der ungefähr der Produktivumgebung entspricht.

Mir ist an dem bestehenden System aufgefallen, dass zwei Formulare in einer Datei verwendet werden. Kann es womöglich damit zusammenhängen?

Solange sie nicht ineinander geschachtelt sind oder du erwartest, dass die Daten mehrerer Formulare gleichzeitig gesendet werden, kannst du so viele Formulare einbauen, wie du lustig bist.

Oder hat jemand mal ähnliche Erfahrungen gemacht und kann mir daher einen Tipp geben? Ich bin etwas ratlos, wie ich jetzt zu debuggen habe.

Es gibt viele Wege, Fehler zu machen. Alle kann man gar nicht erfahren und die Ursachen können selbst bei ähnlichen Auswirkungen ganz andere sein. Das Beste ist immer noch individuelles Debugging. Überlege dir, wo welche Daten entstehen, welche Wege sie genau gehen und wie du diese Wege überprüfen kannst. Ein Beispiel wäre, wie oben vorgeschlagen, zu prüfen was der Browser absendet und nicht nur, was beim Server ankommt (genauer gesagt, was PHP aus den ankommenden Daten gemacht hat).

Lo!

[Fabulit]

Ein erster Blick sollte dann mit solchen Tools wie der livehttpheaders-Extension für den Firefox den vom Browser gesendeten Daten gelten.

Das ist eine gute Idee. Kann ich nur leider hier im Büro nicht. Kommt also auf meine Liste für später.

Es würde auch ein []-Anhängsel gehen, ...

Genau das ist mein Ansatz. (Puh, wenigstens etwas richtig gemacht ;-) )

Du hast das auch möglichst produktivumgebungsnah getestet?

In der Phase befinde ich mich gerade :-D

Es gibt viele Wege, Fehler zu machen...

Ich kenne noch mehr!

Vielen Dank dedlfix, wieder einige Ideen um weiter zu suchen.

Gruß Fabulit

[dedlfix]

Hi!

Ein erster Blick sollte dann mit solchen Tools wie der livehttpheaders-Extension für den Firefox den vom Browser gesendeten Daten gelten.
Das ist eine gute Idee. Kann ich nur leider hier im Büro nicht. Kommt also auf meine Liste für später.

Wie jetzt, du sollst was entwickeln, aber dir werden dafür benötigte/sinnvolle Werkzeuge nicht gestattet? Ich nehme an, dass du dann auch keine anderen Browser zur Verfügung hast, die solche Request-Response-Anzeigewerkzeuge bereits eingebaut haben - IE9 oder Chrome beispielsweise?

Poor-Mans Kontrollwerkzeug wäre dann das schon vorgeschlagene GET statt POST und das Überprüfen des Querystring. Wobei du dir auch $_SERVER['QUERY_STRING'] anschauen kannst, oder am besten beides - nicht dass ein mod_rewrite da was dran ändert.

Lo!

[Fabulit]

Das ist eine gute Idee. Kann ich nur leider hier im Büro nicht. Kommt also auf meine Liste für später.

Wie jetzt, du sollst was entwickeln, aber dir werden dafür benötigte/sinnvolle Werkzeuge nicht gestattet?

Nein, aber ich arbeite nicht als Entwickler. Daher kann ich hier im Büro keine solchen Erweiterungen nutzen.

Und $_SERVER['QUERY_STRING'] habe ich mir noch nicht angeschaut. Vielleicht bringt das ja auch neue Erkenntnisse.

Danke Lo!

[Fabulit]

Danke für die vielen Hinweise. Ich habe deutlich mehr Klarheit und kann mich jetzt guten Gewissens an den Auftraggeber wenden und behaupten es läge alles an dem bestehenden System. Das Formular des Vorsystems scheint fehlerhaft, so dass ich mich nicht über unerwartetes Verhalten wundern muss.

Gruß Fabulit

[hotti]

Danke für die vielen Hinweise. Ich habe deutlich mehr Klarheit und kann mich jetzt guten Gewissens an den Auftraggeber wenden und behaupten es läge alles an dem bestehenden System. Das Formular des Vorsystems scheint fehlerhaft, so dass ich mich nicht über unerwartetes Verhalten wundern muss.

"scheint fehlerhaft" ist keine klare Aussage und eine sehr sehr schlechte Basis für einen Anruf beim Auftraggeber.

[Fabulit]

"scheint fehlerhaft" ist keine klare Aussage und eine sehr sehr schlechte Basis für einen Anruf beim Auftraggeber.

Wie kommst du denn darauf, dass das meine Basis ist?

Meine Basis:

-Auftraggeber und ich wussten im Vorfeld von undokumentiertem, unkommentierten und unformatierten Quelltext des Vorsystems und den eventuell resultierenden Schwierigkeiten

-ich bin explizit _nicht_ engagiert worden, das Vorsystem zu reparieren oder auf Erweiterungen vorzubereiten - ich liefere einzig die Erweiterung

-ich biete zwei alternative Lösungsansätze, welche die gleiche Funktionalität bei minimal veränderter Handhabung gewährleisten

Mein Anruf:

"Hallo Herr X, das Modul Y kann in Ihrem System Z nur unter bestimmten Voraussetzungen eingebunden werden. Wegen der mangelhaften Dokumentation ist es mir nicht möglich, diese Voraussetzungen zu ermitteln. Es kommt bei dem Zusammenspiel beider Systeme zu unerwarteten Kollisionen. Dies sind meine Alternativ-Vorschläge..."

Die Antwort:

"Herr Fabulit, verwenden Sie bitte doch den Alternativ-Vorschlag A. Ich sehe keinen entscheidenden Unterschied zu der von uns beauftragten Variante."

[hotti]

hi,

Mein Anruf:

"Hallo Herr X, das Modul Y kann in Ihrem System Z nur unter bestimmten Voraussetzungen eingebunden werden. Wegen der mangelhaften Dokumentation ist es mir nicht möglich, diese Voraussetzungen zu ermitteln. Es kommt bei dem Zusammenspiel beider Systeme zu unerwarteten Kollisionen. Dies sind meine Alternativ-Vorschläge..."

Das ist auf jeden Fall gut formuliert. Was sehr gut ist, sind Alternativ-Vorschläge, erfahrungsgemäß kommt das immer gut an, einem Anruf steht sodann nichts im Weg.

Viel Erfolg!

Hotti

[Gunnar Bittersmann]

@@Fabulit:

nuqneH

Um neue Datensätze hinzuzufügen, kann per JavaScript eine neue Zeile in die Tabelle eingefügt werden.

Hast du dabei beachtet, dass 'tr' in HTML niemals Kind von 'table' ist? Hilft dir die Archivsuche nach "Nostradamus"?

Qapla'

[Fabulit]

Hi Gunnar,

Hast du dabei beachtet, dass 'tr' in HTML niemals Kind von 'table' ist?

Jepp, ganz vorbildlich wird explizit mit thead und tbody gearbeitet.

Hilft dir die Archivsuche nach "Nostradamus"?

Das kommt jetzt ein wenig spät ;-) Aber es gibt mittlerweile einen Ergebnis-Beitrag mit meinen Erkenntnissen, so dass ich den wertvollen Nostradamus-Joker für nächstes Mal aufbewahre.

Gruß Fabulit