Form in Form / Nested Forms (2)

[Pit]

Hallo Forum,

ich hänge immer noch an meinem Form in Form Problem rum.

Wenn ich alle Formulare in ein einziges Formular packen müßte, müßte ich sehr viel umbauen. Und darüber hinaus müßte ich meine Idee, je Tabellenzeile 1 weiteres Formular einzublenden, komplett umstricken.

Deshalb würde ich, falls möglich, gerne anders da herangehen.

Frage: Ist es möglich, per Javascript die meine Formulare umschließende form-tags (also den öffnenden und schließenden) "auszublenden" oder würde das der Browser eh nicht verstehen? Was ich miene: Ich kann ja per JS (oder Jquery) das DOM nahezu beliebig verändern. Wäre es da nicht möglich, das "äußere" Formular "unschädlich" zu machen, zu verstecken, zu löschen?

Pit

[Mitleser]

Frage: Ist es möglich, per Javascript die meine Formulare umschließende form-tags (also den öffnenden und schließenden) "auszublenden" oder würde das der Browser eh nicht verstehen? Was ich miene: Ich kann ja per JS (oder Jquery) das DOM nahezu beliebig verändern. Wäre es da nicht möglich, das "äußere" Formular "unschädlich" zu machen, zu verstecken, zu löschen?

Möglich ist das bestimmt. Nur wird das sehr schmutzig und hässlich werden. Selbst wenn Du valides Markup lieferst, kannst Du dir nicht sicher sein, was für ein DOM welcher Client daraus genau generiert. Das wird bei der internen Fehlerkorrektur nicht besser ;-)

Ergo mehr als fraglich, ob Du damit besser als mit einem Umbau des ursprünglichen Konzept fährst.

[Pit]

Ergo mehr als fraglich, ob Du damit besser als mit einem Umbau des ursprünglichen Konzept fährst.

Ich würds gerne trotzdem mal versuchen.

Wie gehe ich sowas denn am Besten an? Reicht es, den tags eine ID zu geben und sie zu verstecken oder reicht das so nicht?

Pit

[MudGuard]

Hi,

Ergo mehr als fraglich, ob Du damit besser als mit einem Umbau des ursprünglichen Konzept fährst.

Ich würds gerne trotzdem mal versuchen.

Wie gehe ich sowas denn am Besten an? Reicht es, den tags eine ID zu geben und sie zu verstecken oder reicht das so nicht?

Du kannst keine Tags verstecken, nur ganze Elemente (und das auch nur mitsamt ihrem Inhalt).

Du müßtest Dir den gesamten Inhalt des (äußeren) Form-Elements zwischenspeichern, die Stelle im Dokument merken, an der das Form-Element hängt, das Form-Element aus dem DOM aushängen, und dann den zwischengespeicherten Inhalt an dieser Stelle ins DOM einhängen.

cu,
Andreas a/k/a MudGuard

[Mitleser]

Du müßtest Dir den gesamten Inhalt des (äußeren) Form-Elements zwischenspeichern, die Stelle im Dokument merken, an der das Form-Element hängt, das Form-Element aus dem DOM aushängen, und dann den zwischengespeicherten Inhalt an dieser Stelle ins DOM einhängen.

Das wird IMHO nicht die Konstellation sein, die bei dem kaputten Markup im DOM enstehen wird.

[Pit]

Hi,

Du kannst keine Tags verstecken, nur ganze Elemente (und das auch nur mitsamt ihrem Inhalt).

Verstehe.

Du müßtest Dir den gesamten Inhalt des (äußeren) Form-Elements zwischenspeichern, die Stelle im Dokument merken, an der das Form-Element hängt, das Form-Element aus dem DOM aushängen, und dann den zwischengespeicherten Inhalt an dieser Stelle ins DOM einhängen.

Auch nicht gerade wenig aufwändig... 😟

Kann man denn nicht gleich hinter den öffnenden form-tag des äußeren Formulars einen schließenden per JS einfügen? Geht sowas?

Und entsprechend natürlich auch direkt vor den schließenden form.tag einen öffnenden? Dann wären alle formulare hinter- anstelle von ineinander.

Pit

[Mitleser]

Kann man denn nicht gleich hinter den öffnenden form-tag des äußeren Formulars einen schließenden per JS einfügen? Geht sowas?

So läuft das nicht. Nicht mittels JavaScript im Browser. Das ursprüngliche Markup ist nach dem Parsen für das daraus generierte DOM nicht mehr relevant. Wenn Du das so via JS machen willst, dann wäre das Mittels Node.js auf dem Server möglich. Auch hässlich, aber zumindest weniger fehleranfällig als im Browser.

Lass das einfach, der gesamte Ansatz wird Dir mehr Kummer bereiten, als Du ahnst.

[Mitleser]

Ergo mehr als fraglich, ob Du damit besser als mit einem Umbau des ursprünglichen Konzept fährst. Ich würds gerne trotzdem mal versuchen.

Dann schmeiss mal den Objektinspektor an und guck, was die Clients so draus machen. Habe es nicht getestet, vermute aber, dass bei jedem öffnendem Form das vorige geschlossen wird. Viel Spaß ;-)

[Gunnar Bittersmann]

@@Mitleser

Selbst wenn Du valides Markup lieferst, kannst Du dir nicht sicher sein, was für ein DOM welcher Client daraus genau generiert.

?? Ist dir da das „nicht“ im Satzbau verrutscht?

Selbst wenn Du nicht valides Markup lieferst, kannst Du dir sicher sein, was für ein DOM welcher Client daraus genau generiert.

LLAP 🖖

[ursus contionabundo]

Selbst wenn Du nicht valides Markup lieferst, kannst Du dir sicher sein, was für ein DOM welcher Client daraus genau generiert.

Das gilt womöglich für aktuelle (die, bzw. deren Engine kann man ja testen oder gar deren Spezifikationen nachlesen) — aber nicht für zukünftige Clients:

Man will ja sein nicht-valides Markup nicht an künftige Fehlerkorrekturen anpassen. Also: Ganz einfach valides Zeug erzeugen, das spart in der Zukunft viel Arbeit, die auch noch genau dann sofort erledigt werden muss, wenn es gar nicht passt.

[Gunnar Bittersmann]

@@ursus contionabundo

Selbst wenn Du nicht valides Markup lieferst, kannst Du dir sicher sein, was für ein DOM welcher Client daraus genau generiert.

Das gilt womöglich für aktuelle (die, bzw. deren Engine kann man ja testen oder gar deren Spezifikationen nachlesen) — aber nicht für zukünftige Clients:

Doch. Die HTML-Spezifikation liegt genau fest, wie HTML zu parsen ist (incl. Fehlerbehandlung) und welches DOM daraus entsteht.

Es ist nicht zu erwarten, dass jemand zukünftig einen Browser entwickelt, der dieser Spezifikation widerspricht.

LLAP 🖖

[ursus contionabundo]

@@ursus contionabundo

Selbst wenn Du nicht valides Markup lieferst, kannst Du dir sicher sein, was für ein DOM welcher Client daraus genau generiert.

Das gilt womöglich für aktuelle (die, bzw. deren Engine kann man ja testen oder gar deren Spezifikationen nachlesen) — aber nicht für zukünftige Clients:

Doch. Die HTML-Spezifikation liegt genau fest, wie HTML zu parsen ist (incl. Fehlerbehandlung) und welches DOM daraus entsteht.

Es ist nicht zu erwarten, dass jemand zukünftig einen Browser entwickelt, der dieser Spezifikation widersprich

Du meinst wahrscheinlich sowas.

Das setzt aber voraus, dass das invalide Zeug bei der Spezifikation vorausgeahnt wurde. Das ist aber, besonders im Hinblick auf die Kombinationsmöglichkeiten mehrerer "Invaliditäten", nicht vollständig möglich. Hinzu kommt, dass es womöglich nicht eindeutig ist, was der Browser zu machen hat, wenn er auf invalides HTML trifft.

