Bei fehlender HTM-Datei eine Ersatzdatei ins iframe laden

[Uhlig]

Wer kann mir eine Lösung für folgendes Problem anbieten??

Ich habe eine Anwendung mit vielen Dateien in Html, mein Hobby, geschrieben. Die Anwendung läuft nur auf dem PC – keine Server-Anwendung!
Beim Aufrufen der Seite übergebe ich eine Nummer für den gesuchten Inhalt. Die
Dabei rufe ich ein Bild auf und stelle sie neben einer Tabelle mit Daten auf der Seite dar. Wenn dieses Bild nicht vorhanden ist, wird ein Ersatzbild geladen. Das klappt mit dem onerror gut. (Danke für den Tipp)
Leider nicht beim iframe, in dem der dazugehörige Text zur Anzeige kommen soll. Bei fehlender Seite kommt immer nur die Fehlermeldung vom IE! Gibt es eine Möglichkeit, das Vorhandensein der Datei vor dem Aufruf zu prüfen? Dann könnte ich gleich im Ergebnis der Prüfung die Ersatzdatei aufrufen. Habe noch keinen Weg gefunden. Habe Vista mit IE 9.

<script type="text/javascript">
  function Daten() {
    if (window.location.search != "") {
    var An, paar, datei;
    string = (window.location.search)
    paar = string.split("&");
    An = paar[0];
    datei = paar[1];
    Suchausdruck1 = "Nummer=" + datei;
    Suchausdruck2 = "Texte/" + datei + ".htm"
    Suchausdruck3 = "Bilder/" + datei + ".jpg"
    document.all.Tabelle.object.Filter = Suchausdruck1;
    document.all.Tabelle.Reset();
    document.all.Beschreibung.src = Suchausdruck2;
    document.all.Bild.src = Suchausdruck3;
   }
  }
 </script>
...
 <img src="" name="Bild" height="260" alt="" align="left" hspace="40" frameborder="0" onerror="this.src='Bilder/0.jpg';">
...
 <iframe src="" name="Beschreibung" width="100%" height="394" frameborder="0">
...

Danke im Voraus für eine Hilfe

[molily]

Hallo,

Wenn dieses Bild nicht vorhanden ist, wird ein Ersatzbild geladen. Das klappt mit dem onerror gut. (Danke für den Tipp)
Leider nicht beim iframe

Es sollte beim iframe ebenfalls mit onerror klappen. Beim iframe-Element passiert normalerweise ebenfalls einen error-Event, wenn der Inhalt nicht geladen werden kann.

<iframe onerror="…">

Gibt es eine Möglichkeit, das Vorhandensein der Datei vor dem Aufruf zu prüfen?

Nein, JavaScript kann nicht direkt das Dateisystem lesen. Du kannst natürlich Dateien mit XMLHttpRequest im Hintergrund laden und den Fehlerfall behandeln. Ob das im file-Protokoll geht, müsstest du prüfen (du schreibst ja, dass die Anwendung nicht auf einem Server läuft).

Grüße
Mathias

[Tom]

Hello,

Es sollte beim iframe ebenfalls mit onerror klappen. Beim iframe-Element passiert normalerweise ebenfalls einen error-Event, wenn der Inhalt nicht geladen werden kann.

<iframe onerror="…">

Ist onError dann eigentlich reentrant? Also was passiert im onError-Handler, wenn der ebenfalls einen Fehler produziert?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[molily]

Hi!

<iframe onerror="…">

Ist onError dann eigentlich reentrant? Also was passiert im onError-Handler, wenn der ebenfalls einen Fehler produziert?

Der error-Event feuert bei einem Ladefehler der Ressource im iframe. Mit JavaScript-Fehler hat das nichts zu tun, deshalb hat man keine Endlosschleife, wenn eine Exception im error-Handler auftritt.

