Versteckte Frames für clientseitiges Caching

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.

Page: 1 2

ZDNet.de Redaktion

Recent Posts

Google stopft schwerwiegende Sicherheitslöcher in Chrome 124

Zwei Use-after-free-Bugs stecken in Picture In Picture und der WebGPU-Implementierung Dawn. Betroffen sind Chrome für…

1 Tag ago

Studie: 91 Prozent der Ransomware-Opfer zahlen Lösegeld

Die durchschnittliche Lösegeldzahlung liegt bei 2,5 Millionen Dollar. Acht Prozent der Befragten zählten 2023 mehr…

1 Tag ago

DMA: EU stuft auch Apples iPadOS als Gatekeeper ein

Eine neue Analyse der EU-Kommission sieht vor allem eine hohe Verbreitung von iPadOS bei Business-Nutzern.…

1 Tag ago

Chips bescheren Samsung deutlichen Gewinnzuwachs

Das operative Ergebnis wächst um fast 6 Billionen Won auf 6,64 Billionen Won. Die Gewinne…

2 Tagen ago

Chrome: Google verschiebt das Aus für Drittanbietercookies

Ab Werk blockiert Chrome Cookies von Dritten nun frühestens ab Anfang 2025. Unter anderem gibt…

2 Tagen ago

BAUMLINK: Wir sind Partner und Aussteller bei der Frankfurt Tech Show 2024

Die Vorfreude steigt, denn BAUMLINK wird als Partner und Aussteller bei der Tech Show 2024…

2 Tagen ago