[Gunnar Bittersmann]

@@ursus contionabundo

Das setzt aber voraus, dass das invalide Zeug bei der Spezifikation vorausgeahnt wurde.

Das wurde. Wie schon gesagt: die Spec beschreibt, wie HTML zu parsen ist. Jedes.

Das ist aber, besonders im Hinblick auf die Kombinationsmöglichkeiten mehrerer "Invaliditäten", nicht vollständig möglich.

Die Fettschrift macht die Aussage fetter, aber nicht richtiger.

Hinzu kommt, dass es womöglich nicht eindeutig ist, was der Browser zu machen hat, wenn er auf invalides HTML trifft.

Wie schon gesagt: die Spec beschreibt, wie HTML zu parsen ist. Eindeutig.

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist einer von ihnen kaputt.

LLAP 🖖

[ursus contionabundo]

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist einer von ihnen kaputt.

Thema verfehlt, Setzen!

Merksatz: Wenn zwei Browser aus demselben invalidem HTML-Code unterschiedliche DOMs bauen, dann ist der HTML-Code kaputt.

[Gunnar Bittersmann]

@@ursus contionabundo

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist einer von ihnen kaputt.

Thema verfehlt

Ganz und gar nicht.

Merksatz: Wenn zwei Browser aus demselben invalidem HTML-Code unterschiedliche DOMs bauen, dann ist der HTML-Code kaputt.

Das mag ja sein. Aber: HTML5-Parser bauen auch aus invalidem HTML-Code ein DOM, und zwar nach genau festgelegten Regeln. Welcher Teil von „die Spec beschreibt, wie HTML zu parsen ist. Jedes“ war da missverständlich?

LLAP 🖖

[ursus contionabundo]

@@ursus contionabundo

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist einer von ihnen kaputt.

Thema verfehlt

Ganz und gar nicht.

Merksatz: Wenn zwei Browser aus demselben invalidem HTML-Code unterschiedliche DOMs bauen, dann ist der HTML-Code kaputt.

Das mag ja sein. Aber: HTML5-Parser bauen auch aus invalidem HTML-Code ein DOM, und zwar nach genau festgelegten Regeln.

Du behauptest, das Parsen von invalidem HTML gemäß der Spec führe stets zu demselben DOM.

Welcher Teil von „die Spec beschreibt, wie HTML zu parsen ist. Jedes“ war da missverständlich?

Einfachste Antwort:

Ganz konkret jeder Teil der Spec, in welchem das wunderschöne Wort "otherwise" steht. Und das sind "ziemlich viele".

Denn aus dem "otherwise" folgt logisch zwingend:

Zwei Browser, derselbe kaputte HTML-Code, zwei verschiedene DOMS nach Vorgehen, welches jeweils streng der Spec folgt.

Q.E.D.

Dein Satz "Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist einer von ihnen kaputt." ist bewiesen falsch.

[Gunnar Bittersmann]

@@ursus contionabundo

Ganz konkret jeder Teil der Spec, in welchem das wunderschöne Wort "otherwise" steht.

Auch im Otherwise-Zweig steht ganz konkret, wie sich der Parser zu verhalten hat.

Zwei Browser, derselbe kaputte HTML-Code, zwei verschiedene DOMS nach Vorgehen, welches jeweils streng der Spec folgt. Q.E.D.

Zeig mir bitte konkret eine Stelle in der Spec, die dem Parser die Wahl zwischen Weg A und Weg B lässt. Ansonsten hab ich auf diesen Unsinn keine Lust mehr.

LLAP 🖖

[ursus contionabundo]

Zeig mir bitte konkret eine Stelle in der Spec, die dem Parser die Wahl zwischen Weg A und Weg B lässt. Ansonsten hab ich auf diesen Unsinn keine Lust mehr.

Nanu? Das hab ich doch schon am Anfang der Diskussion verlinkt.

Zitat:

If the stack of open elements does not have an element in table scope that is an HTML element with the same tag name as that of the token, then this is a parse error; ignore the token.

Otherwise:

Generate implied end tags.

Daraus folgt: Aus

<table>
   <tbody>
      <tr>
         <td>Hallo<td>Welt!</td>
      </tr>
   </tbody>
</table>

kann entweder

<table>
   <tbody>
      <tr>
         <td>Hallo</td><td>Welt!</td>
      </tr>
   </tbody>
</table>

oder eben auch

<table>
   <tbody>
      <tr>
         <td>HalloWelt!</td>
      </tr>
   </tbody>
</table>

werden. Also erzeugen zwei "unkaputte", der Spec sauber folgende Browser aus demselben HTML-Code unterschiedliche DOMs.

[ursus contionabundo]

Sorry, Ich such ein anderes.

[Tabellenkalk]

Hallo,

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist einer von ihnen kaputt.

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist mindestens einer von ihnen kaputt…

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist einer von ihnen kaputt.

Wenn zwei Browser aus demselben HTML-Code unterschiedliche DOMs bauen, ist mindestens einer von ihnen kaputt…

Das ist doch dasselbe! Was anderes wäre „genau einer von ihnen“. 😜

LLAP 🖖

[ursus contionabundo]

Und darüber hinaus müßte ich meine Idee, je Tabellenzeile 1 weiteres Formular einzublenden, komplett umstricken.

Aha. Das wäre aber gerade sehr einfach. Hier mal ein Beispiel, dargestellt als wüste Mischung aus Output, Daten und HTML:

<form>

ID|Ort 1|<label for="ort_1">Berlin<label><input type="checkbox" id="ort_1" name="ort[1]"> 2|<label for="ort_2">Hamburg<label><input type="checkbox" id="ort_2" name="ort[2]">

übernehmen

</form>

Du musst also nur das Skript einigermaßen schlau anpassen, welches die Tabelle erzeugt. Serverseitig hast Du z.B. array_keys($_POST['ort']) und dann $_POST['ort'][$i] zur Verfügung.

Falls Du meinst, dass da zu viele Daten hin-und hergehen: Welcher Mensch soll die denn eingeben, dass es unter technischen Gesichtspunkten "beachtlich große" Datenmengen werden?

[Felix Riesterer]

Lieber Pit,

ich hänge immer noch an meinem Form in Form Problem rum.

Du hast dort auf die angebotenen Hinweise nicht im Mindesten reagiert. Der Thread ist noch immer offen, man kann also dort weitere Postings absetzen. Dass Du eben gerade nicht dort Deine Nachfrage postest, sondern stattdessen in einem neuen Thread, zeigt mir, dass Du nicht Willens warst, die Kritik an Deiner Lösungsstrategie anzuerkennen, sondern noch immer darauf beharrst, dass der von Dir eingeschlagene Lösungsweg sinnvoll sei und zwingend eine funktionierende Lösung an dessen Ende stehen muss.

Bist Du resistent gegen echte Hilfe?

Liebe Grüße,

Felix Riesterer.

[Pit]

Hallo Felix,

Du hast dort auf die angebotenen Hinweise nicht im Mindesten reagiert.

Das ist so nicht richtig. Ich habe meine Reaktion nur nicht kund getan. 😉 Im Ernst, ich habe seitdem versucht, meinen Code so umzubauen, dass nur noch 1 Formular daraus resultiert und bin immer wieder an verschiedenen Ecken auf andere Probleme gestoßen. Daher hatte ich auch bezgl. der Antworten keine Nachfragen, denn die Probleme hatten damit nichts direkt zu tun. Letztendlich hatte ich also 1 Formular, 2 Absendebuttons und je nach Button kamen verschiedene Daten durch. Mein Versuch, per JS nachzuscheuen, welche Daten denn vom Client wirklich abgesendet wurden, schlug leider auch fehl. Von den anderen Problemen ganz zu schweigen.

Der Thread ist noch immer offen, man kann also dort weitere Postings absetzen. Dass Du eben gerade nicht dort Deine Nachfrage postest, sondern stattdessen in einem neuen Thread, zeigt mir, dass Du nicht Willens warst, die Kritik an Deiner Lösungsstrategie anzuerkennen, sondern noch immer darauf beharrst, dass der von Dir eingeschlagene Lösungsweg sinnvoll sei und zwingend eine funktionierende Lösung an dessen Ende stehen muss.

Ja, so ungefähr wars auch gedacht. Nachdem ich den ersten Weg (aus thread1) eine Weile lang gegangen war, wollte ich nun doch nochmal den Weg2 (daher neuer Thread) ausprobieren und danach entscheiden, welcher Weg für mich der Bessere ist. Hat aber nichts damit zu tun, dass ich selber den Weg1 nicht für besser halte, ich bin halt nur dort zuoft an meine Grenzen gestoßen. Nicht mal die Grenzen dessen, was ich ggf. kann sondern was ich hier ändern will. Insofern hast Du das vermutlich richtig erkannt.

Bist Du resistent gegen echte Hilfe?

Natürlich nicht. Ich hätte das vielleicht erklären sollen, was ich vor habe. Das ganze Thema nervt mich inzwischen mehr als das es mir Spaß macht und ich wäre in diesem Fall für eine schmutzige lösung recht dankbar, das ist wohl der Hintergrund. Die saubere Lösung, selbst wenn sie dann läuft, wird neue Probleme aufwerfen, denn dann müßte ich im Rahmen eines einheitlichen designs auch andere Stellen im Gesamtprozess ändern... das ist einer der Gründe, warum mir eine schmutzige Lösung hier sogar lieber wäre.

Nichts desto trotz habe ich die hilfreichen Kommentare in Thread1 gelesen und auch versucht, umzusetzen. Ich hätte das erwähnen sollen, da hast Du recht.

Gruß, Pit

[Felix Riesterer]

Lieber Pit,

schön, dass Du Dir die Zeit für eine ausführlichere Antwort genommen hast. Als Helfender fühlt man sich so wesentlich ernster genommen.

Im Ernst, ich habe seitdem versucht, meinen Code so umzubauen, dass nur noch 1 Formular daraus resultiert und bin immer wieder an verschiedenen Ecken auf andere Probleme gestoßen.

Schade, dass Du diesen Prozess im alten Thread nicht dokumentiert hast. Vielleicht hätte man Dir bei der einen oder anderen "Ecke" andere Lösungswege aufzeigen können, als Du sie offensichtlich nach wie vor verfolgst. Was Du in Wirklichkeit zu erreichen suchst, ist nach wie vor unklar, da wir nur von nested forms sprechen, nicht aber von dem, was Du tatsächlich baust.

Daher hatte ich auch bezgl. der Antworten keine Nachfragen, denn die Probleme hatten damit nichts direkt zu tun.

Bist Du Dir da wirklich so sicher, dass Du Irrtümer Deinerseits gänzlich ausschließen kannst? Manchmal kann man nicht "outside the box" denken, wenn man in der Box drinnen sitzt und feststeckt.

Letztendlich hatte ich also 1 Formular, 2 Absendebuttons und je nach Button kamen verschiedene Daten durch.

Das klingt doch nach Erfolg!

Mein Versuch, per JS nachzuscheuen, welche Daten denn vom Client wirklich abgesendet wurden, schlug leider auch fehl.

Wieso "auch"? Du wolltest doch unterschiedliche Server-Reaktionen auf verschiedene Buttons hin! Was ist speziell daran fehlgeschlagen? Dass Du mittels JavaScript etwas nachsteuern möchtest, leuchtet mir ein. Das Formular bei seinem submit-Event abzufangen und den verwendeten Submit-Button zu ermitteln, ist sicherlich möglich. Wenn Du daran gescheitert bist, wäre das eine Nachfrage im alten Thread wert gewesen!

Von den anderen Problemen ganz zu schweigen.

Nein! Schweigen hilft Dir hier nicht weiter! Sprich es an, beschreibe alles, was Du da tust, damit man Dir helfen kann. Online-Beispiele können unsere Einsichten übrigens sehr stark beschleunigen.

Das ganze Thema nervt mich inzwischen mehr als das es mir Spaß macht und ich wäre in diesem Fall für eine schmutzige lösung recht dankbar, das ist wohl der Hintergrund.

Nee, lass uns das mal "richtig" machen. Dann klappt's auch mit später hinzugeflanschten Erweiterungen, weil es vom Konzept her stimmt.

Die saubere Lösung, selbst wenn sie dann läuft, wird neue Probleme aufwerfen, denn dann müßte ich im Rahmen eines einheitlichen designs auch andere Stellen im Gesamtprozess ändern...

Aha! Du redest von Design! Das hat mit der Funktionalität zuerst einmal überhaupt nichts zu tun! Wenn Du eine "user experience" mit "Design" verwechselst, dann können wir darüber reden, wie man mit JavaScript diese unter den gegebenen serverseitigen Funktionalitäten verbessert. Aber zuerst muss das Prinzipielle passen!

das ist einer der Gründe, warum mir eine schmutzige Lösung hier sogar lieber wäre.

Finger weg! Tu Dir das nicht an! Ich spreche aus leidvoller Erfahrung!

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Du redest von Design! Das hat mit der Funktionalität zuerst einmal überhaupt nichts zu tun!

Natürlich hat es das!

„Design ist nicht nur, wie es aussieht oder sich anfühlt. Design ist, wie es funktioniert.“ —Steve Jobs

Wer bei Design nur an Aussehen und Hübschmachen denkt, hat eine falsche Vorstellung davon, was Design ausmacht.

LLAP 🖖

[ursus contionabundo]

Wer bei Design nur an Aussehen und Hübschmachen denkt, hat eine falsche Vorstellung davon, was Design ausmacht.

Nana. Das kommt darauf an, was mit "Design" gemeint ist:

Wikipedia: Design

Der Titel dieses Artikels ist mehrdeutig. Weitere Bedeutungen sind unter Design (Begriffsklärung) aufgeführt.

Man kann das UI unter vielen Gesichtspunkten (Buntiztät, Benutzungsablauf) "designen", man kann den dahinter stehenden technischen Ablauf "designen", man kann das oder die Programme/Skripte "designen", die Transport-Protokolle aller OSI-Level wurden "designt", die Programmiersprachen selbst wurden auch "designt" und sogar deren Interpreter bzw. Compiler (oder Mischformen) wurden (hoffentlich) "designt", was dann sogar auf Hardware bis hin zum Chip (sogar den Die darin) zutrifft ...

Allerdings würde ich im Hinblick auf den Inhalt der Diskussion auch davon ausgehen, dass der Pit nur die Weboberfläche bestenfalls deren Benutzungsablauf meint. Das folgt aber einem Blick in die Glaskugel. Und deren Design folgt bekanntlich nicht dem (nur) vermuteten Zweck, richtige Aussagen zu den gestellten Fragen zu produzieren. Darüber weiß man nur, dass so ein Gerät eigentlich nicht nur aus Glas (oft auch noch als "Kristall" bezeichnet) bestehen dürfte.

[Pit]

Hallo Felix (und natürlich auch alle anderen Helfer),

schön, dass Du Dir die Zeit für eine ausführlichere Antwort genommen hast. Als Helfender fühlt man sich so wesentlich ernster genommen.

Du hast Recht. Normalerweise versuche ich wirklich immer, zu antworten. Aber ich war einfach nur noch frustriert, was diese Formulare anging.

Im Ernst, ich habe seitdem versucht, meinen Code so umzubauen, dass nur noch 1 Formular daraus resultiert und bin immer wieder an verschiedenen Ecken auf andere Probleme gestoßen.

