SELFHTML Forum
SELFHTML Forumsarchiv
2007
November
 |
SELFHTML Forumsarchiv |
 |
|
 |
|
Die folgende Nachricht zum Thema stammt von: André Bräkling, 29. 11. 2007, 18:55
Hallo zusammen,
ich habe ein Schachbrett zusammengeschustert und möchte nun eine Funktion implementieren, die es ermöglicht, dass Brett umzudrehen. Per Default ist weiß unten, durch einen Klick auf einen Button soll schwarz unten stehen. Immerhin soll es Spieler geben, die grundsätzlich von unten nach oben spielen wollen - ungeachtet ihrer Farbe.
Das "Drehen an sich" funktioniert mit dieser Funktion einwandfrei:
function rotatetab () {
gameTab = document.getElementById("gametab");
var aryRows = gameTab.rows;
var intRows = aryRows.length;
var aryNew = new Array(intRows);
for (var i = 0; i < intRows; i++) {
aryNew[intRows-i-1] = aryRows[0];
gameTab.deleteRow(0);
}
for (var i = 0; i < intRows; i++) {
gameTab.appendChild(aryNew[i]);
}
}
Leider kann ich diese Funktion aber nicht benutzen, um die Tabelle "zurückzudrehen", da durch appendChild keine neuen Rows angelegt werden (gameTab.rows bleibt leer), obwohl die Objekte der Tabelle hinzugefügt werden.
Zwar gibt es eine Funktion HTMLTableElement.insertRow, doch diese erzeugt eine leere Zeile, zu der ich dann wieder einzeln meine Zellen hinzufügen muss. Ich möchte jedoch möglichst unkompliziert meine in aryNew gespeicherten HTMLTableRowElement-Objekte an die Tabelle anhängen.
Aktuell sehe ich also nur folgende Möglichkeiten:
1. Die HTMLTableRowElement-Objekte komplett zerlegen (Cells, Attributes, ...), per insertRow eine neue Zeile erzeugen und diese dann aus dem zuvor zerlegten Objekt neu erstellen. (Ich hoffe man versteht, was ich meine.) -> Umständlich.
2. Per appendChild das gesamte HTMLTableRowElement einfügen. -> Es werden keine wirklichen Rows angelegt (siehe oben erläutertes Problem).
Ich suche also eine Möglichkeit, ein bestehendes HTMLTableRowElement-Objekt als ganzes in eine bestehende Tabelle als "echte Row" einzufügen, so dass meine obige Funktion auch umgekehrt funktioniert. Oder halt eine alternative Lösung ;-)
Wäre Klasse, wenn hier jemand eine passende Idee hat, durch die ich den JavaScript-Code auf der Seite nicht unnötig aufblähe. Ich kann mir irgendwie nicht vorstellen, dass es dafür keine brauchbare Lösung gibt.
Danke im vorraus!
Die folgende Nachricht zum Thema stammt von: Vinzenz Mai, 29. 11. 2007, 19:18
Hallo
»» Das "Drehen an sich" funktioniert mit dieser Funktion einwandfrei:
»»
»» function rotatetab () {
»»
»» gameTab = document.getElementById("gametab");
»»
»» var aryRows = gameTab.rows;
»» var intRows = aryRows.length;
»» var aryNew = new Array(intRows);
»»
»» for (var i = 0; i < intRows; i++) {
»» aryNew[intRows-i-1] = aryRows[0];
»» gameTab.deleteRow(0);
»» }
»»
»» for (var i = 0; i < intRows; i++) {
»» gameTab.appendChild(aryNew[i]);
»» }
»» }
»»
»» Leider kann ich diese Funktion aber nicht benutzen, um die Tabelle "zurückzudrehen", da durch appendChild keine neuen Rows angelegt werden (gameTab.rows bleibt leer), obwohl die Objekte der Tabelle hinzugefügt werden.
der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:
/2006/7/t133604/#m866116
/archiv/2007/2/t146811/#m952738
Freundliche Grüße
Vinzenz
Die folgende Nachricht zum Thema stammt von: André Bräkling, 29. 11. 2007, 19:24
»» der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:
Argh, vielen lieben Dank! Manchmal ist die Lösung so nah...
Wenn mal wieder jemand das Problem hat - so geht's natürlich:
function switchtab () {
gameTab = document.getElementById("gametabbody");
var aryRows = gameTab.rows;
var intRows = aryRows.length;
var aryNew = new Array(intRows);
for (var i = 0; i < intRows; i++) {
aryNew[intRows-i-1] = aryRows[0];
gameTab.deleteRow(0);
}
for (var i = 0; i < intRows; i++) {
gameTab.appendChild(aryNew[i]);
}
}
<table id="gametab">
<tbody id="gametabbody">
<tr>...</tr>
...
<tr>...</tr>
</tbody>
</table>
Die folgende Nachricht zum Thema stammt von: Timo "God's Boss" Reitz, 29. 11. 2007, 19:33
»» der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:
»» /2006/7/t133604/#m866116
»» /archiv/2007/2/t146811/#m952738
Diese Aussage ist in ihrer Absolutheit leider falsch. In HTML gilt das zweifelsfrei und ohne Ausnahme, in XHTML kann tr jedoch Kind von table sein, dort gibt es keine optionale Notation von Elementen, entweder sie sind da oder nicht.
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
Die folgende Nachricht zum Thema stammt von: ChrisB, 29. 11. 2007, 20:18
Hi,
»» »» tr ist kein Kind von table sondern von tbody [...]
»» Diese Aussage ist in ihrer Absolutheit leider falsch. In HTML gilt das zweifelsfrei und ohne Ausnahme, in XHTML kann tr jedoch Kind von table sein, dort gibt es keine optionale Notation von Elementen, entweder sie sind da oder nicht.
Kommt auf die Betrachtungsweise an - aus HTML-DOM-Sicht, und damit der heute ueblicher Implementierungen in HTML-UAs stimmt Vinzenz' Aussage, denn http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_11 besagt:
»» "1. User agents that access XHTML documents served as Internet media type text/html via the DOM can use the HTML DOM [...]"
Sofern der UA das macht, stimmt das gesagte also aus DOM-Sicht m.E.
Wenn wirklich XML-DOM genutzt wird, sieht es anders aus:
»» "2. [...] Also, some XHTML elements may or may not appear in the object tree because they are optional in the content model (e.g. the tbody element within table). This occurs because in HTML 4 some elements were permitted to be minimized such that their start and end tags are both omitted (an SGML feature). This is not possible in XML. Rather than require document authors to insert extraneous elements, XHTML has made the elements optional. User agents need to adapt to this accordingly."
Ich habe allerdings noch nicht ausprobiert, wie real existierende, X(HT)ML verarbeitende UAs das in der Praxis umsetzen.
MfG ChrisB
Die folgende Nachricht zum Thema stammt von: Vinzenz Mai, 29. 11. 2007, 20:45
Hallo
»» »» der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:
»» »» /archiv/2006/7/t133604/#m866116
»» »» /archiv/2007/2/t146811/#m952738
»» Diese Aussage ist in ihrer Absolutheit leider falsch.
die Aussage ist nicht absolut, sie bezieht sich auf den vorliegenden Code, sie
steht im Kontext der verlinkten Threads und steht unter der Kategorie "Javascript" und nicht unter der Kategorie HTML/XHTML.
Sie bezieht sich auf die heutige Umsetzung von DOM/Javascript in heute üblichen Browsern.
Freundliche Grüße
Vinzenz
Die folgende Nachricht zum Thema stammt von: Timo "God's Boss" Reitz, 30. 11. 2007, 16:11
»» »» Diese Aussage ist in ihrer Absolutheit leider falsch.
»» die Aussage ist nicht absolut, sie bezieht sich auf den vorliegenden Code, sie
»» steht im Kontext der verlinkten Threads und steht unter der Kategorie "Javascript" und nicht unter der Kategorie HTML/XHTML.
Und wie sollte nun jemand darauf kommen, dass es in XHTML eben anders sein kann?
»» Sie bezieht sich auf die heutige Umsetzung von DOM/Javascript in heute üblichen Browsern.
Wenn ich in XHTML kein tbody-Element verwende, ist im Firefox (ein heute üblicher Browser) auch keines im DOM-Baum.
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
Die folgende Nachricht zum Thema stammt von: Vinzenz Mai, 30. 11. 2007, 17:52
Hallo Timo,
»» Wenn ich in XHTML kein tbody-Element verwende, ist im Firefox (ein heute üblicher Browser) auch keines im DOM-Baum.
das kann ich nicht nachvollziehen:
Die Forumshauptdatei hier verwendet XHTML 1.0 strict, es gibt eine Tabelle mit
der id="kopf", diese enthält im XHTML-Quelltext _kein_ tbody-Element, im DOM-Baum meines Firefox 2.0.0.10 sehe ich hingegen das tbody-Element, die tr-Elemente sind Kindelemente dieses tbody-Elementes.
Deswegen gehe ich davon aus, dass Du schon wieder daneben liegst :-)
Grüße
Vinzenz
Die folgende Nachricht zum Thema stammt von: Timo "God's Boss" Reitz, 02. 12. 2007, 04:16
»» das kann ich nicht nachvollziehen:
»» Die Forumshauptdatei hier verwendet XHTML 1.0 strict, es gibt eine Tabelle mit
»» der id="kopf", diese enthält im XHTML-Quelltext _kein_ tbody-Element, im DOM-Baum meines Firefox 2.0.0.10 sehe ich hingegen das tbody-Element, die tr-Elemente sind Kindelemente dieses tbody-Elementes.
»» Deswegen gehe ich davon aus, dass Du schon wieder daneben liegst :-)
Ich liege nicht daneben, schon gar nicht wieder. Das tbody-Element wird hinzugefügt, weil die Seite vom Firefox als text/html verarbeitet wird.
Vergleiche folgende Seiten:
http://www.godsboss.de/test/tbody/table_tbody.html
http://www.godsboss.de/test/tbody/table_tbody.xhtml
Beide Dokumente sind vom Inhalt her identisch, beide sind valide. Die generierten DOM-Bäume unterscheiden sich allerdings im Firefox. Insbesondere wird beim als text/html gesendeten Dokument ein tbody-Element generiert, beim als application/xhtml+xml gesendeten Dokument hingegen nicht.
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
© 1998-2006 
Impressum, Software: Classic Forum
(JAVASCRIPT)