Form in Form / Nested Forms (2)

[Pit]

Hi felix,

das klingt falsch. Der Submit-Button sollte noch immer als separater Submit-Button existieren. Wenn das Formular durch passende fieldset-Elemente strukturiert ist, wird dem Benutzer klar, welcher Submit-Button für welche Daten relevant ist. Auf der Serverseite kannst Du dann auch verhindern, dass andere Daten ebenso verarbeitet werden, weil für sie ein anderer Submit-Button zuständig ist.

Vertrau' mir, es ist korrekt. Ich weiß genau, was Du meinst und wüßte genau, wie ich es erstelle. (ist auch viel einfacher) Genau DAS will ich nicht haben, denn das habe ich in dem anderen Script so gemacht und werde es anschließend dieser Lösung anpassen. Die Daten befinden sich übrigens in einer Tabelle, daher Zeilen.

Bischen doof, da man nicht weiß, welche Einträge editiert wurden jund welche einfach unverändert mitgeliefert werden.

Wie gesagt, Du solltest die Verarbeitung der Daten vom verwendeten Submit-Button abhängig machen. Alles andere ist Unsinn! Mir scheint, dass bei Dir genau dieses Dein tatsächliches technisches Problem ist.

Das wäre einfach, es ist aber nicht das, was ich gerne hätte. Es sind tabellarische Daten mit einem einzigen Submitbutton unterhalb der Tabelle.

habe ich ein verstecktes input-field installiert, in das ich dann per JS die EditID hinein packe,

Das klingt nach fahrlässig falsch! Tu das nicht! Das ist quick&dirty und ohne JavaScript unbenutzbar und von daher gefährlich!

Ohne JS siehst Du meine Seite GAR NICHT. Und das ist ok so, da ich meinen Nutzerkreis kenne und sie einen Browser und dessen Einstellungen im Zweifel vorgegeben erhalten.

dann weiß ich auf dem Server, welche Zeile wirklich editiert wurde.

Zeile? Editiert? Du editierst Zeilen? Geht es um Textinhalte, die Du in Zeilen organisierst? Na, dann zeig doch mal ein online-Beispiel, wie so eine Bearbeitungsseite bei Dir aussieht! Mannomann, das klingt nach einem Sumpf von funktionalem Design!

Eine Tabelle. Die hat Zeilen. Und 3 Themenbereiche mit jeweils n Zeilen.

Dort kann ich dann hierüber die werte aus dem assoziativen Array direkt herauspicken und in der DB ändern.

Uärgs! Assoziatives Array bedeutet, dass Deine Feldnamen so aussehen:

<input name="quatsch[mit][sosse]" value="Zeile mit Textinhalt">

Oder:

<input name="arr_datum[2073]" value="..."> (wobei 2073 die ID des Eintrages ist)

'Finde ich effizienter und weniger fehleranfällig als eine mir nciht bekannte Menge an Zeilen komplett zu ändern, nur weil sie auch mitgeliefert werden, aber gar nicht userseitig behandelt wurden.

Wie wäre es denn damit:

<fieldset>
  <legend>Zeile 1274 - Erklärung einer Unschuld</legend>
  <p>
    <label for="line-1274">
      Zeile 1274
      <input name="line-1274" value="Er sagte zu ihr, er habe die Nacht auf dem Sofa verbracht.">
    </label>
    <button name="save-1274">Zeile 1274 speichern</button>
  </p>
</fieldset>

Durch die Benennung des Buttons mit dem Schlüsselwort "save" wird klar, dass es sich hier um einen Button handelt. Mit dem Schlüsselwort "line" erkennt man, dass es von einem input-Feld stammt.

Klar, kann man machen, habe ich sogar in einer Config-Tabelle so gelöst. (dann soganr noch so, dass beim Reload der Seite imer genau wieder zurück an den Anker dieser Stelle in der Tabelle gehüpft wird). Nur, ich finds nicht schön und habe mich schon lange gegen so eine Programmierung entschieden.

Wenn es nervig war, dann hat es ein kaputtes funktionales Design!

Wenn das ein Kriterium wäre, wäre Deine Anregung noch kaputter. Nichts für Ungut, Felix, ich mag Deine Postings, Anregungen, Hilfen immer sehr. Aber ich nutze beide Wege (Deinen und meinen) in meiner Anwendung seit Jahren... und beide laufen problemlos. Meine finde ich aber besser.

Trotzdem danke für Deinen Kommentar,

Pit