Schade, dass Du diesen Prozess im alten Thread nicht dokumentiert hast. Vielleicht hätte man Dir bei der einen oder anderen "Ecke" andere Lösungswege aufzeigen können, als Du sie offensichtlich nach wie vor verfolgst. Was Du in Wirklichkeit zu erreichen suchst, ist nach wie vor unklar, da wir nur von nested forms sprechen, nicht aber von dem, was Du tatsächlich baust.

Ich finde es auch unglaublich kompliziert, es zu erklären. Teilweise baut es auch auf Code auf, den ich vor x Jahren erstellt habe ud in dem ich selber nicht mehr 100%ig drin bin. Der Kern dessen, was relevant ist: Ich habe ein Formular, das 3 Themenfelder hat, die jeweis mehrere zu editierende Unterpunkte haben. Nun habe ich die Editmöglichkeit des 3. Themenfeld ausgetauscht gegen eine, die ich bereits in einem anderen Script verwende. In dem anderen Script geht das, weil dort voneinander unabhängige Formulare arbeiten. Diese Editiermöglichkeit wird per Include eingebunden. Das Schöne an ihr ist, dass der zu editierende Unterpunkt ein eigenes Formular einblendet. So kann nach Absenden auch nur dieser Unterpuinkt serverseitig verarbeitet werden. Das geht aber nur, wenn die beiden ersten themenbereiche jeweils eigene Formulare haben. Das ist im aktuellen Script aber bisher nicht der Fall. Dort waren bisher die 3 Themenbereiche in einem einzigen Formular und genau deshalb kann ich das Script für den 3. themenbereich nichte infach genauso einbinden, wie in dem anderen Script, wo die Themenbereiche getrennt sind.

Also: Script1:

Thema A
<form>
Unterpunkt 1
Unterpunkt 2
...
</form>
Thema B
<form>
Unterpunkt 1
...
</form>
Thema C
<form> (über include eingebunden)
Unterpunkt n (n = angeklickter Unterpunkt)
</form>

Script2:

Thema A
<form>
Unterpunkt 1
Unterpunkt 2
...
Thema B
Unterpunkt 1
...
Thema C
<form>
Unterpunkt n (n = angeklickter Unterpunkt)
</form>

Script 2 = Nicht valide und funktioniert nicht.

Letztendlich hatte ich also 1 Formular, 2 Absendebuttons und je nach Button kamen verschiedene Daten durch.

Das klingt doch nach Erfolg!

Nicht wirklich. Ich hatte nicht den Eindruck, Kontrolle darüber zu haben, daher wollte ich ja auch den Vergleich von Client-Daten zu Server-Daten haben, damit ich sehe, was ich absende und was ankommt.

Mein Versuch, per JS nachzuscheuen, welche Daten denn vom Client wirklich abgesendet wurden, schlug leider auch fehl.

Wieso "auch"? Du wolltest doch unterschiedliche Server-Reaktionen auf verschiedene Buttons hin!

Nein, eigentlich wollte ich nur 1 Button haben, je nachdem ob ich in Thema 3 einen Editlink geklickt hatte oder nicht.

Was ist speziell daran fehlgeschlagen? Dass Du mittels JavaScript etwas nachsteuern möchtest, leuchtet mir ein. Das Formular bei seinem submit-Event abzufangen und den verwendeten Submit-Button zu ermitteln, ist sicherlich möglich.

Es ging mir nicht um den Button... ich wollte alle abgesendeten Formular Keys und Values haben.

Von den anderen Problemen ganz zu schweigen.

Nein! Schweigen hilft Dir hier nicht weiter! Sprich es an, beschreibe alles, was Du da tust, damit man Dir helfen kann. Online-Beispiele können unsere Einsichten übrigens sehr stark beschleunigen.

Das war mein nächstes Problem. Es ist ein wirklich großes Script (ca. 3000 Zeilen ohne includes), welches das HTML generiert, je nachdem, was man gerade in diesem Berewich machen möchte. Und ein Teil des Quelltextes ist nicht direkt sichtbar, weil er über JS generiert wird. Leider ist es mir nicht gelungen, das auf den relevanten Quelltext zu reduzieren und zugehbar zu machen.

Das ganze Thema nervt mich inzwischen mehr als das es mir Spaß macht und ich wäre in diesem Fall für eine schmutzige lösung recht dankbar, das ist wohl der Hintergrund.

Nee, lass uns das mal "richtig" machen. Dann klappt's auch mit später hinzugeflanschten Erweiterungen, weil es vom Konzept her stimmt.

Ok.... ich werds nochmal neu angehen.

Die saubere Lösung, selbst wenn sie dann läuft, wird neue Probleme aufwerfen, denn dann müßte ich im Rahmen eines einheitlichen designs auch andere Stellen im Gesamtprozess ändern...

Aha! Du redest von Design! Das hat mit der Funktionalität zuerst einmal überhaupt nichts zu tun! Wenn Du eine "user experience" mit "Design" verwechselst, dann können wir darüber reden, wie man mit JavaScript diese unter den gegebenen serverseitigen Funktionalitäten verbessert. Aber zuerst muss das Prinzipielle passen!

Zur Klärung: Eigentlich ist das Design jetzt schon nicht einheitlich (siehe Skizze oben). Die 3 Formulare des Script1 sind jetzt schon nicht identisch mit dem Konstrukt in Script2, weder funktional noch designmäßig. Das war aber bislang nicht schlimm, weil in Script2 noch ein bislang unerwähnter (und auch zu lang zu erklärender) Zusatz beinhaltet ist, durch den ein 100% indetisches Design nicht unabdingbar nötig war. Es ist eher so, dass je mehr ich daran bastele, desto eher muß ich das andere Script auch "verbasteln"... ich bin da momentan sehr hin- und hergerissen... (merkt man sicher auch dem Post an.. und daher rührt auch, dass ich es am liebsten möglichst gar nicht angefasst hätte oder es "schmutzig " gelöst haben wollte.

das ist einer der Gründe, warum mir eine schmutzige Lösung hier sogar lieber wäre.

Finger weg! Tu Dir das nicht an! Ich spreche aus leidvoller Erfahrung!

Ach, so schlimm wärs an der Stelle sicher gar nicht. Aber ich habe den Eindruck, dass ich auch gar nicht so viel Arbeit dadurch sparen würde...das stört mich noch mehr... 😟

Aber Du hast Recht... ich werde es nochmal angehen. Danke auch für die aufbauenden Worte.

Gruten Rutsch und Gruß, Pit

[pl]

Es ist ein wirklich großes Script (ca. 3000 Zeilen ohne includes), welches das HTML generiert,

Also mal im Ernst, da wirds echt langsam Zeit mal darüber nachzudenken wie man seinen Code organisiert. Und auch über ein zweckmäßiges Templatesystem.

MfG

[Felix Riesterer]

Lieber pl,

Also mal im Ernst, da wirds echt langsam Zeit mal darüber nachzudenken wie man seinen Code organisiert.

ich fürchte da hast Du recht.

Und auch über ein zweckmäßiges Templatesystem.

Wie auch immer das aussehen mag.

Liebe Grüße,

Felix Riesterer.

[pl]

Hallo @Felix Riesterer

Und auch über ein zweckmäßiges Templatesystem.

Wie auch immer das aussehen mag.

Derart gibts auf jeden Fall auch für PHP. Der Hauptgewinn besteht darin, daß HTML und CODE getrennt ist. Dann wird auch der CODE wesentlich weniger. Nur als Beispiel, meine Frameworks haben in Perl wie auch in c ca. 300 Zeilen Code (ohne Plugins)! Die main Funktion in c hat gar nur 20 Zeilen, Beispielseite.

Das längste Scipt was ich mal geschrieben hatte war eine Benutzerverwaltung für LDAP und das waren ca. 1000 Zeilen in Perl, womit auch HTML generiert wurde.

Weitermachen 😉

[Felix Riesterer]

Lieber pl,

Derart gibts auf jeden Fall auch für PHP.

wie Sand am Meer! Daher meine Bemerkung.

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Und auch über ein zweckmäßiges Templatesystem.

Wie auch immer das aussehen mag.

Derart gibts auf jeden Fall auch für PHP. Der Hauptgewinn besteht darin, daß HTML und CODE getrennt ist.

HTML ist auch Code. Und wenn man die HTML-Ausgabe nicht mit Mitteln der sowieso schon verwendeten Programmiersprache (Sprache P wie Programmiersprache) steuern möchte, benötigt man eine dritte Sprache (Sprache T wie Template-System). Die Syntax von Sprache T zum Steuern des Template-Systems (hauptsächlich Wiederholungen, bedingte Ausgaben sowie Platzhaltermechanik) mag einfacher sein als die von P, aber effektiv tauscht man lediglich die Elemente von P durch die von T aus. Und das ist letztlich keine Trennung, solange man derartige Steuerelemente braucht.

Dann wird auch der CODE wesentlich weniger.

Durchaus möglich. Der Preis ist eine zunehmende Komplexität an anderer Stelle (das Template-System bringt eigene Code und Logik mit) und eine längere Laufzeit, weil das Template-System zusätzliche Arbeit verrichten muss, um Sprache T nach P umzusetzen.

Am Ende löst aber auch ein Template-System nicht das logische Strukturierungsproblem, das der OP hat.

dedlfix.

[pl]

Am Ende löst aber auch ein Template-System nicht das logische Strukturierungsproblem, das der OP hat.

Wenn 3000 Zeilen PHP CODE HTML generieren, liegt mit Sicherheit ein strukturelles und konzeptionelles Problem vor. Und letztendlich auch ein Logisches, weil unter solchen Gegebenheiten mit der Logik was nicht stimmen kann.

Mein FW hat 300 Zeilen und das ist in c geschrieben! Und es eignet sich dazu, tausende verschiedene Anwendungen auszuliefern! Der OP hingegen hat 3000 Zeilen für eine Anwendung, über diesen Unterschied lohnt es sich mal nachzudenken.

Dasselbe FW hab ich nämlich auch in PHP entwickelt und da hatte die Hauptdatei nur 170 Zeilen.

MfG

[Matthias Apsel]

Hallo pl,

Mein FW hat 300 Zeilen und das ist in c geschrieben! Und es eignet sich dazu, tausende verschiedene Anwendungen auszuliefern! Der OP hingegen hat 3000 Zeilen für eine Anwendung, über diesen Unterschied lohnt es sich mal nachzudenken.

Dasselbe FW hab ich nämlich auch in PHP entwickelt und da hatte die Hauptdatei nur 170 Zeilen.

#Der Prahlhans

Die Kühle des Abends
Das Mondlicht erstrahlt.
Der Tag ist vergangen,
was hat er geprahlt.

Was war er doch leuchtend
So bunt und so schön.
Die Nacht ist jetzt dunkel,
er nicht mehr zu sehn.

Da möcht es doch manchem,
manchem Prahlhans so gehen.
Bald ist er verschwunden
und nicht mehr zu sehen.

© Gerhard Ledwina

Bis demnächst
Matthias

[pl]

Mobben macht Spaß wa!? Meine Güte ist das armseelig! Und ja, auf mein c Framework kann ich mir echt was einbilden! Das hab ich mir nämlich alles selbst erarbeitet! Da protze ich gerne damit rum, aber sowas von!!

[Orlok]

Hallo pl

Mobben macht Spaß wa!? Meine Güte ist das armseelig!

Mach mal halblang. Es ist kein Mobbing, dich darauf hinzuweisen, dass deine ständige Bezugnahme auf dein Framework hier im Forum unangemessen ist.

Ich zitiere mal aus der Charta des Forums:

„Missbrauche das Forum nicht als Werbeplattform.“

Und weiter unten:

„Folgende Nachrichten werden im SELFHTML-Forum bei Entdecken gelöscht: […] Aufdringliche Werbung […], auch wenn der übrige Inhalt des Postings nicht der Werbung dient.“

Die Verweise auf dein Framework haben – zumindest nach meiner Beobachtung – nur selten Bezug zur eigentlichen Fragestellung, beziehungsweise zum Thema der jeweiligen Diskussion. Und wenn ein fachlicher Bezug gegeben ist, dann sind die Verweise auf das Framework in aller Regel wenig hilfreich, weil der Code nicht öffentlich einsehbar ist.

Codebeispiele wie dieses …

// framework.c

doSomeMagic(value) // Does some magic!

… sind für niemanden hilfreich.

Ich kann mich nicht daran erinnern, dass du mal einen Link auf ein Repository gepostet hättest. Du verlinkst zwar regelmäßig deine Website, aber dort finden sich nur noch mehr nichtssagende Codeschnippsel zusammen mit ein paar vagen Erklärungen – und jeder Menge Selbstbeweihräucherung.

Solange dein Framework aber closed source ist und du auch nicht gewillt bist, in deinen Beiträgen wenigstens die relevanten Abschnitte des Codes offenzulegen, ist das was du hier machst nicht viel mehr als Werbung für dein Framework.

Das ist hier im Forum nicht erwünscht.

Wenn dein Framework ein hier im Forum diskutiertes Problem löst, dann kannst du gerne deine Implementierung zur Diskussion stellen. Das wäre dann womöglich hilfreich. Nicht hilfreich sind jedenfalls Anpreisungen und nicht nachprüfbare Behauptungen. Darauf solltest du in Zukunft verzichten.

Gruß,

Orlok

[Matthias Apsel]

Hallo Orlok,

„Missbrauche das Forum nicht als Werbeplattform.“

Und im konkreten Fall kommt noch hinzu, dass PLs Antowrt nicht nur absolut nichts zur Lösung beiträgt, sondern den Fragenden auch noch als unfähig hinstellt.

Das war der eigentliche Auslöser für meinen Beitrag.

Bis demnächst
Matthias

[pl]

Guten Morgen @Orlok

Mobben macht Spaß wa!? Meine Güte ist das armseelig!

Mach mal halblang. Es ist kein Mobbing, dich darauf hinzuweisen, dass deine ständige Bezugnahme auf dein Framework hier im Forum unangemessen ist.

Ich zitiere mal aus der Charta des Forums:

„Missbrauche das Forum nicht als Werbeplattform.“

Schon falsch!

Wie kommt Ihr eigentlich ständig und in Folge auf die dämliche Idee ich würde Euer Forum für Werbung mißbrauchen!? Das habe ich 1. gar nicht nötig weil ich Rentner bin und 2. gehts hier um um die Energie des Verstehens!

Und 3. schreiben andere hier auch was sie gerade machen!

MfG

[Gunnar Bittersmann]

@@pl

und 2. gehts hier um um die Energie des Verstehens!

Möge die Energie mit dir sein.

LLAP 🖖

[pl]

@Gunnar Bittersmann

und 2. gehts hier um um die Energie des Verstehens!

Möge die Energie mit dir sein.

Danke!!! Du ich denke die meisten hier wissen gar nicht was es heißt, behindert zu sein! Während Andere in meiner Situation in irgendeiner Einrichtung Papiersterne zusammenleimen, hab ich das Glück zuhause zu sein und das tun zu dürfen was ich immer gemacht habe: Programmieren.

Ohne Stock über die Straße zu kommen ist für mich ein größerer Erfolg, als ein Web Application Framework in c zu entwicklen!

MfG

[Christian Kruse]

Hallo pl,

Wie kommt Ihr eigentlich ständig und in Folge auf die dämliche Idee ich würde Euer Forum für Werbung mißbrauchen!? Das habe ich 1. gar nicht nötig weil ich Rentner bin

Werbung verfolgt nicht zwangsläufig kommerzielle Interessen. Der Wunsch nach Anerkennung etwa oder der Wunsch, dass die eigene Software mehr eingesetzt wird oder die Überzeugung, dass eine Lösung besser ist als die andere sind häufige Werbe-Gründe.

und 2. gehts hier um um die Energie des Verstehens!

Wenn es dir um die Energie des Verstehens geht, dann musst du grundlegend anders auftreten. Weniger Werbung, weniger Dogmatismus ala „mein Perl ist das geilste.“ Anerkennen, dass es andere Lösungswege gibt, die andere Tradeoffs machen. Anderen Postern hier im Forum zugestehen, dass sie wissen, worüber sie schreiben. Eingehen auf Kritik, die an deinen Lösungen geübt wird.

Kurz: dein Verhalten lässt nicht darauf schließen, dass du an einem Diskurs interessiert bist, sondern nur an der Verbreitung deiner Dogmen.

Und 3. schreiben andere hier auch was sie gerade machen!

Ich glaube nicht, dass das wahr ist, vor allem nicht in der Form, wie du es hier tust. Ich lasse mich aber gern eines besseren belehren.

LG,
CK

[Matthias Apsel]

Hallo pl,

Wie kommt Ihr eigentlich ständig und in Folge auf die dämliche Idee ich würde Euer Forum für Werbung mißbrauchen!?

Weil Sätze wie „Mein FW hat [nur] 300 Zeilen und das ist in c geschrieben!“ „Und es eignet sich dazu, tausende verschiedene Anwendungen auszuliefern!“ genau diesen Eindruck erwecken.

Bis demnächst
Matthias

[Pit]

Hi dedlfix,

Am Ende löst aber auch ein Template-System nicht das logische Strukturierungsproblem, das der OP hat.

Im ersten teil Deines Satzes stimme ich Dir zu. Ich habe früher ein System betreut, dass mit templates gearbeitet hat (irgend so ein Forensystem), ich fands gruselig. Vielleicht wars einfach schlecht geschrieben, aber seitdem halte ich gar nichts mehr von Templatesystemen.

Den zweiten Teil sehe ich so nicht, es sei denn, Du meinst meine Ausgangsfrage.

Ich habe die 3000 Zeilen geschätzt, es sind je nach Leseweise nur die Hälfte bis 4 mal so viele, denn es sind in Summe 4 Dateien, die auch gut und gerne in einer Datei stehen könnten.

Ich verstehe nicht, warum eine php-Datei, die den HTML jund auch JS Code generiert, nicht ein paar Tausend Zeilen haben können sollte. In Relation zum Gesamtprogramm ist die Datei winzig. Es geht hier nicht um Codeschnipsel, sondern um ein Anwendungsprogramm. Btw., alleine die Hauptdatei der fpdf-Klasse hat auch 2000 Zeilen... gibts da auch Strukturprobleme?

Gruß, Pit

[dedlfix]

Tach!

Ich habe die 3000 Zeilen geschätzt, es sind je nach Leseweise nur die Hälfte bis 4 mal so viele, denn es sind in Summe 4 Dateien, die auch gut und gerne in einer Datei stehen könnten.

Ich verstehe nicht, warum eine php-Datei, die den HTML jund auch JS Code generiert, nicht ein paar Tausend Zeilen haben können sollte. In Relation zum Gesamtprogramm ist die Datei winzig.

Das ist nicht das Problem, das ich meine. Die Größe von Dateien ist lediglich für dich als Entwickler relevant und wie du damit umgehen kannst, zum Beispiel dass du die Dinge gut findest, die du suchst.

Es geht hier nicht um Codeschnipsel, sondern um ein Anwendungsprogramm. Btw., alleine die Hauptdatei der fpdf-Klasse hat auch 2000 Zeilen... gibts da auch Strukturprobleme?

Das Strukturproblem sehe ich darin, wie die Webseite aufgebaut ist, dass es da ein großes Formular gibt, und dass sich das nun damit beißt, weil weitere Formulare in seinem Scope (sozusagen) verwendet werden sollen. Das müsste grundlegend umstrukturiert werden, so dass sich diese Notwendigkeit der Schachtelung nicht mehr ergibt. Wenn abgeschaltetes Javascript kein Problem ist, muss man ja nicht für alle Eingabeelemente ein Formular drumherumbauen. Aber genaueres kann ich dir nicht empfehlen, weil ich dein Problem nicht näher verfolgt habe.

dedlfix.

[Pit]

Hi dedlfix,

Das ist nicht das Problem, das ich meine. Die Größe von Dateien ist lediglich für dich als Entwickler relevant und wie du damit umgehen kannst, zum Beispiel dass du die Dinge gut findest, die du suchst.

Einverstanden. Das klappt im Allgemeinen recht gut. Ich muß mich, wenn ich eine Datei lange nicht mehr "gesehen" habe, immer ein bischen einarbeiten, aber das ist nicht ungewöhnlich, denke ich. Ich fand die Pauschalkritik einiger Forenmitglieder an der Dateigröße nicht angemessen und wollte wissen, ob Du das auch so siehst oder ob Du mit dem Satz etwas anders meintest.

Das Strukturproblem sehe ich darin, wie die Webseite aufgebaut ist, dass es da ein großes Formular gibt, und dass sich das nun damit beißt, weil weitere Formulare in seinem Scope (sozusagen) verwendet werden sollen. Das müsste grundlegend umstrukturiert werden, so dass sich diese Notwendigkeit der Schachtelung nicht mehr ergibt.

Ok, dann habe ich Dich korrekt verstanden und kann Deine Kritik annehmen. Denn der Aufbau der Seite kann so nicht richtig sein. Er ist nicht valide und er funktioniert nicht.

Wenn abgeschaltetes Javascript kein Problem ist, muss man ja nicht für alle Eingabeelemente ein Formular drumherumbauen.

Kannst du mir genauer erklären, was Du mit dem Zusammenhang "JS und Formular um alle Eingabeelemente" meinst?

Gruß, Pit

[dedlfix]

Tach!

Kannst du mir genauer erklären, was Du mit dem Zusammenhang "JS und Formular um alle Eingabeelemente" meinst?

Beispielsweise muss ein Suchfeld plus Absendebutton nicht zwangsläufig in einem Formular-Element untergebracht sein. Das aber nur aus der rein technischen Sicht. Es gibt gute Gründe, dafür ein Formular zu verwenden, beispielsweise dass man ohne weiteres Zutun im Suchfeld auf die Enter-Taste drücken kann, um ein Submit anzustoßen. Aber sei es im Augenblick mal drum.

Man kann auch die Elemente ohne ein Formular-Element drumherum platzieren. (Oder ein darum platziertes Formular ignorieren, was aber Probleme mit der Enter-Taste bringt.) Stattdessen kann man auch den Button zum Click- statt Submit-Button umschreiben und mit Javascript beim Click das Eingabefeld auslesen und den gewünschten Request absetzen.

Allgemein ist das wohl eher keine gute Vorgehensweise, und ich würde das auch nur in kontrollierten Umgebungen (à la Firmenintranet mit vorgeschriebenem Browser) so umsetzen, aber auch nur dann, wenn das Umstrukturieren keine Option ist.

dedlfix.

[Pit]

Hi dedlfix,

jetzt weiß ich, was Du meinst, danke.

Man kann auch die Elemente ohne ein Formular-Element drumherum platzieren. (Oder ein darum platziertes Formular ignorieren, was aber Probleme mit der Enter-Taste bringt.) Stattdessen kann man auch den Button zum Click- statt Submit-Button umschreiben und mit Javascript beim Click das Eingabefeld auslesen und den gewünschten Request absetzen.

Ja, genau sowas mache ich tatsächlich jetzt. Hat aber etwas damit zu tun, dass die einen Button an einer Stelle erwarten, an der ich ihn nicht setzen konnte, weil es so Form in Form gewesen wäre. Deshalb setze ich dort dann einen Fake-Button hin, nehme den Formularbutton per JS raus und sende das Formular dann so ab.

Insgesamt habe ich die komplette Seite nun so umstrukturiert, dass nur noch 1 Formular existiert.

Allgemein ist das wohl eher keine gute Vorgehensweise, und ich würde das auch nur in kontrollierten Umgebungen (à la Firmenintranet mit vorgeschriebenem Browser) so umsetzen, aber auch nur dann, wenn das Umstrukturieren keine Option ist.

Wäre bei mir zwar gegeben, aber bis auf obigen kunstgriff ist es jetzt html-mäßig in Ordnung.

Pit

[Felix Riesterer]

Lieber Pit,

Ich fand die Pauschalkritik einiger Forenmitglieder an der Dateigröße nicht angemessen

da stimme ich Dir voll und ganz zu. Ich habe auch Script-Dateien mit über 6000 Zeilen (viele Zeilen sind Leerzeilen, man kann das getrost halbieren), die unter Anderem mit PHP-DOM-Methoden HTML erzeugen. Als Grundsätzliche Vorlage lesen sie vorhandene HTML-Dateien als Templates ein um davon DOM-Fragmente zu erstellen, aber eine gesonderte Template-Sprache verwende ich nicht. PHP war in seinen Anfängen als Template-Sprache konzipiert gewesen (daher die <?php und ?> "Tags", sowie <?= und dergleichen mehr), warum es dann nicht "gleich richtig" machen? Immerhin kann man das Ausformulieren des Markups in Funktionen kapseln, denen man die Arbeitsdaten gibt...

Liebe Grüße,

Felix Riesterer.

[Pit]

Hallo Felix,

ich habe nun die Seite so umgebaut, dass sie aus nur noch einem Formular besteht. Es war genauso zum ko...en, wie ichs mir dachte. Nicht wirklich schwierig, als das ich hätte nachfragen müssen, aber mühselig und tricky.

Das lag vor allem daran, dass ich das ursprüngliche innere Formular nicht mehr als Formular nehmen konnte, sondern es nur in das äußere Formular integrieren mußte. Daraus resultierte, dass die Elemente des inneren Formulars, die zuvor sozusagen einen eigenen Submit-Button hatten und somit auch eindeutig beim Server als zu editierend ankamen, nun in Arrays verpackt werden mußten und nur als Summe auf dem Server ankommen. Bischen doof, da man nicht weiß, welche Einträge editiert wurden jund welche einfach unverändert mitgeliefert werden. Da ich aber nicht auf Verdacht alle mitgelieferten Einträge in der DB editieren möchte, habe ich ein verstecktes input-field installiert, in das ich dann per JS die EditID hinein packe, dann weiß ich auf dem Server, welche Zeile wirklich editiert wurde. Dort kann ich dann hierüber die werte aus dem assoziativen Array direkt herauspicken und in der DB ändern. '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.

Ist noch nicht ganz fertig, aber morgen werd ichs wohl fertig stellen.

Ich wollts nur kurz erwähnen, weil Du mal nachgefragt hattest, als ich nicht mehr weiter auf Anregungen und Hilfsangebote eingegangen war.

Also, wie gesagt, so richtig schwierig wars nicht, aber sehr nervig umzusetzen fand ichs schon.

Klar, wenns fertig (oder fast fertig) ist, ist man natürlich froh, dass es valide ist und läuft, aber ich arbeite lieber an anderen Problemstellungen rum als an solchen 😉

Also, auch Dir nochmal danke für die Hilfe,

Pit

[Felix Riesterer]

Lieber Pit,

Daraus resultierte, dass die Elemente des inneren Formulars, die zuvor sozusagen einen eigenen Submit-Button hatten und somit auch eindeutig beim Server als zu editierend ankamen, nun in Arrays verpackt werden mußten und nur als Summe auf dem Server ankommen.

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.

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.

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!

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!

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">

'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. Nun kann man serverseitig auswerten:

$line = false;
$text = false;

foreach (array_keys($_POST) as $key) {
    // check for submit button
    if (substr($key, 0, 4) == 'save') {
        $line = substr($key, 4);
    }
}

if ($line
    && array_key_exists("line-$line", $_POST)
) {
    $text = $_POST["line-$line"];
}

// only save data if suitable data has been received
// even when empty
if ($text !== false) {
    // save contents to DB
    /* UPDATE story
     * SET text = :text
     * WHERE line = :line
     */
}

Obiger Code ist ungetestet, es kann bei den verwendeten Indices für substr() fehlerhaftes herauskommen!

Ich wollts nur kurz erwähnen, weil Du mal nachgefragt hattest, als ich nicht mehr weiter auf Anregungen und Hilfsangebote eingegangen war.

Und das war auch gut so!

Also, wie gesagt, so richtig schwierig wars nicht, aber sehr nervig umzusetzen fand ichs schon.

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

Liebe Grüße,

Felix Riesterer.

[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

[Felix Riesterer]

Lieber Pit,

Vertrau' mir, es ist korrekt.

:-)

Ich weiß genau, was Du meinst und wüßte genau, wie ich es erstelle. (ist auch viel einfacher)

Aha... wenn Du das so schreibst, muss ich Dir das einfach glauben.

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.

Das klingt jetzt nicht logisch.

Die Daten befinden sich übrigens in einer Tabelle, daher Zeilen.

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

Das klingt aber wiederum so, als ob Du die Darstellung der Daten als Tabelle realisiert hast. Dazu gehört dann am Ende der Zeile eine Spalte mit dem Speichern-Button. Ansonsten ergibt die Lösung mit der Tabelle für mich anhand Deiner Beschreibung keinen Sinn.

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.

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. Meiner Meinung nach klingt das nicht sinnvoll. Es sei denn, Du hast am Ende der Zeile noch eine Spalte mit dem Speichern-Button, der zu eben dieser Zeile gehört, so dass klar ist, dass nur die Daten dieser Zeile gespeichert werden.

Ohne JS siehst Du meine Seite GAR NICHT.

Ich sehe sie so oder so GAR NICHT. Das hält mich nicht davon ab, eine Meinung dazu zu haben. ;-) Natürlich alles nur anhand Deiner Beschreibungen.

Und das ist ok so, da ich meinen Nutzerkreis kenne und sie einen Browser und dessen Einstellungen im Zweifel vorgegeben erhalten.

Diese Info ist neu. Prinzipiell darfst und kannst Du tun und lassen, was Du willst, aber wenn Du schon fragst... und dabei spärlich Deinen Anwendungsfall skizzierst... dann kommen eben Vorschläge und Meinungen wie die meine.

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

Aha. Da hätte ich jetzt spontan gesagt, dass Du drei Tabellen benötigst. Für jeden Themenbereich eine. Die Tabelle hat nichts mit der Struktur Deiner DB zu tun, sie ist ein Element der Datenvisualisierung für den Zweck der Bearbeitung dieser Daten.

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

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.

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]".

Nur, ich finds nicht schön und habe mich schon lange gegen so eine Programmierung entschieden.

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

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.

Ist schon OK. Ich muss es ja nicht warten. Ich habe nur gelernt, wie ich eine serverseitige Logik aufbauen muss, damit etwas grundsätzlich nutzbar ist, um es dann mit clientseitiger Logik bequem und intuitiver bedienbar zu gestalten. Das macht richtig Spaß und ist keinesfalls "nervig" in der Erstellung!

Trotzdem danke für Deinen Kommentar,

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

