URL als Variable an neues Fenster übergeben

[Andre]

Hallo,

ich habe folgendes Problem. Ich habe per document.write() den HTML-Code für ein Frameset in ein neues Fenster geschrieben. Alles klappt wunderbar. Nur leider offnet sich des Frame (die URL) welche ich als Variable übergeben habe nicht. Obwohl die richtige URL im Quelltext der neuen Seite richtig drin steht.

Wo liegt der Fehler?

PS: Hier kan man sich das ganze Dielemma mal ansehen.
    http://www.goldguysaffen.de/test2.htm

Grüße - Andre

[molily]

Hallo Andre,

ich habe folgendes Problem. Ich habe per document.write() den HTML-Code für ein Frameset in ein neues Fenster geschrieben.

Bitte beschreibe nicht nur deinen Lösungsweg, sondern auch das, was du im Endeffekt vorhast - du möchtest anscheinend das zugehörige Frameset nachladen, wenn der/die BenutzerIn die Unterseite aufruft.

Alles klappt wunderbar.

Nein, bei mir öffnen sich nacheinander dutzende Fenster mit demselben Inhalt, weil die Seite sich immer wieder erneut selbst aufruft. Dies liegt auch und vor allem daran, dass deine Abfrage if (self!="Inhalt") nicht funktioniert.

Nur leider offnet sich des Frame (die URL) welche ich als Variable übergeben habe nicht.

Seltsam - vielleicht erkennt der MSIE die Rekursion. Wenn man sich den Quelltext des Framesets über javascript:window.alert(document.body.innerHTML); in der Adressleiste ausgeben lässt, erscheint wie du sagst unter anderem ein frame-Element mit der genannten Adresse.
Im Opera und Mozilla wird brav ein Fenster nach dem anderen geladen...

Obwohl die richtige URL im Quelltext der neuen Seite richtig drin steht.

Wie gesagt, es ist entweder ein Fehler oder ein Feature des Internet Explorers. Dies ist aber mehr oder weniger irrelevant, da du für deine Frame-Nachlade-Aktionen einen völlig anderen Ansatz wählen solltest, nämlich zuerst einmal kein window.open() und zum zweiten kein mit JavaScript generiertes Frameset; dies solltest du serverseitig erledigen.
In </archiv/2003/2/37440/#m205284> habe ich erst kürzlich detailliert beschrieben, wie sich das zugehörige Frameset nachladen lässt, bitte beachte die Links darin.

Ich hoffe, ich habe dein Kern- beziehungsweise Ursprungsproblem getroffen.

Grüße,
Mathias

[Andre]

Hallo Mathias,

Bitte beschreibe nicht nur deinen Lösungsweg, sondern auch das, was du im Endeffekt vorhast - du möchtest anscheinend das zugehörige Frameset nachladen, wenn der/die BenutzerIn die Unterseite aufruft.

Ja, das ist genau meine Problemstellung. Und dein Lösungsansatz mit PHP ist natürlich naheliegend. Ich denke mit PHP stellt sich das Problem auch garnicht so. Da ich ja ohnehin die Seite jeweils zusammenbauen (lassen) kann. Kurz um PHP wäre klasse, wenn ich dafür im Moment Geld hätte.

Gibt es vielleicht eine "abgespeckte" Lösung für mein Problem? Mir würde es schon reichen, wenn ich per Link das Frameset laden und ein entsprechendes Frame reinladen könnte. Ein Link auf meine Homepage habe ich ja eh auf jede unterseite gestellt.

Also erstmal Danke für DEINE kompetente Antwort - hat mir in jedem Fall die Augen geöffnet. Und ich weiss jetzt was das Ziel ist - PHP.

Grüße - Andre

[Alexander Foken]

Moin Moin !

Da Du zum Nachladen des Framesets ohnehin Javascript brauchst, kannst Du natürlich auch das Frameset mit Javascript aufbauen (und immer schön eine Alternative für Suchmaschinen und Browser ohne/mit abgeschaltetem Javascript bereithalten). Ich will nicht behaupten, daß ich die perfekte Lösung dafür gefunden habe (bei einigen Exoten-Browsern geht's nämlich noch nicht so ganz), aber ich denke, mein Ansatz funktioniert meistens (zumindest mit Netscape ab 4, IE ab 4, Mozilla, Opera, iCab, teilweise auch mit dem Konqueror und Safari). Schau's Dir einfach an, wie ich es auf meiner Homepage (http://www.foken.de/alexander) gemacht habe - Abschreiben erlaubt.

Alexander

[molily]

Hallo, Andre und Alexander,

Da Du zum Nachladen des Framesets ohnehin Javascript brauchst, kannst Du natürlich auch das Frameset mit Javascript aufbauen

Nein, das hat den Nachteil, dass, falls JavaScript deaktiviert ist, gar kein Frameset angezeigt wird.

Ich will nicht behaupten, daß ich die perfekte Lösung dafür gefunden habe [...]
(http://www.foken.de/alexander) gemacht habe

Oh, das finde ich persönlich sehr problematisch. Wie schon gesagt gibt es ohne JavaScript gar kein Frameset. Das Script, was du meinst, beginnt in Zeile 205, in einem script-Element im head-Element. Dort im head gibst du mit document.write Frameset-Code aus, der aber keinesfalls in den head darf. Dort, wo eigentlich das Frameset und darin ein noframe-Element gehört, gibt es bei dir nur ein noscript-Element (was zwar auf dasselbe herauskommt, aber mit noframes hat das nichts zu tun, es dürfte eher in die Kategorie Fehlertoleranz fallen, falls Suchmaschinenrobots und Browser alles richtig anzeigen).
Weiterhin natürlich http://validator.w3.org/check?uri=http%3A%2F%2Fwww.foken.de%2Falexander%2F...

Dein Code ist durchaus in gewisser Hinsicht hilfreich, denn du extrahierst die URL aus dem Query String:

...
content='welcome.html';
if (location.href.indexOf('?')>=0) {
 content=location.href;
 i=1+content.indexOf('?');
 content=content.substr(i,content.length-i);
}
last=content;
...

Und auf den Unterseiten:
if (top==self) {
 window.location.href='../?internet/homepage.html';
} ...

Das läuft mehr oder weniger auf die in http://aktuell.de.selfhtml.org/artikel/javascript/dyn-frames/index.htm vorgestellte Lösung hinaus, wobei ich wie gesagt diese mit statischem Frameset anstatt dein mit JavaScript generiertes Frameset empfehlen würde. Dieser Artikel war auch übrigens in den von mir verlinkten Posting verlinkt - ich rate sonst zu einer Mischlösung, das heißt JavaScript auf den Unterseiten und Perl/PHP/$serverseitigeSprache im Frameset, aber es geht natürlich auch wie in dem Artikel beschrieben ausschließlich mit JavaScript, nur ist besteht dann das Problem, dass es keine zuverlässig funktionierenden Frameset-URLs gibt, das heißt, die Unterseiten lassen sich nicht mit dem jeweiligen Frameset verlinken, es würde nur in Browsern mit JavaScript aber nicht bei Robots funktionieren.

Falls serverseitige Möglichkeiten bestehen, ist ein manueller, generierter HTML-Link sowie ein noframes-Element auf den Unterseiten zusätzlich auch nebenbei hilfreich, wie gesagt. Darüber schreibe ich übrigens momentan einen Artikel, in dem ich einige Möglichkeiten zusammenfasse.

Achja, sagte ich schon, dass Frames nur Ärger bringen? ;))

Grüße,
Mathias

[Alexander Foken]

Moin Moin !

Da Du zum Nachladen des Framesets ohnehin Javascript brauchst, kannst Du natürlich auch das Frameset mit Javascript aufbauen

Nein, das hat den Nachteil, dass, falls JavaScript deaktiviert ist, gar kein Frameset angezeigt wird.

Genau das war das Ziel der ganzen Sache. Von meiner Seite gibt es quasi zwei Versionen: Eine mit Frames und Javascript für den normalen Surfer, und eine ohne Frames und ohne Javascript als Suchmaschinenfutter und für paranoide Surfer (sorry!). Die framelose Version hat (nach einem Klick auf einen Link) eine *lange* Baumübersicht der ganzen Seite (http://www.foken.de/alexander/_simple_nav.html).

Oh, das finde ich persönlich sehr problematisch. Wie schon gesagt gibt es ohne JavaScript gar kein Frameset. Das Script, was du meinst, beginnt in Zeile 205, in einem script-Element im head-Element. Dort im head gibst du mit document.write Frameset-Code aus, der aber keinesfalls in den head darf.

Aber auch nicht in den Body. Ich bin offen für Verbesserungsvorschläge. Wo soll ich den Code denn mit document.write ausgeben ?

Dort, wo eigentlich das Frameset und darin ein noframe-Element gehört, gibt es bei dir nur ein noscript-Element (was zwar auf dasselbe herauskommt, aber mit noframes hat das nichts zu tun, es dürfte eher in die Kategorie Fehlertoleranz fallen, falls Suchmaschinenrobots und Browser alles richtig anzeigen).

Wie gesagt: Frames + Javascript gibt's auf der Seite nur zusammen oder gar nicht.

Weiterhin natürlich http://validator.w3.org/check?uri=http%3A%2F%2Fwww.foken.de%2Falexander%2F...

Autsch!

This page is not Valid HTML 4.01 Frameset!

Below are the results of attempting to parse this document with an SGML parser.

Line 146, column 37: end tag for element "TITLE" which is not open (explain...).

d.writeln('<title>Navigation</title>');
                                       ^

Das fällt wohl in die Kategorie Anfänger-/Flüchtigkeitsfehler. Ich glaube, ich sollte den Validator gleich in den HTML-Generator einbauen. *grummel*

Dein Code ist durchaus in gewisser Hinsicht hilfreich, denn du extrahierst die URL aus dem Query String:

...
content='welcome.html';
if (location.href.indexOf('?')>=0) {
 content=location.href;
 i=1+content.indexOf('?');
 content=content.substr(i,content.length-i);
}
last=content;
...

Und auf den Unterseiten:
if (top==self) {
 window.location.href='../?internet/homepage.html';
} ...

Genau das Ding meinte ich eigentlich.

Das läuft mehr oder weniger auf die in http://aktuell.de.selfhtml.org/artikel/javascript/dyn-frames/index.htm vorgestellte Lösung hinaus, wobei ich wie gesagt diese mit statischem Frameset anstatt dein mit JavaScript generiertes Frameset empfehlen würde.

Normalerweise ja, aber ich will Frames eben nur, wenn ich Javascript haben kann.

Dieser Artikel war auch übrigens in den von mir verlinkten Posting verlinkt - ich rate sonst zu einer Mischlösung, das heißt JavaScript auf den Unterseiten und Perl/PHP/$serverseitigeSprache im Frameset,

"Datt köst extra" - und das ist mir der Spaß nicht wert. Irgendwann einmal, wenn ich reich, alt und grau bin, werde ich einen eigenen Server für die Domain haben. So lange muß es mit der Billiglösung ohne PHP und ohne eigene CGIs gehen.

Achja, sagte ich schon, dass Frames nur Ärger bringen? ;))

Das weiß ich auch. Aber für eine "schöne" Lösung habe ich momentan weder Zeit noch Geld über.

Alexander

[molily]

Hallo, Alexander,

Von meiner Seite gibt es quasi zwei Versionen: Eine mit Frames und Javascript für den normalen Surfer, und eine ohne Frames und ohne Javascript als Suchmaschinenfutter und für paranoide Surfer (sorry!).

Mit Paranoia hat das absolut gar nichts zu tun. Allein zum Abschalten von Frames gibt es viele Gründe, </archiv/2003/1/34680/#m189835>, und das Deaktivieren von JavaScript ist ein Schutzmechanismen, weil viele Seiten JavaScript missbrauchen, </archiv/2003/1/36614/#m200687>, und Browser oft Sicherheitslücken in der JavaScript-Implementation haben.
Dein Begriff »Sicherheitsfanatiker« geht deshalb m.E. soweit an der Realität vorbei, wie es nur möglich ist; das ist nichts als eine urban legend.

Dort im head gibst du mit document.write Frameset-Code aus, der aber keinesfalls in den head darf.

Aber auch nicht in den Body.

Natürlich nicht - ein Frameset-Dokument hat in der Regel kein body-Element, welches nach dem head-Element folgt. Ein Frameset-Dokument kann höchstens ein body-Element im noframes-Element im frameset-Element enthalten: <!ENTITY % noframes.content "(BODY) -(NOFRAMES)">.
http://www.w3.org/TR/html401/present/frames.html#h-16.1 zeigt, wie ein Frameset aufgebaut sein sollte, du musst folglich das frameset-Element *nach* dem head-Element ausgeben. In diesem Frameset-Element muss ein noframes-Element enthalten sein, welches dann die Alternativinformationen enthält, welche du vermutlich auch noch in ein noscript-Element betten müsstest.

Wie du das in jedem Fall passend hinbekommen beziehungsweise jedem gerecht werden willst, ist mir unklar (wenn Frames ausgeschaltet sind und JavaScript an, landet dein Besucher beziehungsweise du auf der Nase, siehe obiger Thread).

Dort, wo eigentlich das Frameset und darin ein noframe-Element gehört, gibt es bei dir nur ein noscript-Element (was zwar auf dasselbe herauskommt, aber mit noframes hat das nichts zu tun, es dürfte eher in die Kategorie Fehlertoleranz fallen, falls Suchmaschinenrobots und Browser alles richtig anzeigen).

Wie gesagt: Frames + Javascript gibt's auf der Seite nur zusammen oder gar nicht.

Das noscript-Element ist nicht nur an falscher Stelle, sondern auch im Grunde unnötig.
Du musst, falls eine Komponente der beiden nicht verfügbar ist, den Alternativinhalt anzeigen. Mit dem noscript-Element verhinderst du, dass die Variante »Frames unterstützt, JavaScript deaktiviert« ins Leere läuft.

Wenn du weiter bei diesem für mich unverständlichen Konzept bleiben willst, würde ich dir folgendes vorschlagen:

<!DOCTYPE ...Frameset...>
<head>...</head>
<frameset>
<script> ...schreibe die beiden frame-Elemente... </script>
<noframes>
<body>Alternativinhalt</body>
</noframes>
</frameset>
</html>

Dadurch dürften alle möglichen Szenarien abgedeckt sein.

Line 146, column 37: end tag for element "TITLE" which is not open (explain...).
    d.writeln('<title>Navigation</title>');

Das fällt wohl in die Kategorie Anfänger-/Flüchtigkeitsfehler.

Ja, der Parser handhabt einen script-Elementinhalt als CDATA, </ wird als Ende des script-Elements angesehen, folglich musst du "</title>" oder "<"+"/title>" schreiben. »The first occurrence of the character sequence "</" (end-tag open delimiter) is treated as terminating the end of the element's content.« (http://www.w3.org/TR/html401/types.html#type-cdata).

Dieser Artikel war auch übrigens in den von mir verlinkten Posting verlinkt - ich rate sonst zu einer Mischlösung, das heißt JavaScript auf den Unterseiten und Perl/PHP/$serverseitigeSprache im Frameset,

"Datt köst extra" - und das ist mir der Spaß nicht wert. Irgendwann einmal, wenn ich reich, alt und grau bin, werde ich einen eigenen Server für die Domain haben. So lange muß es mit der Billiglösung ohne PHP und ohne eigene CGIs gehen.

Das Problem habe ich auch, ich löse es durch einen Präprozessor auf Autorenseite, das heißt vor dem Upload werden die dynamischen und sich ändernden Bestandteile generiert.

Grüße,
Mathias

[molily]

Hallo nochmal,

HUALP, wie man so schön sagt. Mea culpa, mea maxima culpa.

Wenn du weiter bei diesem für mich unverständlichen Konzept bleiben willst, würde ich dir folgendes vorschlagen:

<!DOCTYPE ...Frameset...>
<head>...</head>
<frameset>
<script> ...schreibe die beiden frame-Elemente... </script>
<noframes>
<body>Alternativinhalt</body>
</noframes>
</frameset>
</html>

Dadurch dürften alle möglichen Szenarien abgedeckt sein.

Kann es sein, dass ich zum Teil absoluten Blödsinn geschrieben habe? Noch einmal die Szenarien:

Frames nein, JavaScript nein: der Alternativinhalt wird gezeigt
Frames ja, JavaScript nein: man sieht gar nichts, weil der Alternativinhalt nicht angezeigt wird, das Frameset aber auch nicht (grmbl!)
Frames nein, JavaScript ja: der Alternativinhalt wird gezeigt
Frame ja, JavaScript ja: Frameset wird angezeigt

Habe ich nur das Gefühl, oder lassen sich beide Fälle nicht vereinbaren? Denn wo soll ein noscript-Bereich außerhalb des noframes-Elements unterbringen, vor allem: wie soll im Endeffekt ein valides Frameset herauskommen? Ich habe stark das Gefühl, dass das nicht möglich ist.

Verzeihe bitte, ich dachte, ich hätte alle Eventualitäten bedacht, eigentlich hatte ich die Fälle schon im letzten Posting haarklein untersuchen wollen (ich verhaspelte mich anscheinend gedanklich, weil ich eben die Unvereinbarkeit als Möglichkeit nicht bedacht hatte).

Es geht um eine zweistufige Überprüfung, folglich würde ich zu folgendem raten (jetzt hoffentlich mit Bedacht):

1. Ein normales Vorschaltdokument, welches zunächst nach JavaScript selektiert. In einem noscript-Element wird den Alternativinhalt gezeigt, ein script-Element leitet schnurstracks zu 2).
2. Ein zunächst statisches Frameset, welches später JavaScript aus dem QueryString editiert und die location.href des Frames ändert. Hier wird nach Frames selektiert, in einem noframes-Element wird der Alternativinhalt angeboten.

Szenarien:
Frames nein, JavaScript nein: Besucher bleibt bei 1) hängen und sieht den Alternativinhalt
Frames ja, JavaScript nein: Besucher bleibt bei 1) hängen und sieht den Alternativinhalt
Frames nein, JavaScript ja: Besucher wird bei 1) durchgereicht und bleibt bei 2) hängen und sieht den Alternativinhalt
Frame ja, JavaScript ja: Besucher wird bei 1) durchgereicht und sieht bei 2) das Frameset

Wie gesagt, wenn man nicht darauf Wert legt, dass das Frameset-Dokument irgendwie den Konventionen entspricht, wäre vielleicht folgendes ausreichend:

(am besten kein DOCTYPE - egal welcher angegeben wird, er ist unzutreffend ;))
<html>
<head>...</head>
<script>...Frameset schreiben...</script>
<noscript>Alternativinhalt</noscript>
<noframes>Alternativinhalt</noframes>
</html>

Jedoch...

Szenarien:
Frames nein, JavaScript nein: der Alternativinhalt wird zweimal angezeigt, hualp!
Frames ja, JavaScript nein: der noscript-Alternativinhalt wird angezeigt
Frames nein, JavaScript ja: der noframes--Alternativinhalt wird angezeigt
Frame ja, JavaScript ja: das Frameset wird angezeigt

Wie ließe sich also Szenario eins behandeln, außer über ein zweistufige Überprüfung?

Der entscheidende Punkt ist natürlich, dass die Zahl der Besucher, welche Frames nicht verfügbar/deaktiviert und JavaScript verfügbar und aktiviert haben, verschwindend gering ist. Selbst wenn man diese Gruppe missachtet, löst es nichts an dem Grundproblem, dass ein Frameset Alternativinhalte nur im noframes-Element haben darf, womit folgendes theoretisch in Frage käme:

<html>
<head>...</head>
<script>...Frameset schreiben...</script>
<noframes><noscript>Alternativinhalt/noscript></noframes>
</html>

Szenarien:
Frames nein, JavaScript nein: Alternativinhalt wird angezeigt
Frames ja, JavaScript nein:  Alternativinhalt wird angezeigt
Frames nein, JavaScript ja: das Script schreibt das Frameset, es wird aber ignoriert. noframes wird interpretiert, aber noscript wird ignoriert. Es wird nichts angezeigt, hualp!
Frame ja, JavaScript ja: Alles »paletti« ;)

Selbst wenn man ungültiges Markup schreibt:
<noframes><noscript>Alternativinhalt/noscript></noframes>
..wären die Auswirkungen:

Szenarien:
Frames nein, JavaScript nein: Alternativinhalt wird angezeigt
Frames ja, JavaScript nein: es wird kein Frameset geschrieben, es bleibt nur das noframes Element, dieses wird ignoriert. Es wird nichts angezeigt, hualp!
Frames nein, JavaScript ja: es wird ein Frameset geschrieben, welches nicht interpretiert wird, das noframes-Element wird interpretiert, aber das noscript-element nicht. Es wird nichts angezeigt, hualp.
Frame ja, JavaScript ja: Das Frameset wird wie gewünscht angezeigt.

Bei der Abhängigkeit »Javascript bedingt Frames« weiß ich nicht, wie man alle Fälle in einem Dokument behandeln könnte, weitere Untersuchungen führen auch nicht zum Ziel... Wie gesagt, eine zweistufige Abfrage ist der einzige mir bekannte Fall, welcher auch mit gültigem Markup zu lösen wäre.

Grüße,
Mathias

[Andre]

Hi Alexander,

das ist wie ich finde eine geniale Lösung und genau das was ich gesucht habe. Aber ich glaube um den Code auf meine Bedürfnisse anzupassen brauche ich noch ein bischen eingehendere Javascript-Kenntnisse. Momentan bin ich von dem Code einfach nur erschlagen.

Würde dich ja gerne bitten mir da weiter zu helfen, aber ich denke du hast besseres zu tun als mir das zu stricken. ;)

Grüße - Andre