nicht angemeldet
[XHTML] eine Tabelle mit einem Formular pro Zeile
Hallo,
habe hier mal wieder ein Codeproblem. Ich verwende eine Tabelle, die eine Kopfzeile hat und möchte unter der Kopfzeile pro Zeile ein Formular reinsetzen. Also sinngemäß so:
<table>
<colgroup ... />
<tr>
<th>Titel 1</th>
<th>Titel 2</th>
<th>Titel 3</th>
</tr>
<form ...>
<tr>
<td><input ... /></td>
<td><input ... /></td>
<td><input submit... /></td>
</tr>
</form>
<form ...>
<tr>
<td><input ... /></td>
<td><input ... /></td>
<td><input submit... /></td>
</tr>
</form>
</table>
Das ist natürlich kein valides XHTML 1.1, wie ich es gerne hätte. Das form-Tag darf kein Kind-Element von <table> oder <tr> sein, nur von <th> oder <td>.
Nun könnte ich immer ein <td> erstellen, dass sich über die gesamte Tabellenbreite erstreckt und darin eine neue Tabelle platzieren.
Also etwa so:
<table>
<colgroup ... />
<tr>
<th>Titel 1</th>
<th>Titel 2</th>
<th>Titel 3</th>
</tr>
<td colspan="alle">
<form ...>
<table>
<colgroup ... />
<tr>
<td><input ... /></td>
<td><input ... /></td>
<td><input submit... /></td>
</tr>
</table>
</form>
</td>
<td colspan="alle">
<form ...>
<table>
<colgroup ... />
<tr>
<td><input ... /></td>
<td><input ... /></td>
<td><input submit... /></td>
</tr>
</table>
</form>
</td>
</table>
Aber das ist ist m. E. unsinnig, weil unflexibel, zwangsläufig redundant und auch noch aufgeblasen und hässlich.
Ich könnte die Tabelle auch nach dem Kopf abschließen und eine neue Tabelle erstellen.
Also:
<table>
<colgroup ... />
<tr>
<th>Titel 1</th>
<th>Titel 2</th>
<th>Titel 3</th>
</tr>
</table>
<form ...>
<table>
<colgroup ... />
<tr>
<td><input ... /></td>
<td><input ... /></td>
<td><input submit... /></td>
</tr>
</table>
</form>
<form ...>
<table>
<colgroup ... />
<tr>
<td><input ... /></td>
<td><input ... /></td>
<td><input submit... /></td>
</tr>
</table>
</form>
</table>
was aber den Sinn eines Tabellenkopfes irgendwie vollkommen aushebelt.
Und es kommen auch nicht unterschiedliche Submitbuttons für ein- und dasselbe Formular in Frage - dann rechnet der Server nämlich nach 2 Stunden noch...
Hat irgendjemand nen kreativen Vorschlag? Bin für jede Anregung dankbar.
-
<yoeto>
Hat irgendjemand nen kreativen Vorschlag? Bin für jede Anregung dankbar.
So direkt nicht, da müßte man dein Problem etwas genauer kennen. Eventuell ließe sich um dein Problem herumarbeiten, indem du anstelle des Submit-Buttons in jeder Zeile einen Radiobutton anbietest und am Fuß der Angelegenheit den Submit-Button. Ich könnte mir auch vorstellen, dass sich das Problem per JavaScript lösen läßt, was aber auch nicht optimal ist.
Vermutlich wirst du um eine konzeptionelle Neuplanung nicht herumkommen. Wir sind gerne behilflich, wenn du uns dein Vorhaben beschreiben willst.
</yoeto>
--
<signatur />
ie:% fl:( br:< va:| ls:~ fo:{ rl:? n4:( ss:{ de:] js:( ch:] mo:| zu:)-
Hat irgendjemand nen kreativen Vorschlag? Bin für jede Anregung dankbar.
So direkt nicht, da müßte man dein Problem etwas genauer kennen. Eventuell ließe sich um dein Problem herumarbeiten, indem du anstelle des Submit-Buttons in jeder Zeile einen Radiobutton anbietest und am Fuß der Angelegenheit den Submit-Button. Ich könnte mir auch vorstellen, dass sich das Problem per JavaScript lösen läßt, was aber auch nicht optimal ist.
Das mit den Radio-Buttons klingt gar nicht schlecht. Würde ich jetzt vielleicht als Lösung nehmen. Habe aber eben einen einfachen Weg gefunden, das Problem von vornherein zu vermeiden.
Vermutlich wirst du um eine konzeptionelle Neuplanung nicht herumkommen. Wir sind gerne behilflich, wenn du uns dein Vorhaben beschreiben willst.
Danke. Hat sich aber erledigt. :) (Btw: Ich entwerfe grad einen Onlineshop)
-
-
Hallo Mr. Anderson.
Das ist natürlich kein valides XHTML 1.1, […]
Warum verwendest du das problematische XHTML 1.1 und nicht XHTML 1.0 Strict?
Ich könnte die Tabelle auch nach dem Kopf abschließen und eine neue Tabelle erstellen.
Und warum packst du nicht einfach die gesamte Tabelle (inkl. Kopf) ins form-Element?
Einen schönen Dienstag noch.
Gruß, Ashura
--
sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
„It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
[HTML Design Constraints: Logical Markup]-
hi,
Das ist natürlich kein valides XHTML 1.1, […]
Warum verwendest du das problematische XHTML 1.1 und nicht XHTML 1.0 Strict?
Nur zur Klarstellung: Auch dort hätte form an der Stelle nix verloren.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; } -
Warum verwendest du das problematische XHTML 1.1 und nicht XHTML 1.0 Strict?
Es ist völlig egal ist, ob ich XHTML 1.0 oder 1.1 oder HTML 4.0 oder sonstwas nehme. Das Problem ist überall das Gleiche. Davon abgesehen verwende ich derzeit nichts, was von den Unterschieden zwischen XHTML 1.0 Strict und XHTML 1.1 betroffen wäre.
Und warum packst du nicht einfach die gesamte Tabelle (inkl. Kopf) ins form-Element?
Weil ich dann nur ein Formular habe und nicht beliebig viele.
Grüße,
Mr. Anderson-
Hallo,
Davon abgesehen verwende ich derzeit nichts, was von den Unterschieden zwischen XHTML 1.0 Strict und XHTML 1.1 betroffen wäre.
Aha, dann kennst du wohl <html lang="de"> noch nicht, was Screenreadern wirklich weiterhilft, was die Spracherkennung angeht... Es gibt weitere triviale Beispiele für Unterschiede, die dich tangieren sollten, die findest du wie gesagt im Archiv.
Mathias
-
Davon abgesehen verwende ich derzeit nichts, was von den Unterschieden zwischen XHTML 1.0 Strict und XHTML 1.1 betroffen wäre.
Aha, dann kennst du wohl <html lang="de"> noch nicht, was Screenreadern wirklich weiterhilft, was die Spracherkennung angeht... Es gibt weitere triviale Beispiele für Unterschiede, die dich tangieren sollten, die findest du wie gesagt im Archiv.
Hm. Mal sehen... doch die kenne ich sogar... könnte daran liegen, dass ich mich auf den Seiten der w3c informiert habe. Verwende ich das lang-Attribut gerade? Nein... Insbesondere auf einer Seite, auf der Fotos und Poster von Sehenswürdigkeiten verkauft werden, hat das keine hohe Priorität.
Was soll mich denn noch tangieren? Ruby? Ein name-Attribut? (btw: Wonach soll ich denn suchen, um diese trivialen Beispiele für Unterschiede, die mich tangieren sollten, im Archiv zu finden)Ich hab ernsthaft nach nem Vorschlag für diese eine spezielle Sache gesucht. Warum schreibst Du mir jetzt vor, wie ich alles andere zu tun habe?
-
Hallo,
Ich hab ernsthaft nach nem Vorschlag für diese eine spezielle Sache gesucht. Warum schreibst Du mir jetzt vor, wie ich alles andere zu tun habe?
Ich schreibe dir gar nichts vor, ich sage dir nur, welche Vorteile es hat, die Möglichkeiten von XHTML 1.0 zu nutzen, die XHTML 1.1 nicht bietet. Wenn du keinen Wert auf Barrierefreiheit und damit auf korrekte Sprachauszeichnung legst, gut, deine Sache.
Das besagte name-Attribut z.B. bei form und img ist relevant, wenn du abwärtskompatible JavaScripte schreiben möchtest. Und selbiges beim a-Element, wenn du abwärtskompatible Linkanker setzen willst. Image-Maps sind auch unmöglich, weil das usemap-Attribut anders funktioniert. applet und iframe sind unmöglich, weil es kein Transitional in XHTML 1.1 gibt (bekanntlich funktioniert object nicht immer gleichermaßen). Nicht zuletzt entspricht es keinen Standard, XHTML 1.1 als text/html auszuliefern, das W3C rät sogar davon ab.
Mathias
-
Ich schreibe dir gar nichts vor,
Dann entschuldige bitte. Es klang so.
ich sage dir nur, welche Vorteile es hat, die Möglichkeiten von XHTML 1.0 zu nutzen, die XHTML 1.1 nicht bietet. Wenn du keinen Wert auf Barrierefreiheit und damit auf korrekte Sprachauszeichnung legst, gut, deine Sache.
Prinzipiell lege ich schon Wert darauf, aber auf dieser speziellen Seite genießt das nunmal eine geringere Priorität als sonst. Btw: Auch Screenreader dürfen allmählich XML und XHTML verstehen. Das gibt es schließlich nicht seit gestern.
Das besagte name-Attribut z.B. bei form und img ist relevant, wenn du abwärtskompatible JavaScripte schreiben möchtest. Und selbiges beim a-Element, wenn du abwärtskompatible Linkanker setzen willst. Image-Maps sind auch unmöglich, weil das usemap-Attribut anders funktioniert. applet und iframe sind unmöglich, weil es kein Transitional in XHTML 1.1 gibt (bekanntlich funktioniert object nicht immer gleichermaßen). Nicht zuletzt entspricht es keinen Standard, XHTML 1.1 als text/html auszuliefern, das W3C rät sogar davon ab.
Nun, JavaScript ist bisher nicht geplant. Und wenn da noch was dazukommt, so wird es kein Beinbruch sein, wenn es in alten Browsern, die meist sowieso nicht standardkonform interpretieren können, nicht funktioniert.
Applets sind nicht geplant. Und IFrames lehne ich ab.
XHTML als text/html zu kennzeichnen, ist, so wie ich das verstehe, widersprüchlich bewertet vom w3c, aber bei XHTML 1.0 Strict ist es immer gleichermaßen wie bei XHTML 1.1.
Mal heißt es, wenn man einen guten Grund hat, ist es noch standardkonform text/html zu verwenden. Mal heißt es, dass es strickt untersagt ist. Naja, ich werde es mit application/xhtml+xml versuchen, und wenn das zu große Probleme gibt, probiere ich halt text/html. Wird sich zeigen.Grüße,
Mr. Anderson
-
-
-
-
-
-
Hallo,
Das Problem hat nichts mit XHTML zu tun. Und warum du XHTML 1.1 vermeiden solltest, kannst du im Forumsarchiv recherchieren.
Deine Frage wurde hier schon öfters gestellt. Die gängige Lösung ist: Verwende in Formular, das die gesamte Tabelle umspannt, und gebe den Submit-Buttons andere Namen, den zugehörigen Feldern einen entsprechenden Bezeichner, sodass die die Felder dem Submit-Button zuordnen kannst.
Und es kommen auch nicht unterschiedliche Submitbuttons für ein- und dasselbe Formular in Frage - dann rechnet der Server nämlich nach 2 Stunden noch...
Dann ist die Software auf dem Server mangelhaft. Ändere sie entsprechend, sodass sie nur die Formularfelder bearbeitet, die zum gedrückten Submitbutton gehören. Möglich ist das jedenfalls.
Unschön ist eher, dass alle Formulardaten übertragen werden müssen. Deshalb nutzt man für solche Zwecke verstärkt JavaScript und XMLHttpRequest, um nur die relevanten Formulardaten auszulesen und per POST zum Server zu übertragen.
Mathias
-
Deine Frage wurde hier schon öfters gestellt. Die gängige Lösung ist: Verwende in Formular, das die gesamte Tabelle umspannt, und gebe den Submit-Buttons andere Namen, den zugehörigen Feldern einen entsprechenden Bezeichner, sodass die die Felder dem Submit-Button zuordnen kannst.
Dann ist die Software auf dem Server mangelhaft. Ändere sie entsprechend, sodass sie nur die Formularfelder bearbeitet, die zum gedrückten Submitbutton gehören. Möglich ist das jedenfalls.
Die Software ist noch gar nicht geschrieben. Ich plane lediglich. Die Felder dem Submit-Button zuzuordnen und die restlichen nicht zu bearbeiten, ist kein Problem. Aber wie finde ich denn heraus, welcher Submitbutton gedrückt wurde, wenn also die Beschriftung (value) überall gleich sein soll und der Name (name) jeweils anders ohne eine lineare Laufzeit zu bekommen?
Unschön ist eher, dass alle Formulardaten übertragen werden müssen.
Das auch...
»»Deshalb nutzt man für solche Zwecke verstärkt JavaScript und XMLHttpRequest, um nur die relevanten Formulardaten auszulesen und per POST zum Server zu übertragen.
JavaScript hat IMO in funktionalen Bestandteilen nichts zu suchen.
-
hi,
Aber wie finde ich denn heraus, welcher Submitbutton gedrückt wurde, wenn also die Beschriftung (value) überall gleich sein soll
Muss sie das denn?
und der Name (name) jeweils anders ohne eine lineare Laufzeit zu bekommen?
Du kannst ja Namen in der Form name="submit[xy]" benutzen.
In PHP beispielsweise bekämst du damit unterhalb von $_POST['submit'] ein Array mit genau einem Element - nämlich dem jeweiligen xy.
In anderen serverseitigen Sprachen gibt's bestimmt ähnliche Möglichkeiten.gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
hi,
Aber wie finde ich denn heraus, welcher Submitbutton gedrückt wurde, wenn also die Beschriftung (value) überall gleich sein soll
Muss sie das denn?
Naja, es wäre in dem Fall komisch, wenn sie es nicht wäre.
und der Name (name) jeweils anders ohne eine lineare Laufzeit zu bekommen?
Du kannst ja Namen in der Form name="submit[xy]" benutzen.
In PHP beispielsweise bekämst du damit unterhalb von $_POST['submit'] ein Array mit genau einem Element - nämlich dem jeweiligen xy.
In anderen serverseitigen Sprachen gibt's bestimmt ähnliche Möglichkeiten.Eigentlich eine gute Idee. Aber woher weiß ich, wie der Schlüssel heißt, der sich als einziger in dem Array befindet?
Naja, ist alles nicht mehr so wichtig. Hab ja ne Lösung, bei der das alles einfach umgangen wird.
-
hi,
Eigentlich eine gute Idee. Aber woher weiß ich, wie der Schlüssel heißt, der sich als einziger in dem Array befindet?
foreach($array as $key => $value) { ... }
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
hi,
Eigentlich eine gute Idee. Aber woher weiß ich, wie der Schlüssel heißt, der sich als einziger in dem Array befindet?
foreach($array as $key => $value) { ... }
gruß,
wahsagalol. Klar. Da stand ich etwas auf dem Schlauch. ^^
Grüße,
Mr. Anderson
-
-
-
-
Hallo,
Die Felder dem Submit-Button zuzuordnen und die restlichen nicht zu bearbeiten, ist kein Problem. Aber wie finde ich denn heraus, welcher Submitbutton gedrückt wurde, wenn also die Beschriftung (value) überall gleich sein soll
Das darf er dann auch nicht.
<input type="submit" name="submit_nr1234" value="Der Beschriftung ist beliebig, der Name sollte die Information enthalten">
Auch hier kannst du ein JavaScript hinzufügen, welches dir die Suche nach dem submit_nrXXXX in den POST-Parametern *vereinfacht* (andernfalls muss du $_POST durchlaufen und suchen).und der Name (name) jeweils anders ohne eine lineare Laufzeit zu bekommen?
Den Satzteil verstehe ich nicht, was ist eine lineare Laufzeit?
Deshalb nutzt man für solche Zwecke verstärkt JavaScript und XMLHttpRequest, um nur die relevanten Formulardaten auszulesen und per POST zum Server zu übertragen.
JavaScript hat IMO in funktionalen Bestandteilen nichts zu suchen.
Im Gegenteil, JavaScript kommt erst in »funktionalen Bestandteilen« zur Entfaltung. Ich habe nicht gesagt, dass du nur die JavaScript-Methoden verwenden sollst. Aber wenn JavaScript zur Verfügung steht, dann kannst du JavaScript auch nutzen, um dir unnötige Kommunikation zwischen Browser und Webserver zu sparen. Die Alternative ist dann halt, dass das gesamte Formular abgesendet wird. Auch kein Beinbruch, wenn du da nicht gerade hunderte Kilobyte Daten übertragen willst (ich nehme an, es geht darum, ein Produkt in den Warenkorb zu legen, da du von einem Shop sprachst).
Mathias
-
Hallo,
Die Felder dem Submit-Button zuzuordnen und die restlichen nicht zu bearbeiten, ist kein Problem. Aber wie finde ich denn heraus, welcher Submitbutton gedrückt wurde, wenn also die Beschriftung (value) überall gleich sein soll
Das darf er dann auch nicht.
<input type="submit" name="submit_nr1234" value="Der Beschriftung ist beliebig, der Name sollte die Information enthalten">
Auch hier kannst du ein JavaScript hinzufügen, welches dir die Suche nach dem submit_nrXXXX in den POST-Parametern *vereinfacht* (andernfalls muss du $_POST durchlaufen und suchen).und der Name (name) jeweils anders ohne eine lineare Laufzeit zu bekommen?
Den Satzteil verstehe ich nicht, was ist eine lineare Laufzeit?
Angenommen, man hat n submit-Buttons. Wenn es im Durchschnitt (oder im schlimmsten Fall - das ist Definitionssache) k * n Vergleiche benötigt, um den richtigen Button zu finden, so ist die Laufzeit linear. (Dabei ist k eine konstante Zahl größer 0)
Wenn man die POST-Anfrage durchlaufen muss, wird man durchschnittlich 0,5 * n Schritte benötigen.
Gegenbeispiel: konstante Laufzeit erreicht man, wenn man sofort weiß, welcher Button gedrückt wurde. Hierfür benötigt man nämlich 0 Vergleiche.JavaScript hat IMO in funktionalen Bestandteilen nichts zu suchen.
Im Gegenteil, JavaScript kommt erst in »funktionalen Bestandteilen« zur Entfaltung. Ich habe nicht gesagt, dass du nur die JavaScript-Methoden verwenden sollst. Aber wenn JavaScript zur Verfügung steht, dann kannst du JavaScript auch nutzen, um dir unnötige Kommunikation zwischen Browser und Webserver zu sparen. Die Alternative ist dann halt, dass das gesamte Formular abgesendet wird. Auch kein Beinbruch, wenn du da nicht gerade hunderte Kilobyte Daten übertragen willst (ich nehme an, es geht darum, ein Produkt in den Warenkorb zu legen, da du von einem Shop sprachst).
Nunja, ich brauche aber eine Basis, die ohne JavaScript auskommt und trotzdem nach meinen Vorstellungen funktioniert. Wenn JavaScript dann noch etwas verbessern kann, darf es das gerne. Was ich aber meine: Es darf ohne JavaScript nicht die Funktion der eigentlichen Sache verhindert werden. Man muss eine Seite immer noch vernünftig bedienen können, wenn JavaScript abgeschaltet oder nicht implementiert ist.
-
-
-