Es gibt http://de.selfhtml.org/javascript/beispiele/fehlerbehandlung.htm@title=window.onerror, aber hier sind JavaScript-Fehler definitionsgemäß die Verursache des Events. window.onerror ist aber auch nicht reentrant.

Mathias

[Tom]

Hello,

<iframe onerror="…">

Ist onError dann eigentlich reentrant? Also was passiert im onError-Handler, wenn der ebenfalls einen Fehler produziert?

Der error-Event feuert bei einem Ladefehler der Ressource im iframe. Mit JavaScript-Fehler hat das nichts zu tun, deshalb hat man keine Endlosschleife, wenn eine Exception im error-Handler auftritt.

Aber wenn der Handler die URL ersetzt und die neue dann auch wieder nicht da ist, was passiert denn dann? Das gibt doch dann auch wieder onError im iFrame, oder nicht?

Ich muss zugeben, dass ich das Konzept noch nicht ganz durchschaue.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hi,

Der error-Event feuert bei einem Ladefehler der Ressource im iframe. Mit JavaScript-Fehler hat das nichts zu tun, deshalb hat man keine Endlosschleife, wenn eine Exception im error-Handler auftritt.
Aber wenn der Handler die URL ersetzt und die neue dann auch wieder nicht da ist, was passiert denn dann? Das gibt doch dann auch wieder onError im iFrame, oder nicht?

ja, aber Javascript arbeitet ja nicht wirklich nebenläufig. Das Laden des neuen Inhalts (genauer gesagt, das Anfordern) beginnt ja erst, wenn der bis dato arbeitende onerror-Handler endet und der Browser bzw. die Javascript-Engine "Zeit hat", sich um die neu zugeteilten Aufgaben zu kümmern.

Ciao,
 Martin

[Tom]

Hello,

Hi,

Der error-Event feuert bei einem Ladefehler der Ressource im iframe. Mit JavaScript-Fehler hat das nichts zu tun, deshalb hat man keine Endlosschleife, wenn eine Exception im error-Handler auftritt.
Aber wenn der Handler die URL ersetzt und die neue dann auch wieder nicht da ist, was passiert denn dann? Das gibt doch dann auch wieder onError im iFrame, oder nicht?

ja, aber Javascript arbeitet ja nicht wirklich nebenläufig. Das Laden des neuen Inhalts (genauer gesagt, das Anfordern) beginnt ja erst, wenn der bis dato arbeitende onerror-Handler endet und der Browser bzw. die Javascript-Engine "Zeit hat", sich um die neu zugeteilten Aufgaben zu kümmern.

Gut, damit ist Reentranz-Problem also vom Tisch. Aber was ist mit dem zirkulären Verlauf? Wodurch wird der hier ausgeschlossen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo,

ja, aber Javascript arbeitet ja nicht wirklich nebenläufig. Das Laden des neuen Inhalts (genauer gesagt, das Anfordern) beginnt ja erst, wenn der bis dato arbeitende onerror-Handler endet und der Browser bzw. die Javascript-Engine "Zeit hat", sich um die neu zugeteilten Aufgaben zu kümmern.
Gut, damit ist Reentranz-Problem also vom Tisch. Aber was ist mit dem zirkulären Verlauf? Wodurch wird der hier ausgeschlossen?

wird er nicht. Wenn der error-Handler durch das Neu-Besetzen von location.href eine neue Ressource anfordert, die ihrerseits auch wieder nicht geladen werden kann, entsteht eine endlose Abfolge von onerror-Aufrufen. Aber nicht rekursiv, sondern streng sequentiell.

Irgendwie fällt mir dazu wieder der "Triple Fault" ein, den ich in der guten alten Zeit von x86-Assembler (damals konkret 286) kennengelernt habe: Einen Fehler in der Fehlerbehandlungsroutine konnte die 286-CPU noch durch eine weitere Exception abfangen; wenn in diesem Exception-Handler dann _wieder_ ein Fehler auftrat, führte die CPU einen Reset aus.