Liebe Grüße,

Felix Riesterer.

[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

[Felix Riesterer]

Lieber Pit,

danke für Deine ausführlichen Erklärungen!

Innerhalb der ersten beiden Themenbereiche darf der User beliebig viele Änderungen (auf einmal) vornehmen.

Aha! Daher also der Sinn, das in einem Formular zusammenzufassen. Klingt logisch.

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.

Klingt für mich nach einem zweiten Formular für diesen 3. Themenbereich.

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

:-)

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.

Natürlich sendet er das Gesamtformular ab. Was soll ein Submit-Button auch anderes tun? Sein Name landet aber in den POST-Daten und daher kann man sehr genau sagen, welcher Button da benutzt wurde, um dann zu sagen, welche Daten man zur Bearbeitung akzeptiert.

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.

Die könnten in "ihrem Formular" stehen, getrennt vom 3. Themenbereich...

Ich denke, jetzt wird deutlicher, warum ich das so gelöst habe.

Es bleiben Fragezeichen. Aber die darfst Du nun behalten.

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

Ist ja schon gut. :-)

Liebe Grüße,

Felix Riesterer.

[Pit]

Hi Felix,

danke für Deine ausführlichen Erklärungen!

Gern geschehen. 😀

Innerhalb der ersten beiden Themenbereiche darf der User beliebig viele Änderungen (auf einmal) vornehmen.

Aha! Daher also der Sinn, das in einem Formular zusammenzufassen. Klingt logisch.

Jups...

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.

Klingt für mich nach einem zweiten Formular für diesen 3. Themenbereich.

Wo innerhalb einer Tabelle darf ich form-tags setzen und muss ein Submitbutton innerhalb der form-Tags stehen? Denn Voraussetzung ist und bleibt, dass die Tabelle eine Tabelle ohne Lücken bleibt. Wenn das geht, wäre tatsächlich ein 2. Formular nur für den Themenbereich 3 brauchbar gewesen und ich fänds noch schöner als meine jetztige Lösung.

Natürlich sendet er das Gesamtformular ab. Was soll ein Submit-Button auch anderes tun?

😉

Sein Name landet aber in den POST-Daten und daher kann man sehr genau sagen, welcher Button da benutzt wurde, um dann zu sagen, welche Daten man zur Bearbeitung akzeptiert.

Krieg ich auch ohne den Namen des Buttons raus 😜

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.

Die könnten in "ihrem Formular" stehen, getrennt vom 3. Themenbereich...

Nochmal... wenn Du mir sagst, wie ich 2 Formulare in eine nahtlose Tabelle schreibe und unter die Tabelle, also unterhalb der beiden Formulare einen Button zum Absenden des Formulars der Themenbereiche 1+2 mache, fänd ich diese Lösung richtig gut und sogar besser als meine. Aber ich glaube, da wirst Du auch z.b. ohne JS-seitiges Formularabsenden nicht arbeiten können...

Gruß, Pit

[Matthias Apsel]

Hallo Pit,

Wo innerhalb einer Tabelle darf ich form-tags setzen

nur in td und tr

und muss ein Submitbutton innerhalb der form-Tags stehen?

Nein.

Bis demnächst
Matthias

[Pit]

Hallo Matthias,

Wo innerhalb einer Tabelle darf ich form-tags setzen

nur in td und tr

Das ist ungünstig für mich, meine Tabelle hat diese Struktur. Das Setzen mehrerer tbodys hat den Zwecke, dass ich zusammengehörige Tabellenzeilen gebündelt habe, um das Verschieben mittels Jquery auf diese zusammengehörigen zeilen anzuwenden.

Gruß, Pit

[Gunnar Bittersmann]

@@Matthias Apsel

Wo innerhalb einer Tabelle darf ich form-tags setzen

nur in td und tr

tr? Du meintest vermutlich td und th.

und muss ein Submitbutton innerhalb der form-Tags stehen?

Nein.

Mit „innerhalb der form-Tags“ war vermutlich zwischen > und </, nicht zwischen < und > gemeint.

Dann: Ja, muss er. Was sollte der Button sonst auch submitten?

LLAP 🖖

[Pit]

Hi Gunnar,

nur in td und tr

tr? Du meintest vermutlich td und th.

Ich müßte mehrere tbodys im Formular zusammenfassen...

und muss ein Submitbutton innerhalb der form-Tags stehen?

Nein.

Mit „innerhalb der form-Tags“ war vermutlich zwischen > und </, nicht zwischen < und > gemeint.

Dann: Ja, muss er. Was sollte der Button sonst auch submitten?

Gemeint war: <form...> </form> <button> oder <form...><button></form> ? Weil: Ich bräuchte ja dann auf jeden Fall Variante 1, wenn auch mit JS…

Pit

[Felix Riesterer]

Lieber Pit,

ein Submit-Button kann nur das Formular absenden, innerhalb dessen er notiert ist. Logisch, oder nicht?

Gemeint war: <form...> </form> <button> oder <form...><button></form> ?

Ersteres Formular hat keinen Button und der Button hat kein Formular, welches er abschicken könnte. Zweiteres ist das, was Du benötigst.

Weil: Ich bräuchte ja dann auf jeden Fall Variante 1, wenn auch mit JS…

Keine Ahnung was Du brauchst. Du kannst mit JavaScript grundsätzlich alles tun... Mach' halt was Du willst!

Liebe Grüße,

Felix Riesterer.

[Matthias Apsel]

Hallo Felix Riesterer,

Ersteres Formular hat keinen Button und der Button hat kein Formular, welches er abschicken könnte. Zweiteres ist das, was Du benötigst.

<button form="myform">myform absenden</button>

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Pit

Ich müßte mehrere tbodys im Formular zusammenfassen...

Gemeint war: <form...> </form> <button> oder <form...><button></form> ? Weil: Ich bräuchte ja dann auf jeden Fall Variante 1, wenn auch mit JS…

Was du vermutlich nicht brauchst: eine Tabelle. Wenn es dir um die visuelle Darstellung geht, ist Grid dein Freund.

Ein Button innerhalb eines Formulars ist ein Submit-Button (wenn ihm nichts anderes gesagt wurde).

Ein Button außerhalb eines Formulars ist ein Button.

Einen Button außerhalb eines Formulars per JavaScript zum Absenden eines Forumulars irgendwo ganz anders im DOM zu verwenden, klingt ziemlich krude.

Ich hab allerdings nicht deine ellenlangen Erklärungsversuche verfolgt, waum du denkst, dass dies nötig wäre. Hast du nicht ein abgespecktes anschauliches Beispiel parat, was du da zusammenbaust?

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ein Button außerhalb eines Formulars ist ein Button.

Mit dem form-Attribut lässt er sich einem Formular zuordnen.

Einen Button außerhalb eines Formulars per JavaScript zum Absenden eines Forumulars irgendwo ganz anders im DOM zu verwenden, klingt ziemlich krude.

Das geht auch ohne JS.

Bis demnächst
Matthias

[Pit]

Hi Gunnar,

Was du vermutlich nicht brauchst: eine Tabelle. Wenn es dir um die visuelle Darstellung geht, ist Grid dein Freund.

Es sind tabellarische Daten. Für die nimmt man doch Tabellen.

Ich hab allerdings nicht deine ellenlangen Erklärungsversuche verfolgt, waum du denkst, dass dies nötig wäre. Hast du nicht ein abgespecktes anschauliches Beispiel parat, was du da zusammenbaust?

Das wäre sicher sinnvoll, klar. Ist aber inzwischen nicht mehr nötig, weil ich gestern schon die Lösung erstellt habe. Mir gefiehl nur die Möglichkeit, die Tabelle ggf. zu zweiteilen, dafür hätte ich emine Lösung nochmal umgebaut. Wenn das aber nicht geht, lebe ich mit meiner Lösung von gestern sicher sehr gut, die läuft in dieser Form in einem anderen Script bereits seit x Jahren ohne Fehler.

Trotzdem danke für Deine hilfe, Pit

[Matthias Apsel]

Hallo Gunnar Bittersmann,

tr? Du meintest vermutlich td und th.

Ja.

und muss ein Submitbutton innerhalb der form-Tags stehen?

Nein.

Mit „innerhalb der form-Tags“ war vermutlich zwischen > und </, nicht zwischen < und > gemeint.

Dann: Ja, muss er. Was sollte der Button sonst auch submitten?

Nein, das form-Attribut existiert.

Bis demnächst
Matthias