Informationen für Javascript auszeichnen

[wahsaga]

hi,

ich erstelle serverseitig eine Tabelle, die ein Verzeichnislisting enthält, mit dem "üblichen" Aufbau - Name, Größe, Änderungsdatum, etc.
Diese Tabelle möchte ich nun clientseitig nach verschiedenen Kriterien sortierbar machen.

Die für die jeweilige Sortierung relevanten Werte kann ich ja im Falle des Dateinamens ganz einfach auslesen - aber für Größe und Datum ist das nicht so einfach, weil diese natürlich "schön" formatiert dargestellt werden sollen - Größe ja nachdem in Bytes, KB oder MB, und das Datum natürlich auch in lesbarer Form.
Auch letztere kann ich natürlich im Javascript aus den jeweiligen Zellen auslesen - aber die Werte sind zum sortieren denkbar ungeeignet; Bei der Größe gibt es Genauigkeitsverluste durch Rundung, und um ein lesbares Datum sortieren zu können, müsste man es auch erst wieder konvertieren.

Deshalb will ich die Originalgröße in Bytes sowie den UNIX-Timestamp der letzten Änderung gerne auch irgendwie schon im HTML-Code unterbringen, um per Javascript simpleren Zugriff auf die relevanten Werte zu haben.

Klar könnte ich da in die jeweiligen Zellen noch ein per CSS verstecktes span o.ä. einbauen - aber das scheint mir nicht sonderlich schön.

Welche Attribute stellt mir HTML zur Verfügung, in denen ich die Werte unterbringen könnte?
A hätte das rel-Attribut - aber da nur der Dateiname verlinkt wird, möchte ich darin ungern die Info über Größe und Timestamp ablegen. Außerdem scheint mir diese Info im rel reichlich fehlplatziert.

Also könnte ich das class-Attribut der jeweiligen Zellen mit dem Wert befüllen - erscheint mir aber auch nicht sonderlich sauber, damit erschaffe ich Klassen, zwischen denen kaum ein logischer Zusammenhang besteht, und die auch oftmals nur aus einem einzelnen Element bestehen könnten.

Welchen Weg würdet ihr wählen, um die für's Javascript benötigten Attribute im HTML-Code abzulegen, und warum?

(Zusätzlich zur Tabelle noch Javascript-Code zu generieren, der die Informationen in Form eines Arrays o.ä. enthält, möchte ich wenn möglich auch vermeiden.)

gruß,
wahsaga

[wahsaga]

hi,

Welche Attribute stellt mir HTML zur Verfügung, in denen ich die Werte unterbringen könnte?

title scheidet eigentlich auch aus - weil der daraus resultierende Tooltipp dem Nutzer ja nicht so unverständliche Informationen wie einen Unix-Timestamp vor die Nase halten soll.

gruß,
wahsaga

[Ashura]

Hallo wahsaga.

Welchen Weg würdet ihr wählen, um die für's Javascript benötigten Attribute im HTML-Code abzulegen, und warum?

Meinst du dass es Overkill wäre, beim Laden des jeweiligen Dokumentes eine „Sammlerfunktion“ über die Tabelle laufen zu lassen, welche jedem HTMLTableCellElement eine selbstdeklarierte Eigenschaft verpasst, in welcher gefälligere Werte enthalten sind?

Einen schönen Donnerstag noch.

Gruß, Ashura

[wahsaga]

hi,

Meinst du dass es Overkill wäre, beim Laden des jeweiligen Dokumentes eine „Sammlerfunktion“ über die Tabelle laufen zu lassen,

Das mache ich sowieso schon - zum initialisieren der Sortierfunktion lese ich aus der Tabelle die jeweiligen Werte in ein Array von Objekten ein. Dann wird dieses Array sortiert - und anschließend werden die Tabellenzeilen entsprechend "umgehängt".

welche jedem HTMLTableCellElement eine selbstdeklarierte Eigenschaft verpasst, in welcher gefälligere Werte enthalten sind?

Das ist leider die "falsche Richtung".
Klar _kann_ ich das formatierte Datum aus der Tabellenzelle auslesen - aber da es sich zum Sortieren nicht eignet, müsste ich es dann ja wieder in einen Timestamp oder zumindest eine Date()-Instanz umwandeln. Das ist mir aber eigentlich zu viel Parse-Aufwand - und zum anderen möchte ich das Anzeigeformat des Datums im HTML im serverseitigen Script konfigurierbar halten. Dann müsste mein Javascript aber auf das jeweilige Datumsformat reagieren - aus "2006/07/06 14:02" wieder einen Timestamp herzustellen müsste ja anders realisiert sein, als aus "Do., 6. Juli 2006, 14:02 Uhr". Und das Javascript wollte ich eigentlich vom Anzeigeformat unabhängig halten.
Außerdem löst es das Problem nicht, dass mir bei der formatierten Darstellung einer Dateigröße von 12.345 Bytes als "12.1 KB" Genauigkeit verloren geht.

gruß,
wahsaga

[Eternius]

Hallo,

nach langem hin und her habe ich mich entschieden das ganze in einer JS Datenstruktur zu repräsentieren.
  Es ginge auch mit selbst gebastelten attributen, aber:

Der Hauptgrund war, dass im Gegensatz zu einem kleinen Arrayzugriff, ein getAttribute Zugriff oder dergleichen auf eine Node verdammt langsam ist, was sich beim sortieren sehr bemerkbar gemacht hat, bei grossen mengen von daten.

gruss

[wahsaga]

hi,

Der Hauptgrund war, dass im Gegensatz zu einem kleinen Arrayzugriff, ein getAttribute Zugriff oder dergleichen auf eine Node verdammt langsam ist, was sich beim sortieren sehr bemerkbar gemacht hat, bei grossen mengen von daten.

Das Einlesen der Werte mache ich ja nur einmal bei der Initialisierung - beim (mehrmaligen, unterschiedlichen) Sortieren habe ich die Werte also bereits in Javascript vorliegen.

gruß,
wahsaga

[Eternius]

Hallo,

Das Einlesen der Werte mache ich ja nur einmal bei der Initialisierung - beim (mehrmaligen, unterschiedlichen) Sortieren habe ich die Werte also bereits in Javascript vorliegen.

Gut, dann hänge doch diese fertige Datenstruktur an den Table node mittels javascript an und greife bei Bedarf darauf zu.

Das heisst, du brauchst die Daten nur zum initialisieren. Was spricht gegen eine reine Javascript Lösung? Warum müssen /sollten die Daten an der jeweiligen Tabellenzeile/reihe hängen?

gruss

[wahsaga]

hi,

Gut, dann hänge doch diese fertige Datenstruktur an den Table node mittels javascript an und greife bei Bedarf darauf zu.

Es geht nicht darum, wo ich diese Datenstruktur zur Laufzeit im Javascript ablege - sondern wie ich sie erst mal aus den vorhandenen Daten (Tabelle) erzeuge.

Das heisst, du brauchst die Daten nur zum initialisieren.

Nein, ich brauche sie jedes mal für eine neue Sortierung.
Aber nur beim initialisieren lese ich sie ein mal in Javascript ein, danach habe ich sie ja zur Verfügung.

Was spricht gegen eine reine Javascript Lösung? Warum müssen /sollten die Daten an der jeweiligen Tabellenzeile/reihe hängen?

Weil ich den Umfang der Datenübertragung vom Server an den Client gerne minimieren möchte.

gruß,
wahsaga

[molily]

Hallo,

Welche Attribute stellt mir HTML zur Verfügung, in denen ich die Werte unterbringen könnte?

Keine. Ich würde nicht HTML verwenden. Bei class, title, rel usw. kommt nur semantischer Nonsens heraus, das ist für mich nichts anderes als blockquote bloß zum Einrücken verwenden usw. Dann lieber HTML-fremdes Markup.

Wenn du das Dokument sowieso serverseitig generierst: Ich würde die Rohdaten in ordentlichen, frei aufgebauten Datenstruktur beigeben - also zumindest nicht HTML. JSON bietet sich da an.

Mathias

[wahsaga]

hi,

Keine. Ich würde nicht HTML verwenden. Bei class, title, rel usw. kommt nur semantischer Nonsens heraus, das ist für mich nichts anderes als blockquote bloß zum Einrücken verwenden usw. Dann lieber HTML-fremdes Markup.

Ja, vermutlich wird das doch die beste Lösung sein.

Wenn du das Dokument sowieso serverseitig generierst: Ich würde die Rohdaten in ordentlichen, frei aufgebauten Datenstruktur beigeben - also zumindest nicht HTML. JSON bietet sich da an.

Na dann lieber gleich als Array in Javascript-Code - schließlich brauche ich sie auch nur in diesem Format.

Meine eigentliche Intention war, das Datenvolumen welches ich vom Server an den Client schicke minimal zu halten.
Die Unterbringung in irgendeinem HTML-Attribut schien mir dabei zunächst die mit der geringstmöglichen Redundanz zu sein.
Aber eigentlich hast du recht - wenn ich für das Javascript-Array die entsprechenden Kurzschreibweisen nutze, dann hält sich das neben dem Dateninhalt nötige Coding ja auch stark in Grenzen.

gruß,
wahsaga

[molily]

Hallo,

Na dann lieber gleich als Array in Javascript-Code - schließlich brauche ich sie auch nur in diesem Format.

Ich dachte nicht an eine mehrfache Übertragung derselben Daten im gleichen Dokument, sondern an die Übertragung der Zusatzdaten. Wenn du sowieso alles auf JavaScript aufbaust, stellt sich die Frage nach dem passenden Datenformat nicht. Dann kannst du XML oder JSON verwenden und das HTML dann clientseitig generieren, wenn du Lust hast anhand eines XSL-Stylesheets.

