Versteckte Frames für clientseitiges Caching

Auf den ersten Blick scheint das dynamische Erstellen eines Inline-Frames eine leichte Sache. Das stimmt grundsätzlich, andererseits gibt es dabei auch ein paar unerwartete Probleme.

In einem früheren Artikel wurde eine Browser-basierte Anwendung beschrieben, die Objekte im Voraus in versteckte Frames lädt, um die Performance der Anwendung zu verbessern. Bei diesen Objekten handelte es sich um Auswahl-Boxen, Grafiken und Java Swing-Applets. Einmal geladen, wurden diese Objekte aus dem versteckten Frame in einen sichtbaren Frame kopiert, wo sie wie jedes andere Objekt funktionierten. Das Laden im Voraus verbesserte zwar deutlich die Performance, aber der Vorgang selber dauerte fast fünf Minuten, und das bei Ethernet-Geschwindigkeit. Mit einem normalen Modem hätte die Zeit gereicht, hinaus zu gehen um Kaffee und Kuchen zu besorgen.

Das Laden von Objekten im Voraus hat sicher seine Vorteile, aber diese spezielle Implementierung hatte doch ihre Macken. Also entschied ich mich, die Sache von einer anderen Seite anzugehen. Anstatt die Objekte im Voraus zu laden, speicherte ich alle Objekte, die mehr als einmal verwendet würden, in einem Cache zwischen. Und anstelle eines eigenen versteckten Frames für jedes auf der Client-Seite zwischengespeicherte Objekt benutzte ich einen versteckten Frame mit mehreren mit diesem verknüpften Inline-Frames. Dadurch hatte ich die Möglichkeit, über das DOM-Objekt Frames Collection zu sehen, welche Elemente bereits im Cache waren. Wenn z.B. der Name des versteckten Frames Dwarfs ist, wäre die Frames Collection top.Dwarfs.frames. Um einen Inline-Frame namens Grumpy zu finden, würde man eine JavaScript-Funktion wie in Listing A verwenden.

Die Funktion inlineFrame findet einen vorhandenen Inline-Frame, aber was ist, wenn der Inline-Frame gar nicht existiert und Null zurückgegeben wird? Nun, wenn es den Frame noch nicht gibt, müssen wir ihn eben erstellen.

Auf den ersten Blick scheint das dynamische Erstellen eines Inline-Frames eine leichte Sache. Das stimmt grundsätzlich, andererseits gibt es dabei auch ein paar unerwartete Probleme. Der Anfang ist recht einfach, aber man muss den document.readyState des Inline-Frames überprüfen, um herauszubekommen, wann er fertig ist. Und hierbei kann es Schwierigkeiten geben.

Themenseiten: Anwendungsentwicklung, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen Lesen Sie ZDNet-Artikel in Google Currents ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Versteckte Frames für clientseitiges Caching

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *