JS-Block schreibt JS-Block???

[foomaker]

Tach zusammen,

Ich lese in einem HTML Script innerhalb des bodys folgendes JS-Script:

  
<script type="text/javascript">  
<!--  
document.write(unescape(\"%3Cscript id='1' src='\"http://www.example.com/scripts/doDomething.js' type='text/javascript'%3E%3C/script%3E\"));  
//-->  
</script>  

Dieses Skript schreibt - wie man unschwer erkennen - ins doc einen JS-Block.

Kann mir einer erklären, was das für einen Sinn macht? Warum der Umweg über document.write?
Warum steht da nicht schlicht

  
<script id="1" src="http://www.example.com/scripts/doDomething.js" type="text/javascript"></script>  

?

Gruß vom foomaker

[JürgenB]

Hallo foomaker,

welchen Sinn das in deinem Fall macht, kann ich nicht sagen. Ich benutze so eine Konstruktion, um in einem Script die noch zusätzlich benötigten "Module" nachzuladen.

Gruß, Jürgen

[foomaker]

Hallo Jürgen,

welchen Sinn das in deinem Fall macht, kann ich nicht sagen. Ich benutze so eine Konstruktion, um in einem Script die noch zusätzlich benötigten "Module" nachzuladen.

Das war auch mein erster Gedanke. So eine Konstruktion macht dann ja Sinn, wenn im "document.write..." Block noch Parameter abgefragt werden, anhand derer "entschieden" wird, WAS in den Body nachgeladen/geschrieben wird.
In diesem Fall jedoch findet keine Fallüberprüfung statt. Es wird einfach platt etwas reingeschrieben, was auch schlicht SO direkt drinstehen könnte.

Hat das vielleicht was mit einer etwaigen w3c-Validator-Überprüfung zu tun?

Gruß vom foomaker

[JürgenB]

Hallo foomaker,

da müssen auch nicht unbedingt Parameter mit übergeben werden. Ich benutze die Konstruktion nur um das Einbinden der Scripte für den Anwender einfacher zu machen. D.H. der Anwender bindet das "Haupt-Script" ein, und dieses kümmert sich um alles weitere. Und wenn bei späteren Versionen sich die "Zusatzscripte" ändern, muss in den HTML-Dokumenten nichts geändert werden.

Gruß, Jürgen

[foomaker]

Hallo Jürgen,

... wenn bei späteren Versionen sich die "Zusatzscripte" ändern, muss in den HTML-Dokumenten nichts geändert werden.

Jap, ach das macht durchaus Sinn.
Die Sinnhaftigkeit in meinem Beispiel bleibt mir aber weiter verschlossen.
Goolge selbst empfiehlt selbst diese Konstruktion, allerings ohne zu erklären, WARUM der JS-Block über den Umweg "document.write..." erzeugt wird.

Gruß vom foomaker

[Struppi]

Die Sinnhaftigkeit in meinem Beispiel bleibt mir aber weiter verschlossen.
Goolge selbst empfiehlt selbst diese Konstruktion, allerings ohne zu erklären, WARUM der JS-Block über den Umweg "document.write..." erzeugt wird.

Kann ich mir nicht vorstellen.

Denn man sollte auch nicht verschweigen, dass dieses Konstrukt auch Nachteile hat. Du kannst nicht mehr sofort auf Variabeln und Funktionen zugreifen, was u.U. diese Schreibweise, gegenüber dem klassischen einbinden von Skripten, völlig unbrauchbar macht.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Denn man sollte auch nicht verschweigen, dass dieses Konstrukt auch Nachteile hat

Man kann ein zweites JavaScript (als externe Datei) auch über appendChild (Kind von head, oder von sonst einem Element) einbinden.

Nachteile gibt es nicht, wenn man weiß, bzw. festgelegt hat:
 - was das erste Sript macht
 - was das appendChilded zweites Script machen soll

Vorteile gibt es allerdings auch keine - abgesehen davon, dass nur User mit Firebug o. etwas Ä. sehen können, was passiert. Außerdem verleiht es einem die Möglichkeit, einem Seitenautor nur die Zeile mit dem Erstscript einzubinden, dieses kann dann weitere Skripte laden, die der Autor »bei sich« nicht hochzuladen braucht.

Viele Grüße aus Frankfurt/Main,
Patrick

[JürgenB]

Hallo Patrick,

Man kann ein zweites JavaScript (als externe Datei) auch über appendChild (Kind von head, oder von sonst einem Element) einbinden.

da muss man aber aufpassen. Je nach dem, wie man es macht, läuft das Einbinden synchron oder asynchron:

siehe http://www.j-berkemeier.de/test/Nachladen.html und die Kommentare im Quelltext.

Gruß, Jürgen

[Patrick Andrieu]

Hallo JürgenB!

da muss man aber aufpassen.

Ich würde sagen, man muss wissen, was man macht ;)

siehe http://www.j-berkemeier.de/test/Nachladen.html und die Kommentare im Quelltext.

Schönes Beispiel, aber mit Ajax habe ich leider nicht sehr viel an der Mütze (Hut trag' ich keinen) ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[JürgenB]

Hallo Patrick,

Schönes Beispiel, aber mit Ajax habe ich leider nicht sehr viel an der Mütze (Hut trag' ich keinen) ;)

ist ja auch Sjax. :)

Gruß, Jürgen

[JürgenB]

Hallo Struppi,

Denn man sollte auch nicht verschweigen, dass dieses Konstrukt auch Nachteile hat. Du kannst nicht mehr sofort auf Variabeln und Funktionen zugreifen, was u.U. diese Schreibweise, gegenüber dem klassischen einbinden von Skripten, völlig unbrauchbar macht.

das stimmt. Wenn aber alle Scripte erst über den window.onload angestoßen werden, spielt das keine Rolle. Wenn nicht, hilft evtl. ein synchroner http-Request.

Gruß, Jürgen

[Struppi]

das stimmt. Wenn aber alle Scripte erst über den window.onload angestoßen werden, spielt das keine Rolle.

Aber nur dann.

Wenn du mehrere Dateien auf die Art einbindest und diese greifen auf Funktionen oder Objekte von anderen eingebundenen Skripten zu, wird es schon komplizierter. Die Methode von Patrick ist wohl am sinnvollsten.

Struppi.

[JürgenB]

Hallo Struppi,

... Die Methode von Patrick ist wohl am sinnvollsten.

Patrick hat jetzt nicht im Detail angegeben, wie er Scripte einbindet. Aber nach meiner Erfahrung läuft das Erzeugen des script-Elements (createElement, appendChild) und das anschließende Setzen des src-Attributs asynchron. (V3)

Synchron lief nur das setzen des text-Attributes mit dem Inhalt der Script-Seite, der über einen synchronen http-Request geliefert wurde. (V1b)

Gruß, Jürgen

Test Javascript nachladen

[Patrick Andrieu]

Hallo JürgenB!

... Die Methode von Patrick ist wohl am sinnvollsten.
Patrick hat jetzt nicht im Detail angegeben, wie er Scripte einbindet.

Ich komme derzeit nicht dazu, mein angefangenes Beispiel zu Ende zu schreiben. Nur so viel: Das erste Skript enthält zwei oder drei Functionen, auf die das appendChilded, zweites Skript zurückgreift. Bisherige Tests in verschiedenen Browsern zeigten bisher keine Anomalien.

Viele Grüße aus Frankfurt/Main,
Patrick

[ChrisB]

Hi,

Goolge selbst empfiehlt selbst diese Konstruktion, allerings ohne zu erklären, WARUM der JS-Block über den Umweg "document.write..." erzeugt wird.

Wo? Link?

MfG ChrisB

[Cheatah]

Hi,

Das war auch mein erster Gedanke.

meiner war Obfuscation. Ziemlich billige wäre das dann allerdings.

Hat das vielleicht was mit einer etwaigen w3c-Validator-Überprüfung zu tun?

Wäre möglich, zumal die ID ungültig ist.

Cheatah