Meine eigentliche Intention war, das Datenvolumen welches ich vom Server an den Client schicke minimal zu halten. (...) wenn ich für das Javascript-Array die entsprechenden Kurzschreibweisen nutze, dann hält sich das neben dem Dateninhalt nötige Coding ja auch stark in Grenzen.

Natürlich ist Redundanz zu vermeiden, davon abgesehen würde ich immer die ausführliche Codevariante wählen, also etwa:

var daten = [  
  {  
    spalte1 : "...",  
    spalte2 : "...",  
    ...  
  },  
  ...  
];

Eine sort()-Sortierfunktion ist dann einfach geschrieben.

Alleine von der Verringerung des Datenvolumens würde ich mich nicht leiten wollen. Beschränkung auf die nötigen Daten in einem vernünftigen Format, für den Rest Gzip-Komprimierung.

Mathias

[wahsaga]

hi,

Ich dachte nicht an eine mehrfache Übertragung derselben Daten im gleichen Dokument, sondern an die Übertragung der Zusatzdaten.

Ja, ich auch.
Was an Daten nicht aus der Tabelle ermittelbar ist (Größe in Bytes, Timestamp), direkt als Javascript-Code übertragen, andere Sachen wie bspw. Dateinamen kann dann bei der Initialisierung aus Tabellenzellen hinzugelesen werden.

Wenn du sowieso alles auf JavaScript aufbaust, [...]

Nope.
Verzeichnislisting soll auch ohne JS anzeigbar sein - clientseitiges Sortieren ist JS-Bonus.

Eine sort()-Sortierfunktion ist dann einfach geschrieben.

Jepp, die stellt kein Problem dar.

gruß,
wahsaga

[Gunnar Bittersmann]

Hello out there!

Na dann lieber gleich als Array in Javascript-Code - schließlich brauche ich sie auch nur in diesem Format.

Meine eigentliche Intention war, das Datenvolumen welches ich vom Server an den Client schicke minimal zu halten.

Du kannst ja die JavaScript-Informationen in eine externe Ressource (serverseitig generiert) auslagen, die nur zum Client übertragen werden muss, wenn dieser JavaScript verarbeitet.

See ya up the road,
Gunnar

[Joachim]

Hi,

Welchen Weg würdet ihr wählen, um die für's Javascript benötigten Attribute im HTML-Code abzulegen, und warum?

Was spricht denn dagegen, die Werte von vorneherein in einem Javascript-Array unterzubringen, und die Tabelle gleich per Dom zu erzeugen? Dann musst Du nicht eine bestehende Tabelle auslesen, sondern nur ein Array umsortieren.

(Zusätzlich zur Tabelle noch Javascript-Code zu generieren, der die Informationen in Form eines Arrays o.ä. enthält, möchte ich wenn möglich auch vermeiden.)

Falls Du also Daten aus der Tabelle ausliest - wo willst Du sie denn dann unterbringen, ausser in einem Array...

Gruesse, Joachim

[wahsaga]

hi,

Was spricht denn dagegen, die Werte von vorneherein in einem Javascript-Array unterzubringen,

Siehe meine Antwort auf Mathias.
Aber jetzt werde ich das wahrscheinlich doch so machen, scheint die sauberste Lösung zu sein.

und die Tabelle gleich per Dom zu erzeugen?

Dann sieht der User ohne Javascript aber gar nix - so hat er auf jeden Fall das Verzeichnislisting in der serverseitig festgelegten Default-Sortierung vorliegen. Nur auf den zusätzlichen Komfort, die Tabelle dann noch nach eigenem Gutdünken sortieren zu lassen, darf er dann verzichten.

gruß,
wahsaga

[Joachim]

Hi,

Dann sieht der User ohne Javascript aber gar nix

Ich kenne ja Deine Bedenken diesbezueglich. Vieleicht kannst Du aber schon beim Aufruf der Datei einen Javascript-generierten Parameter mitgeben und so unterschiedliche Ausgaben erzeugen...

Gruesse, Joachim

[wahsaga]

hi,

Dann sieht der User ohne Javascript aber gar nix
Ich kenne ja Deine Bedenken diesbezueglich. Vieleicht kannst Du aber schon beim Aufruf der Datei einen Javascript-generierten Parameter mitgeben und so unterschiedliche Ausgaben erzeugen...

Nein, das ist nicht möglich.

Außerdem halte ich davon generell wenig - auch derart parametrisierte URLs könnten sich ggf. in Bookmarks einschleichen, auf irgendwelchen Wegen in SuMa-Ergebnisse gelangen, etc.
Und dann habe ich bei einem späteren Aufruf irgendwann einen javascriptEnabled=true-Parameter, der mich schlicht und einfach anlügt ...

gruß,
wahsaga

[Gunnar Bittersmann]

Hello out there!

Dann sieht der User ohne Javascript aber gar nix - so hat er auf jeden Fall das Verzeichnislisting in der serverseitig festgelegten Default-Sortierung vorliegen. Nur auf den zusätzlichen Komfort, die Tabelle dann noch nach eigenem Gutdünken sortieren zu lassen, darf er dann verzichten.

Warum bietest du für die nicht auch noch serverseitige Sortierung an?

See ya up the road,
Gunnar

[wahsaga]

hi,

Nur auf den zusätzlichen Komfort, die Tabelle dann noch nach eigenem Gutdünken sortieren zu lassen, darf er dann verzichten.

Warum bietest du für die nicht auch noch serverseitige Sortierung an?

In dem Fall m.E. zu unperformant.

gruß,
wahsaga

[wahsaga]

hi,

beim "Sortieren" der Tabelle im HTML stellt sich mir noch eine kleine Frage.
Ich baue die Tabelle nicht neu auf - erst leeren, dann jede Tabellenzeile neu aufbauen und einhängen erscheint mir zu unperformant - sondern hänge die Tabellenzeilen einfach per insertBefore um [1].

Frage dazu:
Ist es "erlaubt", bei insertBefore zweimal den selben Knoten anzugeben?
Sollte zwar eigentlich kein Problem sein, wenn ein Knoten vor sich selbst eingefügt wird, landet er effektiv wieder an der gleichen Position - und ggf. erkennt ein optimierter Interpreter das sogar gleich, macht also in dem Fall gar nichts.

Aber der DOM-Spezifikation habe ich dazu keine Aussage gefunden - und frage mich deshalb, ob das irgendeinem (standardtreuen) Browser sauer aufstoßen könnte?

[1] Ob das wirklich performanter ist, als die von Danny Goodman in Dynamic HTML Tables: Improving Performance betrachteten Ansätze - insb. der über DocumentFragment "gewinnt" den dortigen Benchmark ja in den meisten Browsern - habe ich noch nicht ausgetest. Mein Ansatz scheint mir auf jeden Fall nicht die schlechteste Möglichkeit zu sein, weil ich mir das entfernen und neu erzeugen von Knoten in meinem Scriptcode damit komplett erspare.

gruß,
wahsaga

[JürgenB]

Hallo wahsaga,

warum willst du an der Tabellenstruktur etwas ändern bzw. Tabellenzeilen umhängen? Es reicht doch, die Tabelleninhalte in ein 2d-Array zu kopieren, dort zu sortieren und dann wieder per nodeValue oder innerHTML in die Tabelle zurückzuschreiben. Siehe z.B. http://www.j-berkemeier.de/TableSort.html / http://www.j-berkemeier.de/TableSort_so_geht_es.html

Gruß, Jürgen

[wahsaga]

hi,

warum willst du an der Tabellenstruktur etwas ändern bzw. Tabellenzeilen umhängen?

Damit ich anschließend eine neu sortierte Tabelle habe - das ist doch Sinn und Zweck des ganzen Unterfangens :-)

Es reicht doch, die Tabelleninhalte in ein 2d-Array zu kopieren, dort zu sortieren und dann wieder per nodeValue oder innerHTML in die Tabelle zurückzuschreiben.

Das _geht_ auch - ich bezweifle jedoch, dass es performanter wäre.

Wie im Vorposting schon beschrieben, glaube ich eher nicht - hab's noch nicht getestet - dass das neu erzeugen oder clonen von Knoten, zerstören des Originalknotens und einhängen der Kopie an neuer Position performanter ist, als mein Ansatz:
Die nötige Sortierreihenfolge habe ich bereits ermittelt, und jetzt hänge ich einfach nur die Knoten um, per insertBefore - kein erzeugen/clonen und kein zerstören von Knoten, nur das umhängen bestehender an eine andere Stelle.
Das erscheint mir schon theoretisch performanter - und zudem hält es auch noch das nötige Coding kürzer.

gruß,
wahsaga

[JürgenB]

Hallo wahsaga,

mein Tabellensortierer kümmert sich nur um die Inhalte der TDs. Die restliche Tabellenstruktur bleibt wie sie ist. Und kürzer als
"Tabelle -> Array (nur beim 1. mal), Array sortieren, Array -> Tabelle", also eine (zwei) for-Schleifen,
geht es, glaube ich, nicht mehr.

Ich kann mir nicht vorstellen, habe es aber auch noch nicht getestet, dass das Verschieben von TRs schneller geht, als das Überschreiben der Inhalte der TDs.

Vieleicht kannst du mal einen Link posten, wenn du fertig bist, damit man die Algorithmen vergleichen kann. Wieviele Zeilen hat deine Tabelle? Ich habe eine mit 65 (Mitarbeitertabelle, daher keine URL) und eine mit fast 3000 Zeilen (link:http://www.uni-muenster.de/Physik.AP/Buecher-de.html].

Gruß, Jürgen

[wahsaga]

hi,

Ich kann mir nicht vorstellen, habe es aber auch noch nicht getestet, dass das Verschieben von TRs schneller geht, als das Überschreiben der Inhalte der TDs.

Vieleicht kannst du mal einen Link posten, wenn du fertig bist, damit man die Algorithmen vergleichen kann.

Kurz gebasteltes Test-Script:
http://wazgnuks.net/misc/tabsort_benchmark.htm

Wieviele Zeilen hat deine Tabelle?

Hab mal 200 Zeilen á drei Zellen zum testen genommen.
Zelleninhalte zufällig per PHP-Script erzeugt und ge-copy&paste-d, sind also immer die gleichen.
Erste Spalte enthält Kombination aus 15-20 Groß- und Kleinbuchstaben, zweite eine Zahl zwischen 10 und 5000, dritte eine zwischen 1000000000 und 2000000000.
Werte der ersten Spalte werden alphabetisch sortiert, die Zahlenwerte nummerisch.

Script zeigt als oberstes die zur Initialisierung (Werte aus Tabellenzellen einlesen, Array aus Objekten erzeugen) gebrauchte Zeit an,
darunter nach dem Sortieren des Objektarrays in Javascript die dazu benötigte Zeit und den Durchschnitt aller Sortiervorgänge,
und darunter die zum "Neuaufbau" der Tabelle (= Tauschen von TRs über insertBefore) gebrauchte Zeit, resp. Durchschnitt.

Zum sortieren einfach auf einen der drei Links im Tabellenkopf klicken, Sortierung erfolgt je Spalte immer im Wechsel auf- und absteigen.

Getestet mit Firefox 1.5, IE 6 und Opera 8.54

IE braucht auf meinem System durchschnittlich 260-270 Millisekunden zum sortieren und 225 zum tauschen der Tabellenzeilen,

Firefox ca. 110 sortieren/ 80 tauschen -

und Opera ist der absolute Davonrenner, ca. 35 Millisekunden sortieren und 10 Zeilen tauschen.

Firefox versaut es ab und zu mal mit den Zellenbreiten, so dass es zu leichten Überlagerungen kommt,
und Opera vergisst das neu rendern manchmal auch ein bisschen, überlagert dann alte Zelleninhalte mit neuen, was ich ihm durch meinen Wink mit dem Zaunpfahl wieder abgewöhne.

gruß,
wahsaga

[JürgenB]

Hallo wahsaga,

ich habe mal eben eine Benchmarkversion gebastelt: http://www.j-berkemeier.de/test/TableSort_Bench.html meine Zeiten unterscheiden sich nicht wesentlich von deinen, und wenn man das ganze "Zeugs drumrum" weglässt und nur die Sortierfunktion nimmt, sind die Codes auch ungefähr gleich lang.

Beim Messen habe ich festgestellt, dass bei mir die Variante mit innerHTML beim Zurückschreiben etwa 3-mal langsamer ist als die jetzt verlinkte Variante mit nodeValue.

Gruß, Jürgen

[MudGuard]

Hi,

Getestet mit Firefox 1.5, IE 6 und Opera 8.54
Firefox versaut es ab und zu mal mit den Zellenbreiten, so dass es zu leichten Überlagerungen kommt,
und Opera vergisst das neu rendern manchmal auch ein bisschen, überlagert dann alte Zelleninhalte mit neuen, was ich ihm durch meinen Wink mit dem Zaunpfahl wieder abgewöhne.

Ich würde während des Sortiervorgangs den tbody auf display:none oder visibility:hidden setzen.
Das dürfte das Sortieren nochmal beschleunigen, da nicht bei jedem Zeilen-Umsetzen das Rendering neu gemacht wird.
Außerdem dürfte es auch die Überlagerungsprobleme im Firefox beheben, und den Zaunpfahl für Opera ersetzen.

cu,
Andreas

[wahsaga]

'Nabend Andreas,

tut mir leid, dich auf ganzer Linie enttäuschen zu müssen ;-/

Ich würde während des Sortiervorgangs den tbody auf display:none oder visibility:hidden setzen.
Das dürfte das Sortieren nochmal beschleunigen, da nicht bei jedem Zeilen-Umsetzen das Rendering neu gemacht wird.

Nope, keine merkbare Verbesserung - egal mit welcher der beiden Eigenschaften.
Ich hätte zunächst ein unschönes kurzes Flackern erwartet - aber das tritt nicht ein. Und an den durchschnittlichen Zeiten ändert sich auch nichts annähernd signifkant.

Vermutlich ist das mal wieder einer dieser Fälle, wo die Browser gar nicht erst zwischendurch rendern - sondern erst mal die Abarbeitung des Scriptteils abwarten, bevor sie Änderungen umsetzen.

Cheatah hatte neulich auf die Frage eines Teilnehmers bezüglich eines Problems mit diesem Umstand geraten, die Scriptausführung durch einen Timeout zu unterbrechen, um eine gewünschte optische Veränderung - IIRC war es eine Warte-Meldung während eines längeren Scriptes - sichtbar werden zu lassen. Aber da wär' ich ja schön blöd, wenn ich das in diesem Fall ebenfalls versuchte :-)

Außerdem dürfte es auch die Überlagerungsprobleme im Firefox beheben,

Ebenfalls nein, und

und den Zaunpfahl für Opera ersetzen.

ebenfalls nein.

Als Zaunpfahl habe ich hier wieder mal auf das neu-setzen der Hintergrundfarbe für body zurückgegriffen - wenn ich das für die Tabelle selber mache, hat es nicht den gewünschten Effekt.

gruß,
wahsaga

[wahsaga]

hi,

Frage dazu:
Ist es "erlaubt", bei insertBefore zweimal den selben Knoten anzugeben? [...]
Aber der DOM-Spezifikation habe ich dazu keine Aussage gefunden - und frage mich deshalb, ob das irgendeinem (standardtreuen) Browser sauer aufstoßen könnte?

Um die Frage selber zu beantworten:

Ja, Opera (8.54) zickt rum, wenn ich per insertbefore versuche einen Knoten vor sich selber einzufügen - wirft eine DOM Exception (keine weiteren Infos außer Zeilenummer).

Leicht behoben, durch vorherige Abfrage, ob beide Knoten identisch sind.

gruß,
wahsaga

[molily]

Hallo,

Ja, Opera (8.54) zickt rum, wenn ich per insertbefore versuche einen Knoten vor sich selber einzufügen - wirft eine DOM Exception (keine weiteren Infos außer Zeilenummer).

Ja, normal. Die Info steckt bei einer DOM-Exception in der code-Eigenschaft, die Exception musst du mit try-catch abfangen.

Mathias

[Cheatah]

Hi,

Welche Attribute stellt mir HTML zur Verfügung, in denen ich die Werte unterbringen könnte?

Event-Handler.

Du kannst dem <tr>-Element (oder auch den <td>s bzw. <th>s) einen handelsüblichen Event-Handler zuordnen, in dem nur ein von Dir zur Verfügung gestelltes JavaScript-Objekt zurück geliefert wird, welches mit den entsprechenden Daten instanziiert wird. Wenn Du das noch z.B. geschickt über eine Caching-Klasse laufen lässt, hast Du im Prinzip die bereits vorgeschlagene Methodik, die Werte im JavaScript-Code mitzuliefern, nur dass sie halt an der richtigen Stelle stehen. Bei der Sortierung rufst Du den Event-Handler auf, ziehst den Wert heraus, und fertig.

Cheatah

[wahsaga]

hi Cheatah,

Event-Handler.

Der Vorschlag ist zwar interessant - erscheint mir aber trotzdem auch ein bisschen vhddBiA ...

Du kannst dem <tr>-Element (oder auch den <td>s bzw. <th>s) einen handelsüblichen Event-Handler zuordnen, in dem nur ein von Dir zur Verfügung gestelltes JavaScript-Objekt zurück geliefert wird, welches mit den entsprechenden Daten instanziiert wird. Wenn Du das noch z.B. geschickt über eine Caching-Klasse laufen lässt,

Die Daten nur einmal zu ermitteln und in Javascript-Objekten abzulegen, ist ja eh schon drin.
Einmal ermitteln, danach beliebig oft sortieren.

Bei der Sortierung rufst Du den Event-Handler auf, ziehst den Wert heraus, und fertig.

Welchen Eventhandler sollte ich da nehmen?
Es müsste ein für TR oder TD erlaubter sein - und die solchen reagieren (fast) alle auf irgendwelche Anwenderreaktionen oder -eingaben (onmouse-irgendwas oder onkey-irgendwas).
Löst der Anwender diese Events bei einigen Elementen jetzt schon aus, bevor ich meine Initalisierung starten kann - dann habe ich einige Objekte schon erzeugt, andere noch nicht ...
Gut, kann man steuern, in dem man den Eventhandler direkt nach der Abarbeitung vom Element entfernt - und dann in der Initialisierung nur noch die Elemente behandelt, die ihn noch haben.
Aber irgendwie auch technisch unschöne Frickelei, oder?

hast Du im Prinzip die bereits vorgeschlagene Methodik, die Werte im JavaScript-Code mitzuliefern, nur dass sie halt an der richtigen Stelle stehen.

Wie gesagt, der Vorschlag ist interessant, keine Frage - aber ob ich diese Stelle so "richtig" finden kann, weiß ich noch nicht.
Der Event an sich interessiert mich ja nicht die Bohne - warum soll ich dann eine Reaktion auf ihn einbauen?
Klar, eleganter als meine Eingangsüberlegungen, rel oder class dafür zu missbrauchen, ist es allemal - aber so ganz damit anfreunden kann ich mich noch nicht.

gruß,
wahsaga

[Cheatah]

Hi,

Event-Handler.
Der Vorschlag ist zwar interessant - erscheint mir aber trotzdem auch ein bisschen vhddBiA ...

ja, er ist nicht unbedingt straight forward, das gebe ich zu.

Welchen Eventhandler sollte ich da nehmen?

Sag Du es mir ;-)

Es müsste ein für TR oder TD erlaubter sein - und die solchen reagieren (fast) alle auf irgendwelche Anwenderreaktionen oder -eingaben (onmouse-irgendwas oder onkey-irgendwas).
Löst der Anwender diese Events bei einigen Elementen jetzt schon aus, bevor ich meine Initalisierung starten kann - dann habe ich einige Objekte schon erzeugt, andere noch nicht ...

Ein guter Caching-Mechanismus kommt damit zurecht, und für den ersten Wurf tut es auch die stetige Neuerzeugung. Nicht performant, aber funktionstüchtig. Das Caching mit einem guten Design-Pattern (Singleton?) vorzubereiten sollte nicht das Problem sein.

Gut, kann man steuern, in dem man den Eventhandler direkt nach der Abarbeitung vom Element entfernt - und dann in der Initialisierung nur noch die Elemente behandelt, die ihn noch haben.
Aber irgendwie auch technisch unschöne Frickelei, oder?

Ja, das wäre es in der Tat, zumal Du dann den Zusammenhang zwischen Zeile und Daten verlieren würdest. Wenn der IE keine Rolle spielt, könntest Du übrigens per Prototyping den HTMLTableRowElement-Objekten entsprechende Zugriffsmethoden zuordnen.

Der Event an sich interessiert mich ja nicht die Bohne - warum soll ich dann eine Reaktion auf ihn einbauen?