So ein kontrollierter Abbruch fehlt wohl im hier vorliegenden Fall.

Ciao,
 Martin

[Tom]

Hello,

ja, aber Javascript arbeitet ja nicht wirklich nebenläufig. Das Laden des neuen Inhalts (genauer gesagt, das Anfordern) beginnt ja erst, wenn der bis dato arbeitende onerror-Handler endet und der Browser bzw. die Javascript-Engine "Zeit hat", sich um die neu zugeteilten Aufgaben zu kümmern.
Gut, damit ist Reentranz-Problem also vom Tisch. Aber was ist mit dem zirkulären Verlauf? Wodurch wird der hier ausgeschlossen?

wird er nicht. Wenn der error-Handler durch das Neu-Besetzen von location.href eine neue Ressource anfordert, die ihrerseits auch wieder nicht geladen werden kann, entsteht eine endlose Abfolge von onerror-Aufrufen. Aber nicht rekursiv, sondern streng sequentiell.

Ich sprach ja auch nicht von rekursiv, sondern von zirkulär. :-)

So ein kontrollierter Abbruch fehlt wohl im hier vorliegenden Fall.

Wenn Du auch der Meinung bist, dass das Szenario zu einem solchen Fehler führen könnte, müssen in dem Handler (eigentlich innerhalb _und_ außerhalb) also Maßnahmen ergriffen werden, um das abzufangen. Der Handler muss also in seinem Kontext eine Information ablegen, ob er schon mal eine Ersetzung durchgeführt hat. Oder gibt es bei JavaScript auch Static-Variablen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[tami]

hi Tom,

Wenn Du auch der Meinung bist, dass das Szenario zu einem solchen Fehler führen könnte, müssen in dem Handler (eigentlich innerhalb _und_ außerhalb) also Maßnahmen ergriffen werden, um das abzufangen. Der Handler muss also in seinem Kontext eine Information ablegen, ob er schon mal eine Ersetzung durchgeführt hat. Oder gibt es bei JavaScript auch Static-Variablen?

Du kannst doch mit einer Closure mitzählen:

  
<button id="test">klick</button>  
<script>  
[code lang=javascript]createMemorizer = function() {  
    var counter = 0;  
    memFunc = function() {  
        if (counter === 0) {  
            alert("hallo");  
        } else {  
            alert ("vorbei");  
        };  
        counter += 1;  
    }  
     return memFunc;  
}  
myButton = document.getElementById("test");  
myButton.onclick = createMemorizer();  

~~~</script>[/code]  
  
mfg  
  
tami

[Tom]

Hello tami,

Du kannst doch mit einer Closure mitzählen:

<button id="test">klick</button>
<script>
[code lang=javascript]createMemorizer = function() {
    var counter = 0;
    memFunc = function() {
        if (counter === 0) {
            alert("hallo");
        } else {
            alert ("vorbei");
        };
        counter += 1;
    }
     return memFunc;
}
myButton = document.getElementById("test");
myButton.onclick = createMemorizer();

  
Eigentlich ein ziemlich aufwändiger aufgeblähter Ersatz für eine Zeile  
  
` static var counter = 0; `{:.language-html}  
  
die es tun würde, wenn es static Varaiblen gäbe :-O  
  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
<http://bikers-lodge.com>

[tami]

hi Tom,

Hello tami,

Du kannst doch mit einer Closure mitzählen:

<button id="test">klick</button>
<script>
[code lang=javascript]createMemorizer = function() {
    var counter = 0;
    memFunc = function() {
        if (counter === 0) {
            alert("hallo");
        } else {
            alert ("vorbei");
        };
        counter += 1;
    }
     return memFunc;
}
myButton = document.getElementById("test");
myButton.onclick = createMemorizer();

>   
> Eigentlich ein ziemlich aufwändiger aufgeblähter Ersatz für eine Zeile  
>   
> ` static var counter = 0; `{:.language-html}  
>   
> die es tun würde, wenn es static Varaiblen gäbe :-O  
  
~~~javascript
  
/*jslint browser: true, devel: true */  
var My = {  
    counter : 0  
},  
    myButton = document.getElementById("test");  
myButton.onclick = function () {  
    "use strict";  
    if (My.counter === 0) {  
        alert("hallo");  
    } else {  
        alert("vorbei");  
    }  
    My.counter += 1;  
};  

mfg

tami

[Tom]

Hello,

[...]

Eigentlich ein ziemlich aufwändiger aufgeblähter Ersatz für eine Zeile

static var counter = 0;

die es tun würde, wenn es static Varaiblen gäbe :-O

/*jslint browser: true, devel: true */
var My = {
    counter : 0
},
    myButton = document.getElementById("test");
myButton.onclick = function () {
    "use strict";
    if (My.counter === 0) {
        alert("hallo");
    } else {
        alert("vorbei");
    }
    My.counter += 1;
};

  
Du kennst ja schmutzige Tricks :-)  
  
Das muss ich mir gleich mal in die Sammlung packen.  
Für JavaScript bin ich zwar nicht zuständig, aber man sollte doch immer auch über den Tellerrand luksen.  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
<http://bikers-lodge.com>

[tami]

hi Tom,

Das muss ich mir gleich mal in die Sammlung packen.
Für JavaScript bin ich zwar nicht zuständig, aber man sollte doch immer auch über den Tellerrand luksen.

Javascript ist die meistgenutzte von einem Menschen ausgedachte Sprache gemäß Douglas Crockford. S. molilys Link im Parallelthread zum Google-Theater-Vortrag von ihm.
Der Sicherheitsexperte Marc Stiegler, auf den Crockford verweist, nutzt das Closure in Javascript in einem Beispiel für das Verteilen von einmaligen Berechtigungen, wenn ich das recht verstanden habe. Das ist dann eine "private" Variable. Und insofern "sicher" gegen Außeneinwirkung.

mfg

tami

[1UnitedPower]

Meine Herren!

Eigentlich ein ziemlich aufwändiger aufgeblähter Ersatz für eine Zeile

Das sehe ich ein wenig anders. Das static-Schlüsselwort, wie etwa in C, führt gleich ein ganz neues Konzept ein, während in JavaScript alte Konzepte wiederverwendet werden können, um das selbe Ziel zu erreichen. Ich finde JS in dieser hinsicht weniger komplex.

Aber in tamis Beispiel passieren auch mehrere Dinge, die ich mal aufschlüsseln möchte: Um über mehrere Funktionsaufrufe hinweg einen gemeinsamen Speicher zu nutzen, genügt in JS folgender Code (jsfiddle):

var count = 0;  
function foo(){  
   console.log( ++count );  
}  
foo(); // 1  
foo(); // 2

Wie auch immer, count ist jetzt anfällig gegenüber Seiteneffekten. Wenn wir eine weitere Funktion einführen, die ebenfalls ihre Aufrufe laut mitzählt, kriegen wir ein Problem (jsfiddle):

var count = 0;  
var foo = function foo(){  
   console.log( ++count );  
}  
var bar = function () {  
   console.log( ++count );  
}  
foo(); // 1  
bar(); // 2 !!!  
foo(); // 3 !!!

Hier würden beide Funktionen den selben gemeinsamen Speicher nutzen und deshalb ungewollt interferieren. Um davor zu schützen kann man Closures nutzen:

var foo = (function(){  
   var count;  
   return function(){  
      console.log( ++count );  
   }  
};  
var bar = (function(){  
   var count;  
   return function(){  
      console.log( ++count );  
   }  
};  
  
foo(); // 1  
bar(); // 1  
foo(); // 2

Diese Art von Seiteneffekten ist immer Ursache von Programmzuständen. Bei rein funktionaler Programmierung gibt es diese Fehlerklasse nicht, deshalb konnten wir sie durch Closures auflösen. Das ist übrigens ein sehr nützliche Eigenschaft von funktionalen Programmiersprachen, die sich bei Parallelisierung bemerkbar macht. Eine andere, imho. elegantere Lösung, die das selbe Prinzip nutzt, sieht so aus (jsfiddle):

var foo = function () {  
   console.log( ++this.count );  
}.bind({count: 0});  
  
var bar = function () {  
   console.log( ++this.count );  
}.bind({count: 0});  
  
foo(); // 1  
bar(); // 1  
foo(); // 2

[tami]

hi 1UnitedPower,

Hier würden beide Funktionen den selben gemeinsamen Speicher nutzen und deshalb ungewollt interferieren. Um davor zu schützen kann man Closures nutzen:

var foo = (function(){

var count;
   return function(){
      console.log( ++count );
   }
};
var bar = (function(){
   var count;
   return function(){
      console.log( ++count );
   }
};

foo(); // 1
bar(); // 1
foo(); // 2

  
Der Code läuft nicht, weil hinten jeweils "());" fehlt.  
  
~~~javascript
/*jslint browser: true, devel: true */  
var foo = (function () {  
    "use strict";  
    var count = 0;  
    return function () {  
        count += 1;  
        console.log(count);  
    };  
}());  
var bar = (function () {  
    "use strict";  
    var count = 0;  
    return function () {  
        count += 1;  
        console.log(count);  
    };  
}());  
  
foo(); // 1  
bar(); // 1  
foo(); // 2

So funzts.

mfg

tami

[1UnitedPower]

Meine Herren!

Der Code läuft nicht, weil hinten jeweils "());" fehlt.

Das war natürlich das einzige Beispiel, das ich nicht gefiddelt habe :D
Die äußeren Klammern könnte man sogar ganz entfallen lassen, weil an dieser Stelle durch die Zuweisung (foo = …) bereits klar ist, dass eine function-Statement und kein -Expression folgt. Aber ich bevorzuge es, sie trotzdem immer zu notieren, das schafft Klarheit. Danke für die Korrektur!

[Tom]

Hello,

nur noch ein Wort an Rande, warum ich hier so auf dem Abfangen der (ungewollten) Schleife rumreite.

Hier gab es in den letzten Wochen mehrfach den Wunsch, per Client (also JavaScript) Bilder, Seiten, Elelemente ersatzweise nachzuladen, wenn die ursprünglich gewünschten nicht erreichbar/nicht vorhanden sind.

Und ich hab auf der Webseite der ARD einen Link, auf den ich ein paarmal hereingefallen bin. Da hat auch jemand eine Schleife aufgebaut. Die verhindert sogar, dass man den Browser beendet und blockiert den ganezen Rechner. Man kann entweder nur ewig lange warten oder den Rechner ausschalten.

Wenn man also auch nur die Möglichkeit des Entstehens einer solchen Schleife erkennt, sollte man sie programmtechnisch vermeiden.

Die Aussage von Uhlig https://forum.selfhtml.org/?t=217584&m=1495062 finde ich daher grob fahrlässig.

Oder ist das jetzt Korinthenkackerei?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[tami]

hi Tom,

Und ich hab auf der Webseite der ARD einen Link, auf den ich ein paarmal hereingefallen bin. Da hat auch jemand eine Schleife aufgebaut. Die verhindert sogar, dass man den Browser beendet und blockiert den ganezen Rechner. Man kann entweder nur ewig lange warten oder den Rechner ausschalten.

Wenn man also auch nur die Möglichkeit des Entstehens einer solchen Schleife erkennt, sollte man sie programmtechnisch vermeiden.

Die Aussage von Uhlig http://forum.de.selfhtml.org/my/?t=217584&m=1495062 finde ich daher grob fahrlässig.

Oder ist das jetzt Korinthenkackerei?

Nee, das wäre nutzerfreundlich, diesen Versuch (s. Beispiel mit Closure) einmal zu unternehmen und dann abzubrechen, in dem man mitzählt oder vielleicht den aktuellen Location.href auslesen kann, oder den http-Statuscode, aber den kriegt man nur bei XMLHttpRequest vermutlich ...;

mfg

tami

[tami]

hi tami,

... oder den http-Statuscode, aber den kriegt man nur bei XMLHttpRequest vermutlich ...;

Blödsinn, dadaurch wird ja der onerror getriggert.

mfg

tami

[tami]

hi 1UnitedPower,

Meine Herren!

Der Code läuft nicht, weil hinten jeweils "());" fehlt.

Das war natürlich das einzige Beispiel, das ich nicht gefiddelt habe :D
Die äußeren Klammern könnte man sogar ganz entfallen lassen, weil an dieser Stelle durch die Zuweisung (foo = …) bereits klar ist, dass eine function-Statement und kein -Expression folgt. Aber ich bevorzuge es, sie trotzdem immer zu notieren, das schafft Klarheit. Danke für die Korrektur!

Jslint sagt dazu: "Wrap an immediate function invocation in parentheses to assist the reader in understanding that the expression is the result of a function, and not the function itself."

mfg

tami

[molily]

müssen in dem Handler (eigentlich innerhalb _und_ außerhalb) also Maßnahmen ergriffen werden, um das abzufangen. Der Handler muss also in seinem Kontext eine Information ablegen, ob er schon mal eine Ersetzung durchgeführt hat.

Das kann man machen, aber üblicher ist, dass der Handler sich einfach selbst entfernt. Die meisten Event-Handling-Bibliotheken bieten dafür Funktionen an.
Z.B. http://api.jquery.com/one/

Das von mir initial erwähnte <iframe onerror="…">, also das Unterbringen von JavaScript-Event-Handlern im HTML, ist bekanntlich kein guter Stil. Wobei sich der Handler hier ebenfalls selbst entfernen könnte: this.onerror = null;

Global zugängliche »statische« Variablen, die Status zentral speichern, sind eigentlich in allen Programmiersprachen ein Anti-Pattern. In JavaScript kann man sowohl einfach Objekte mit Status erzeugen, als auch Status über Closures in Funktionen verfügbar machen, ohne dass der Status von außen zugänglich ist.

http://molily.de/js/organisation-module.html
http://molily.de/js/organisation-verfuegbarkeit.html#closures

Mathias

[Tom]

Hello,

Das kann man machen, aber üblicher ist, dass der Handler sich einfach selbst entfernt. Die meisten Event-Handling-Bibliotheken bieten dafür Funktionen an.
Z.B. http://api.jquery.com/one/

Das von mir initial erwähnte <iframe onerror="…">, also das Unterbringen von JavaScript-Event-Handlern im HTML, ist bekanntlich kein guter Stil. Wobei sich der Handler hier ebenfalls selbst entfernen könnte: this.onerror = null;

Dankeschön.

Noch ein Trick, der in niederen Sprachen nicht funktionieren würde, weil dort kein Garbage Collector vorhanden ist. Dann würden lauter Speicherleichen entstehen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Uhlig]

Hello,
Die Ersatzdatei ist immer da - keine Schleife
Liebe Grüße aus Sachsen
Uhlig

[Tom]

Hello Uhlig,

Hello,
Die Ersatzdatei ist immer da - keine Schleife

Da verstehst Du etwas falsch.
Doch Schleife!
Die Ersatzdatei könnte nicht erreichbar sein. Der Client hängt sich dann auf.

Gegen die Schleife musst Du auf alle Fälle etwas tun, denn sie bleibt in der Programmierung versteckt, auch wenn die Daten meistens etwas dagegen tun. Das ist so, wie eine noch nicht ausgebrochene Krankheit, deren Verusacher aber schon im Körper stecken.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg