jQuery - DOM-Element bearbeiten

[Der Thomas]

Hallo.

Ich habe bereits Ahnung von JavaScript und will mich nun in ein Framework "einarbeiten".
Nachdem ich viel gegoogelt und gelesen habe standen eigentlich nur noch zwei Frameworks zur Auswahl:
jQuery und prototype
Der Tenor hier im Forum ging in diesem Thread jquery vs. prototype ehr Richtung jQuery, wodurch ich mich dann auch dafür entschieden habe.

Allerdings gibt es eine Sache die mir einfach nicht gefällt (und die prototype besser macht, wie ich finde).

$() <- wird einfach für alles benutzt.
Egal ob ich ein Element erstelle, getElementById haben will oder einen CSS-Selektor-Query, fast alles läuft über diese eine Funktion.

Ein Beispiel:

  
var tbl = $('#grosseTabelle');  
  
var i, k;  
for (i=0; i<100; i++) {  
	var tr = $('<tr></tr>');                 // tr's erstellen  
	for (k=0; k<100; k++) {  
		tr.append($('<td></td>'));       // td's hinzufügen  
	}  
	tbl.append(tr);                          // tr an die Tabelle hängen  
}  

Vielleicht könnt ihr mir dabei helfen dieses kleine Beispiel "schön" zu machen.
Was mir vor allem nicht gefällt ist dabei das $('<tr></tr>'). Eine Funktion wie document.createElement(...) konnte ich für jQuery leider nicht finden :-/
Und gibt es eine Art DocumentFragment? Die 100 Zeilen und Spalten sind jetzt nur ein Beispiel, wenn es mehr würden wäre es ja wahrscheinlich besser alle auf einmal ins DOM einzuspeisen. Kann man das mit jQuery irgendwie?

Wäre froh wenn mir jemand sagen könnte wie das mehr im jQuery-Stil umzusetzen ist.

Danke!

[Klawischnigg]

Hi there,

Ich habe bereits Ahnung von JavaScript und will mich nun in ein Framework "einarbeiten".

Was hast Du denn vor? So ein Framework dient, wenn überhaupt, ja einem bestimmten Zweck und der bestimmt auch die Art des Frameworks, das man einsetzen sollte (wenn man denn ein Framework verwenden will)...

[Der Thomas]

Hi,

Was hast Du denn vor? So ein Framework dient, wenn überhaupt, ja einem bestimmten Zweck und der bestimmt auch die Art des Frameworks, das man einsetzen sollte (wenn man denn ein Framework verwenden will)...

Ich hoffe du erlaubst eine Gegenfrage:
Für welche Fälle ist denn prototype besser geeignet als jQuery?

Bei den zahlreichen Funktionen, die Frameworks wie jQuery, prototype, dojo, etc. bieten ging ich davon aus, dass es diese Spezialisierung nicht mehr gibt...

Gruß

[Klawischnigg]

Hi there,

Ich hoffe du erlaubst eine Gegenfrage:
Für welche Fälle ist denn prototype besser geeignet als jQuery?

Das kann ich Dir nicht beantworten. Der Sinn meiner ursprünglichen Antwort war, warum Du überhaupt ein Framework verwenden willst; und wenn Du das weisst, dann gibt es je nach Sinn und Zeck Deines Vorhabens eben mehr oder weniger angepasste Frameworks.

Ich habe halt die Erfahrung gemacht, daß es bei größeren Projekten besser ist, wenn man sich die benötigten Funktionen und Funktionalitäten selbst schreibt, und bei kleinen Projekten benötigt man kein Framework.

Aber wenn es Dir lediglich um das Einarbeiten in ein Framework an sich geht (warum auch immer - oder auch nicht, ältere Leute setzen sich halt zB gerne in den Park und vergiften Tauben, wenn ihnen fad ist), dann nimm Dir das, welches Dir am besten zusagt.

Bei den zahlreichen Funktionen, die Frameworks wie jQuery, prototype, dojo, etc. bieten ging ich davon aus, dass es diese Spezialisierung nicht mehr gibt...

Naja, die meisten manipulieren halt einfach den DOM-Baum, einige sind darüber hinauf für Ajax-Anwendungen besser geeignet, mit andern kanns Du optische Effekte besser umsetzen etc...

[Der Thomas]

Hi.

Das kann ich Dir nicht beantworten. Der Sinn meiner ursprünglichen Antwort war, warum Du überhaupt ein Framework verwenden willst; und wenn Du das weisst, dann gibt es je nach Sinn und Zeck Deines Vorhabens eben mehr oder weniger angepasste Frameworks.

Da fällt mir schon einiges ein... CSS-Selektoren, das DOMContentReady (oder wie heißt das...) so dass es auch in allen Browsern funktioniert, Chaining, JSON und vor allem all diese kleinen Funktionen die man hin und wieder mal braucht (addClass, removeClass, hide, show fallen mir da jetzt spontan ein).

Aber wenn es Dir lediglich um das Einarbeiten in ein Framework an sich geht (warum auch immer - oder auch nicht, ältere Leute setzen sich halt zB gerne in den Park und vergiften Tauben, wenn ihnen fad ist), dann nimm Dir das, welches Dir am besten zusagt.

:D Ich versuche ja gerade rauszufinden welches mir am Besten zusagt.

[molily]

Ich habe halt die Erfahrung gemacht, daß es bei größeren Projekten besser ist, wenn man sich die benötigten Funktionen und Funktionalitäten selbst schreibt, und bei kleinen Projekten benötigt man kein Framework.

Da frage ich mich, wie groß diese »größere Projekte« sind. Wie viele Codezeilen, wieviele Entwickler, wieviel Zeit, welche Zielplattformen, wie skalierbar?

Offenbar müssen sie riesig groß sein mit einer Entwicklungsdauer von mehreren Jahren - denn um einfache DOM-Operationen, Event-Handling und ein bisschen Ajax browserübergreifend robust (und getestet) umzusetzen, braucht man geschätzt ein Jahr Entwicklungszeit. Für eine halbwegs brauchbare Selektor-Engine noch einmal ein halbes Jahr. Wohlgemerkt wenn man Algorithmen und Know-How bereits aus bestehenden Bibliotheken übernimmt. Von Performance noch gar nicht gesprochen.

Das machen alternative, kleinere Bibliotheken wie DOMAssistant nämlich. DOMAssistant ist wirklich nicht überladen, hat aber bereits 1500 Zeilen Code (ungefähr 1/6 von jQuery), der dicht mit Logik bepackt ist, die auf den Erfahrungen aus vielen anderen Bibliotheken aufbaut. Zepto.js, eine Mikro-Bibliothek nur für Webkit Mobile mit JavaScriptCore hat bereits 577 - sehr gut durchdachte - Zeilen Code.

Also, nach einem Jahr Vorlauf kann man dann vermutlich anfangen, browserübergreifende JavaScript-Anwendungen zu schreiben.

Mathias

[Klawischnigg]

Hi there,

Da frage ich mich, wie groß diese »größere Projekte« sind. Wie viele Codezeilen, wieviele Entwickler, wieviel Zeit, welche Zielplattformen, wie skalierbar?

Also irgendetwas, was ich für 15-20 Tausend Euro verkaufen kann. Ich entwickle seit 25 Jahren Software und habe das meist alleine erledigt, ab und an kauf' ich mir Leistung temporär dazu. Das ganze darf nicht mehr als höchstens ein paar Monate dauern, Zielplattform ist mir egal, ich schreib' mittlerweile nur mehr Intranetanwendungen, die im Browser laufen. Reich wird man damit zwar nicht, aber es reicht für den Weinkeller. In diesem Sinne sind das für mich größere Projekte.

Offenbar müssen sie riesig groß sein mit einer Entwicklungsdauer von mehreren Jahren - denn um einfache DOM-Operationen, Event-Handling und ein bisschen Ajax browserübergreifend robust (und getestet) umzusetzen, braucht man geschätzt ein Jahr Entwicklungszeit.

Naja, ich erfind' das Rad ja auch nicht ständig neu. Ich verwende selbstgeschrieben Bibliotheken oder was weiss ich wie man das jetzt nennt mit Funktionen, die ich wirklich benötige. Klar, das sich das im Lauf der Jahre entwickelt hat und immer weiter verbessert und optimiert wird.

Für eine halbwegs brauchbare Selektor-Engine noch einmal ein halbes Jahr.

Keine Ahnung, was Du damit meinst. Ist mir jedenfalls noch nicht abgegangen.

Das machen alternative, kleinere Bibliotheken wie DOMAssistant nämlich. DOMAssistant ist wirklich nicht überladen, hat aber bereits 1500 Zeilen Code (ungefähr 1/6 von jQuery), der dicht mit Logik bepackt ist, die auf den Erfahrungen aus vielen anderen Bibliotheken aufbaut. Zepto.js, eine Mikro-Bibliothek nur für Webkit Mobile mit JavaScriptCore hat bereits 577 - sehr gut durchdachte - Zeilen Code.

Das klingt ja nicht uninteressant, mein Problem ist halt, das ich nie vor dem Problem stehen möchte, daß beim Kunden irgendein Problem auftritt, das ich nicht verstehe, weil ich keine Lust habe, ein Framework so komplett zu studieren, daß ich es gleich selbst schreiben könnte. Aus dem Grunde stehe ich dem etwas bis ziemlich reserviert gegenüber...

[molily]

Für eine halbwegs brauchbare Selektor-Engine noch einmal ein halbes Jahr.

Keine Ahnung, was Du damit meinst. Ist mir jedenfalls noch nicht abgegangen.

Du bist professioneller JavaScript-Programmierer und kannst mit dem Begriff nichts anfangen? Ähm. Gut. Ich wusste nicht, dass man zeitgemäßes DOM Scripting OHNE eine Selektor-Engine machen kann.

Selektor-Engines sind seit 2003 Bestandteil der meisten Frameworks und Toolkits. jQuery nutzt beispielsweise Sizzle. Sie erlauben einem, Elemente im DOM über CSS-ähnliche Selektor auszuwählen. $('#el .class[attr=val]') gibt einem etwa alle Element-Objekte mit der Klasse class und dem Attribut attr="val" im Element #el zurück.

mein Problem ist halt, das ich nie vor dem Problem stehen möchte, daß beim Kunden irgendein Problem auftritt, das ich nicht verstehe, weil ich keine Lust habe, ein Framework so komplett zu studieren, daß ich es gleich selbst schreiben könnte. Aus dem Grunde stehe ich dem etwas bis ziemlich reserviert gegenüber...

Frameworks kochen auch nur mit Wasser. Wer auf dem Level ist, alles selbst zu schreiben, der kann auch Framework-Code verstehen. Es treten keine Probleme auf, die man nicht in absehbarer Zeit lokalisieren kann. Liegt der Fehler in der Bibliothek, muss man höchstens einen Workaround einbauen, bis in der nächsten Version der Fehler behoben ist.

Sieh das mal aus der umgekehrten Sicht: Der Kunde ist an denjenigen gebunden, der anstatt allgemein verbreiteter, gut dokumentierter, automatisiert getesteter, regelmäßig aktualisierter Bibliotheken eine selbstgebastelte Software einsetzt. Kann oder will derjenige nicht mehr daran arbeiten, so steht der Kunde auf einer 20.000-Euro-Software, die nur eine Person auf der Welt versteht. Einen anderen Entwickler kann er nicht daran setzen; der würde so lange den Code studieren müssen, da könnte er ihn auch gleich neu schreiben.

Es hat schon seinen Grund, warum es große offene und etablierte Softwareprojekte gibt, die von einer Community getragen werden: Sie sollen verhindern, dass jeder seinen eigenen inkompatiblen und (höchstwahrscheinlich) unwartbaren Kram codet. Auf die unberechenbare Situation, solch eine Software weiterentwickeln zu müssen, würden ich mich nicht einlassen und Kunden eher empfehlen, die Software neu entwickeln zu lassen. Und zwar mit einer konventionellen Werkzeugkiste, in die sich jeder JavaScripter auf dem Arbeitsmarkt anhand der Dokumentation in einer paar Tagen einarbeiten kann.

Mathias

[Matti Mäkitalo]

Hi,

Vielleicht könnt ihr mir dabei helfen dieses kleine Beispiel "schön" zu machen.
Was mir vor allem nicht gefällt ist dabei das $('<tr></tr>'). Eine Funktion wie document.createElement(...) konnte ich für jQuery leider nicht finden :-/

Naja, du kannst natürlich var tr = $(document.createElement('tr')); nutzen, aber ob das soviel lesbarer ist, wage ich zu bezweifeln.

Eine andere Möglichkeit wäre, zuerst den kompletten HTML-String zusammenzubauen und diesen dann mit var html = $(htmlStr); zu einem jQuery-Objekt umzuwandeln.
Oder du kannst einfach an der gewünschten Einhängestelle $('#selector').html(htmlStr); nutzen.

Dann müsstest du aber danach noch etwaige Event-Handler u.ä. nachträglich reinfummeln und kannst dies nicht beim Zusammenbauen des DOMs erledigen (d.h. der Browser hast Mehraufwand).

Bis die Tage,
Matti

[molily]

$() <- wird einfach für alles benutzt.

Nein, es wird benutzt, wo es nötig ist. Manche jQuery-Anfänger meinen, alles mögliche und jede Zeile erst einmal mit einmal $() zu beginnen.

Egal ob ich ein Element erstelle, getElementById haben will oder einen CSS-Selektor-Query, fast alles läuft über diese eine Funktion.

Das stimmt. Das sind ja zusammengefasst nur zwei Anwendungsfälle. Ein wichtiger dritter ist vielleicht noch das manuelle Wrappen von Elementen, z.B. $(this) in Event-Handlern und Iteratoren.

var tbl = $('#grosseTabelle');

var i, k;
for (i=0; i<100; i++) {
var tr = $('<tr></tr>');                 // tr's erstellen
for (k=0; k<100; k++) {
tr.append($('<td></td>'));       // td's hinzufügen
}
tbl.append(tr);                          // tr an die Tabelle hängen
}
[/code]

Vielleicht könnt ihr mir dabei helfen dieses kleine Beispiel "schön" zu machen.

Es ist so schön, wie jQuery es vorsieht. Es ist aber nicht performant. DOM-Operationen wie diese, wo du riesige Tabellen zusammenbaust, sollten nicht am Live-DOM stattfinden. Mit 100 mal 100 Zellen frierst du den Browser ein, weil er nach jeder Operation das DOM aktualisiert und layoutet.
Besser ist es, die grosseTabelle z.B. erst mittels detach aus dem DOM zu lösen, dann daran zu arbeiten und sie letztlich wieder einzuhängen.

Was mir vor allem nicht gefällt ist dabei das $('<tr></tr>'). Eine Funktion wie document.createElement(...) konnte ich für jQuery leider nicht finden :-/

Wenn du low-level arbeiten willst, kannst du das tun, aber jQuery vereinfacht es dir nicht. $('<td></td>') bzw. $('<td/>') so »unschön« aus, weil dieser Fall unglaublich selten vorkommt. Wann erzeugt man schon ein leeres Element? Diese Schreibweise ist darauf ausgelegt, dass man dem Element gleich noch Inhalt mitgibt. Gerne auch komplexen Inhalt mit weiteren Elementen. Wenn du es einfach willst, kannst du, wie Matti auch sagt, mit dem konventionellen DOM arbeiten und jQuery nur nutzen, wenn du dessen Methoden brauchst. In deinem Beispiel nutzt du jQuery nicht wirklich - du hättest ohne viel Mehraufwand document.createElement und appendChild schreiben können.

Dein Beispiel ist insofern total gestellt und nicht verwunderlich, dass haargenau diese Vorgehensweise mit eine Bibliothek nicht sonderlich eleganter oder kürzer umgesetzt werden kann. jQuery ist nicht dafür gedacht, in solchen Beispielen gut auszusehen, sondern die API ist für üblichere DOM-Operationen ausgelegt. Das ist bei Prototype im Grunde nicht anders. Ein new Element('td') hat gegenüber low-level-DOM document.createElement('td') keine großen Vorteile, vielmehr legt es ein globales Objekt an, das möglicherweise einen eingebauten Konstruktor überschreibt. Die Vorteile ergeben sich bei komplexeren DOM-Operationen und etwa beim Event-Handling.

Und gibt es eine Art DocumentFragment?

jQuery arbeitet intern sehr viel mit Document-Fragments. Wie gesagt kannst du detach verwenden, wenn du viele DOM-Operationen an bestehenden Elementen erledigen musst. Wobei sich dann die Frage ergibt: Warum und warum auf diese Weise? Auch dafür gibt es andere und bessere Lösungen, z.B. Template-Engines. Unmengen an HTML rendert man ohnehin meist auf dem Server oder transformiert sie clientseitig aus JSON mittels eines Templates in HTML.

Die 100 Zeilen und Spalten sind jetzt nur ein Beispiel, wenn es mehr würden wäre es ja wahrscheinlich besser alle auf einmal ins DOM einzuspeisen. Kann man das mit jQuery irgendwie?

Wie gesagt kannst du das HTML als String zusammenbauen und dann in einem Rutsch mit append o.ä. ins DOM einfügen. Fast alle Methoden zur DOM-Manipulation akzeptieren jQuery-Objekte, Elemente-Objekte sowie HTML-Strings. Es ist daher einfach, die kürzeste Schreibweise zu wählen, ohne darauf verzichten zu müssen, die jQuery-Methoden jederzeit anwenden zu können.

Mathias