Form in Form / Nested Forms (2)

[Pit]

Hallo Felix,

Du hast also eine Tabelle, in der Du nur Änderungen innerhalb einer Zeile akzeptieren willst? Der Benutzer darf also nicht in beliebigen Zellen Inhalte ändern? Okaaay...

Nicht ganz… Stell Dir die Tabelle als wirklich tabellarische Daten vor, denn das sind sie. In Script1 habe ich sie tatsächlich in 3 Tabellen unterteilt. In Script 2 sind sie in einer Tabelle, weil zum Abschluss noch die Summierung aller Werte einer Spalte unter die Tabelle kommt. Durch das Zusammenfassen in eine Tabelle wird die Summierung einfach klarer. Reden wir aber von Script 2: Innerhalb der ersten beiden Themenbereiche darf der User beliebig viele Änderungen (auf einmal) vornehmen. Übrigens hier auch über assoziative Gestaltung des $_POST-Arrays umgesetzt. Der User ändert also beliebig viel, das Ganze wird zusätzlich visualisiert, und zum guten Schluß klickt er den Absendebutton, der namentlich deutlich macht, dass die Summe aller Änderungen gespeichert werden wird. Jede editierte Zeile bleibt, egal ob editiert und als editiert visualisiert oder "uneditiert" immer eine Zeile hoch. Das liegt daran, dass der User in diesen Zeilen immer nur 3 Werte ändern können muß, die jeweils nur einzeilig bleiben (also Zahl, Ziffer o.ä.).

Der 3. Themenbereich unterscheidet sich hiervon, denn die Einträge sind uneditiert zwar auch 1 Zeile hoch, aber beim Edit hat der User sehr viele Editieroptionen, die weit über die Zeile ansich hinaus gehen. Deshalb wird bei Klick auf den Editbutton diese Tabellenzeile um ein ganzes, übrigens wunderschön gestaltetes ;) Formular mit allen relevanten Informationen und Editiermöglichkeiten eingeblendet. Dieses hat sicher die Höhe von 30-40 Zeilen. Deshalb habe ich das so gestaltet, dass sich die Edits in diesem Themenbereich "zieharmonikamäßig" abwechseln. Ich wollte nicht, dass in Themenbereich 3 mehr als 1 Edit gleichzeitig vorgenommen wird, weil das über die Tabellenlänge ansonsten unübersichtlich und somit fehleranfällig wird. Daher habe ich jetzt quasi diese Mischform, dass der User sowohl Mehrfachedits ausführen kann als auch in einem Themenbereich nur Einzeledits vornehmen kann. Das das so sinvoll ist, mußt Du jetzt einfach glauben, da ich nicht näher als geschehen auf die Inhalte eingehen kann, weils zu viel werden würde. 😜

Bleibt also erstens die Umsetzung (die könnte man so machen, wie beschriebst, nämlich einem Zeilenbutton) und bei meiner Lösung die intuitive Visualisierung (die bei Deiner Lösung auch wegfällt):

Deshalb meine Umsetzung dergestalt, dass ich in den edit einer Zeile des Themenbereichs 3 zwar einen Button setze, der namentlich verdeutlicht, dass es um den Einzeledit dieser Zeile geht, der aber nichts anderes macht, als das Gesamtformular abzusenden. Das beim Klick auf diesen Button auch Edits aus den ersten beiden Themenbereichen verarbeitet werden, ist mir bewußt, daran werde ich auch nichts ändern.

Ich denke, jetzt wird deutlicher, warum ich das so gelöst habe. Und warum erkläre ich es so lang und breit? Nunja, ich weiß selber, wie es sich anfühlt jemandem zu helfen, der beratungsresistent wirkt. Das motiviert nicht sonderlich. Wenn aber deutlich wird, dass derjenige die Lösung aus dem Hilfsangebot verstanden hat, aber begründet eine gleichwertige andere Lösung vorgezogen hat, passt das dann schon wider ;)

Ich habe verstanden, dass Du es so haben willst. Du konntest mich nur nicht davon überzeugen, warum Du die Daten in eine Tabelle packst, um dann dem Benutzer nur das Speichern von Daten innerhalb einer Tabellenzeile zu erlauben.

...wird jetzt sicher klarer, hm?

Aha. Da hätte ich jetzt spontan gesagt, dass Du drei Tabellen benötigst. Für jeden Themenbereich eine.

Genauso habe ich das in Script 1. Sieht aber viel "ausgerissener" aus als in Script 2. Da ist alles kompakter, übersichtlicher, gebündelter... nur hatte ich dort halt wegen meiner o.g. Editvorgaben das Form in Form Problem (um zum Ausgangspunkt meines Problems zurückzukommen).

Schon klar. Habe ich auch schon gemacht. Man baut seine Projekte eben nach den Idealen, die man sich vornimmt. Da PHP zum Einsatz kommt, werden "Namen" wie "arr_datum[2073]" eben korrekt verstanden. Unter anderen serverseitigen Lösungen könnte das problematisch werden, aber warum sollte man das berücksichtigen, wenn man niemals vorhat, seine Lösung nach anderen Sprachen zu portieren? Also alles gut.

Sehe ich genauso.

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).

Klingt nach einer coolen Lösung! Sie skaliert ebenso gut, wie mit "arr_datum[2073]".

Haha... nein, es klingt nach Deiner bevorzugten Lösung 😉 Warum habe ich das übrigens dort so gelöst? Weil es eine Tabelle mit ca. 250 Konfigeinstellungen ist und ich nicht wollte, dass der User hier zig mal in der Tabelle hin- und her springt, ggf. bereits hier oder dort etwas editiert, es wieder vergisst, dann woanders... und so weiter... und zum guten Schluss schickt er dann ein Formular ab, in dem alles mögliche in der Konfiguration verstellt wird. Und warum darf ich die User dieses Scripts für so doof oder zerstreut annehmen? Weil ich der einzige User mit Rechten für dieses script bin 😉

Und hier sind wir wieder beim geschmacklichen Aspekt. Und über Geschmack lässt sich bekanntlich "trefflich streiten".

Ja, ich glaube auch, dass es darauf hinaus läuft. Oder darauf, dass es für beide hier angesprochenen Lösungen (zumindest für mich) gute Gründe oder sinnvolle Anwendungsgebiete gibt.

Das macht richtig Spaß und ist keinesfalls "nervig" in der Erstellung!

Ah, gut, dass Du das "nervig" nochmal ansprichst. Es geht da nicht immer nur um die Arbeit selber, es geht auch darum, ob das, was man da machen muß zeitaufwändig und dabei "brotlos" ist ;)

Trotzdem danke für Deinen Kommentar,

Ich lerne aus Deinem Problem wieder etwas neues. Lohnt sich immer.

Mir geht das genauso mit Deinen/Euren Antworten,

Gruß, Pit