Ja, das ist richtig. Die vorgesehene Reaktion ist aber nur eine Rückgabe - die verworfen wird, weil sie von nichts beachtet werden will.

Klar, eleganter als meine Eingangsüberlegungen, rel oder class dafür zu missbrauchen, ist es allemal - aber so ganz damit anfreunden kann ich mich noch nicht.

Und ich bin Dir nicht mal böse deswegen ;-) da es ganz klar ebenfalls nur ein Workaround ist. Welcher Workaround für Dich die meisten Vorteile mit den wenigsten Nachteilen verknüpft, wirst Du selbst entscheiden können.

Cheatah

[wahsaga]

hi,

Gut, kann man steuern, in dem man den Eventhandler direkt nach der Abarbeitung vom Element entfernt - und dann in der Initialisierung nur noch die Elemente behandelt, die ihn noch haben.
Aber irgendwie auch technisch unschöne Frickelei, oder?

Ja, das wäre es in der Tat, zumal Du dann den Zusammenhang zwischen Zeile und Daten verlieren würdest.

Nö, wieso?

Mein Array mit einem Objekt je Tabellenzeile baue ich ja sowieso auf - nummerischer Element-Index entspricht dem Index der Zeile in der Tabelle.
Wenn der Eventhandler vor meiner Intialisierungsroutine feuert, ermittle ich mir den Index der Tabellenzeile halt irgendwie - und wenn er schon im Eventhandler mit drin stünde.
Damit kann ich das nummerisch richtige Element im Array anlegen.

Und dann Schleife über alle Zeilen, schauen für welche noch kein Element existiert - dabei habe ich den nummerischen Index ebenfalls schon zur Hand.

Aber zu viel Javascript-Voodoo will ich dann auch nicht betreiben - die nötigen Daten in einem Script-Bereich im Head schon serverseitig auszugeben, erscheint mir doch die Alternative mit dem besten Aufwand/Nutzen-Verhältnis.

gruß,
wahsaga

[Cheatah]

Hi,

Ja, das wäre es in der Tat, zumal Du dann den Zusammenhang zwischen Zeile und Daten verlieren würdest.
Nö, wieso?

naja, lass es mich umformulieren: Die verknüpfende Information, die zuvor per se gegeben war, ist plötzlich weg und muss künstlich neu konstruiert werden. Einen besonders großen Nutzen sehe ich darin nicht.

Mein Array mit einem Objekt je Tabellenzeile baue ich ja sowieso auf - nummerischer Element-Index entspricht dem Index der Zeile in der Tabelle.

Hm. Ich würde Referenzen zu den Zeilen halten, und den Index nur aus Effizienzgründen redundant speichern.

Wenn der Eventhandler vor meiner Intialisierungsroutine feuert, ermittle ich mir den Index der Tabellenzeile halt irgendwie - und wenn er schon im Eventhandler mit drin stünde.

Über HTMLTableRowElement.prototype.getItemIndex() natürlich[1] ;-)

Aber zu viel Javascript-Voodoo will ich dann auch nicht betreiben

Kein Voodoo. Auch in JavaScript ist Objektorientierung ein hervorragendes Konzept.

die nötigen Daten in einem Script-Bereich im Head schon serverseitig auszugeben, erscheint mir doch die Alternative mit dem besten Aufwand/Nutzen-Verhältnis.

So sei es denn ;-)

Cheatah

[1] Oder Du schreibst Dir einen Getter für .itemIndex, versteht sich.

[Tim Tepaße]

Hallo Wahsaga,

Die für die jeweilige Sortierung relevanten Werte kann ich ja im Falle des Dateinamens ganz einfach auslesen - aber für Größe und Datum ist das nicht so einfach, weil diese natürlich "schön" formatiert dargestellt werden sollen - Größe ja nachdem in Bytes, KB oder MB, und das Datum natürlich auch in lesbarer Form.
Welchen Weg würdet ihr wählen, um die für's Javascript benötigten Attribute im HTML-Code abzulegen, und warum?

Zwei Lösungsvorschläge:

Zum einen haben die Jungs und Mädels der Microformats-Bewegung für sich die Lösung erdacht, bessere (vollständigere) Daten mittels <abbr> und dessem title-Attribut darzustellen, in der Form eines Datums sähe das dann so aus:

<p>Die Party beginnt am <abbr class="date" title="2006-07-10T22:00:00+02:00">zehnten um zehn Uhr abends</abbr>. Seid da!</p>

Etwas mehr Information dazu findest Du im Microformats-Wiki:
• abbr-design-pattern
• datetime-design-pattern

Und ja, wenn man nicht mit XPath arbeitet, wie das viele dort zu tun scheinen, ist das mit normalen DOM-Methoden einen Hauch nerviger zu verarbeiten, weil ein weiteres Element vorhanden ist, ja.

Zweite Möglichkeit, die mir in den Sinn kommt, ist es, eigene Daten beinhaltende Attribute zu definieren und diese in einem XML-Namensraum zu stopfen:

<html xmlns="http://www.w3.org/1999/xhtml"  
      xmlns:my="tag:tepasse.org,2006-07-06:selfhtml/wahsaga">  
...  
<tr>  
  <th class="filename"><a href="p0rn.jpg">p0rn.jpg</a></th>  
  <td class="size" my:size="1049600">1.1 MebiByte</td>  
  <td class="last-changed" my:date="2006-07-06T19:12:00+02:00">gerade eben</td>  
</tr>

Ja, die Validität nach der DTD ist dann kaputt, es sei denn, Du erweiterst diese  lokal und hartkodierst das Präfix damit in der DTD fest. XML-Namensräume und DTDs vertragen sich eben nicht wirklich.

Ansonsten wäre meine Methode wohl auch mittels JSON Syntax die Daten noch einmal zusätzlich mitzuliefern, also entweder in einem zusätzlichen script-Element oder aber – ins Blaue reingedacht – in einem (oder bei mehreren zu sortierenden Tabellen in mehreren) object-Elementen im head zu verstecken. Ein generisches unaufdringliches Tabellensortier-Skript könnte dann die Seite auf sortierbare Tabellen untersuchen, dann nach object-Elementen mit den passenden Datenstrukturen suchen und diese einander zuordnen. Ohne sich den Namensraum zu verschmutzen. Allerdings wird dass dann wieder viel Aufwand und viel Code für wenig Nutzen, der Hauptnutzen wäre dann rein ästhetischer Natur.

Tim

[molily]

Hallo,

Zum einen haben die Jungs und Mädels der Microformats-Bewegung für sich die Lösung erdacht, bessere (vollständigere) Daten mittels <abbr> und dessem title-Attribut darzustellen, in der Form eines Datums sähe das dann so aus:

<p>Die Party beginnt am <abbr class="date" title="2006-07-10T22:00:00+02:00">zehnten um zehn Uhr abends</abbr>. Seid da!</p>

Geil. Da scheint auch keiner daran zu denken, dass Screenreader die Langfassung im title-Attribut vorlesen. Diese Party wird nicht sehr erfolgreich...

Mathias

[wahsaga]

hi,

<p>Die Party beginnt am <abbr class="date" title="2006-07-10T22:00:00+02:00">zehnten um zehn Uhr abends</abbr>. Seid da!</p>

Geil. Da scheint auch keiner daran zu denken, dass Screenreader die Langfassung im title-Attribut vorlesen.

Aus ähnlichem Grund hatte ich title ja auch gleich in meinem Nachtrag zur Fragestellung schon ausgeschlossen.

Nein, sorry, diese Möglichkeit vermag mich auch nicht sonderlich zu überzeugen.

gruß,
wahsaga

[Gunnar Bittersmann]

Hello out there!

Deshalb will ich die Originalgröße in Bytes sowie den UNIX-Timestamp der letzten Änderung gerne auch irgendwie schon im HTML-Code unterbringen, um per Javascript simpleren Zugriff auf die relevanten Werte zu haben.

Warum bringst du nicht _nur_ die Originalgröße in Bytes sowie das Datum der letzten Änderung im vernünftigen[tm] Format im HTML-Code unter?

Mit JavaScript machst du aus '43008' '42 KiB'; die paar Nutzer ohne JavaScript bekommen dann eben immer die Angabe in Bytes zu sehen – ist das tragisch?

Ich würde für das Datum nicht den UNIX-Timestamp verwenden, sondern das internationale Datumsformat 'yyyy-mm-ddThh:mm:ss' [ISO 8601]. Daten in dem Format kannst du gleich alphanumerisch sortieren, du brauchst keine Date-Objekte. Auch das Umformatieren in 'dd.mm.yyyy hh:mm:ss' (warum auch immer man das machen wollen würde) ginge mit Stringfunktionen.

See ya up the road,
Gunnar