Framepage in Frames aufrufen

[STeve]

Hy

Wie kann ich ( habe zu wenig Programmierkennt.) ein ? JavaScript machen, dass beim direkten Aufruf einer Unterseite zB. http://www.buerogummi.ch/pages/artikelangebot/marken/herma.htm

diese Seite im Frameset der ganzen Seite lädt. (www.buerogummi.ch)

Wäre super froh um Hilfe - habe schon Stunden im Bemühen um eine Lösung verbracht.

Thank you so mutch

[Johannes Zeller]

Hallo STeve

Wie kann ich ( habe zu wenig Programmierkennt.) ein ? JavaScript machen, dass beim direkten Aufruf einer Unterseite zB. http://www.buerogummi.ch/pages/artikelangebot/marken/herma.htm

</faq/#Q-19>

diese Seite im Frameset der ganzen Seite lädt. (www.buerogummi.ch)

Ich würde dir an deiner Stelle mal http://aktuell.de.selfhtml.org/artikel/javascript/dyn-frames/ ansehen.

Schöne Grüße

Johannes

[Ingo]

Ich würde dir an deiner Stelle mal http://aktuell.de.selfhtml.org/artikel/javascript/dyn-frames/ ansehen.

hi,
diese methode hatte ich früher auch benutzt, bis ich nach recht viel experimentieren und suchen eine lösung gefunden hatte, die z.b. keinen abbruch bei der framenamenabfrage über die domaingrenze hinweg verursacht und bei modernen browsern außer dem ie nicht erst das standard-frameset anzeigt:
http://www.1ngo.de/web/framesets.html

gruß
Ingo

[molily]

Hallo Ingo,

diese methode hatte ich früher auch benutzt, bis ich nach recht viel experimentieren und suchen eine lösung gefunden hatte, die z.b. keinen abbruch bei der framenamenabfrage über die domaingrenze hinweg verursacht und bei modernen browsern außer dem ie nicht erst das standard-frameset anzeigt:
http://www.1ngo.de/web/framesets.html

| Framesets sind zwar vom W3C als deprecated (missbilligt) eingestuft und im aktuellen XHTML Strict nicht mehr zulässig

Frames sind nicht im Sinne der Specs »deprecated«! Frames sind formal gesehen Teil der Transitional-DTD, weil sie eine reine Präsentationstechnik sind und somit tatsächlich nicht »Strict«. Wenngleich die Elemente (frameset, frame, noframes, iframe...) und Attribute (u.a. target) rund um Frames ebenso wie Deprecated-Elemente und -Attribute nur auf die visuelle Ausgabe ausgelegt ist und somit »presentational markup« sind, sind sie nicht »deprecated«.

Frames waren nie in den Strict-Varianten von HTML zulässig, insofern ist der Hinweis, dass Frames in XHTML 1.0 Strict nicht erlaubt sind, unpassend. XHTML 1.0 Frameset existiert. Der XFrames-Standard ist auf dem Weg. So what?(tm)

Ich wiederhole mich...
</archiv/2003/2/38526/#m211664>
</archiv/2003/3/40483/#m221914>

Zum Inhalt selbst:

Du schreibst:
»Man sollte daher entsprechende Vorsorge treffen und:

• auf jeder Seite Anbieterangaben und einen Link zur Navigation bzw. dem Frameset setzen oder
• serverseitige Lösungen verwenden, um eine Anzeige im Frameset zu realisieren oder
• das Frameset mittels JavaScript nachladen«

Dies sollte kein ausschließendes »oder« sein. Ein breadcrumb trail bzw. ein statischer Link, welcher die aktuelle Seite im Frameset nachlädt, sollte immer angeboten werden. Serverseitige Möglichkeiten sollten soweit wie möglich genutzt werden - sie sind immer zuverlässiger als Javascript. Javascript darf nur die optionale Sahnehaube sein.

Ich würde immer dazu raten, eine komplette Weiterleitung zu realisieren, und zwar mit location.href, nicht mit location.replace. Denn es gibt viele Fälle, in welchen die Seite bewusst außerhalb des Framesets gezeigt werden soll (Drucken, Skalieren, kleiner Bildschirm, ...). Dann ist es zumindest in einigen Browsern (dennoch leider zu wenigen) möglich, die Seite durch die Zurück-Funktion einzeln anzuzeigen. Des weiteren finde ich das Neubeschreiben des Fensters insofern unvorteilhaft, dass die URL dieselbe bleibt. Ich fände es angemessener, wenn möglich die »Frameset-URL« (frameset.html?seite.html) anzuzeigen, weil der Part des Generieren des Framesets serverseitig gelöst werden kann. Somit ist er nicht von JavaScript abhängig. Ansätze bietet http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/ - aber keinesfalls den noframes-Bereich leer lassen! Auch dort muss neben generellen Links am Anfang der Link zur als Parameter übergebenen Seite ausgegeben werden.

Generell sind solche automatischen Nachlade-Skripte arg problematisch, da es eben vorkommt, dass manche, um die Probleme von Frames zu umgehen, das Dokument bewusst außerhalb des Framesets ansehen wollen.

Die Abfrage von navigator.appName ist letztlich sinnfrei, siehe Archiv. Das Script ist in dieser Form nicht nachhaltig.

onerror = FremdURL ist insofern blöd, dass auch andere unkalkulierbare Fehler auftreten können und in diesen Fällen unpassend ist, die Funktion FremdURL auszuführen.

Was document.images damit zu tun hat, ist mir schleierhaft, speziell in der Funktion LadeFrame - man sollte auf die Methoden und Objekte prüfen, die benutzen zu gedenkt.

Grüße,
Mathias

[Ingo]

Hallo Mathias,

zunächst mal Danke für die intensive Durchforstung meines Artikels.

Frames sind nicht im Sinne der Specs »deprecated«!

Da hast Du natürlich recht, auch wenn's im Grunde eine Spitzfindigkeit ist (zwar nicht mißbilligt aber mit KW-Vermerk..). Ich habe diese Passage daher rausgenommen.

Dies sollte kein ausschließendes »oder« sein. Ein breadcrumb trail bzw. ein statischer Link, welcher die aktuelle Seite im Frameset nachlädt, sollte immer angeboten werden.

Damit hast Du ja eigentlich recht, auch wenn es wohl Viele für überflüssig, doppelt und nicht ins Design passend ansehen.
Wenn ich jetzt so drüber nachdenke, verlasse ich mich viel zu sehr auf's Nachladen des Framesets. Ein UND ist hier wirklich sinnvoller.

Daß serverseitige Lösungen zuverlässiger sind, ist mir klar, aber sie stehen auch nicht Jedem zur Verfügung. Da ich aber gerade beim Überarbeiten bin, bringe ich dies auch noch zum Ausdruck.

eine komplette Weiterleitung zu realisieren, und zwar mit location.href, nicht mit location.replace. Denn es gibt viele Fälle, in welchen die Seite bewusst außerhalb des Framesets gezeigt werden soll

Dem steht jedoch entgegen, daß die meisten Browser nichts davon haben und das Frameset erneut nachgeladen werden muß. Und wer die Seite ohne Frameset nutzen will, kann dies bei meinem Script auch tun, nachdem er sie lokal gespeichert hat...

finde ich das Neubeschreiben des Fensters insofern unvorteilhaft, dass die URL dieselbe bleibt

Ok, ist ein Minuspunkt dieser Methode. Aber mich stört doch mehr, wenn zunächst die Standardseite des Sets geladen wird und

danach erst die eigentliche Seite. Und ich vermute mal, daß das den meisten Usern so geht - jedenfalls denjenigen, die nicht mit dem IE unterwegs sind.

Die Abfrage von navigator.appName ist letztlich sinnfrei

Das sehe ich nun in diesem Fall aber nicht so. Wenn sich z.B. ein Opera als IE ausgibt, bekommt er die IE-Routine, mit der er auch etwas anfangen kann. Es geht mir hierbei lediglich darum, dem IE nicht die Alternativroutine vorzusetzen, da sie bei ihm nicht funktioniert. Und den IE kann man damit doch zuverlässig erkennen, oder irre ich mich hier?

onerror = FremdURL ist insofern blöd, dass auch andere unkalkulierbare Fehler auftreten können und in diesen Fällen unpassend ist, die Funktion FremdURL auszuführen.

zugegeben... aber ich möchte mit meiner Routine ja auch fremde Framesets sprengen. Wenn hier Jemand eine Möglichkeit kennt, wie man die Anzeige im fremden Frameset zuverlässig ohne Fehler bei der Domainüberschreitung erkennen kann, wäre ich sehr froh. Denn mir gefällt diese Lösung auch nicht. Und Du kannst mir gauben: bevor ich dazu übergegangen war, hatte ich selfhtml rauf und runter gelesen, überall im Netz nach Alternativen gesucht und schließlich mein Script wirklich eingehend auf mögliche Fehlerquellen getestet.

Was document.images damit zu tun hat, ist mir schleierhaft

Tja, da hast Du mich jetzt erwischt... Ich war - wie ich gerade mal nachgeschlagen habe - der irrigen Annahme, daß der IE das erst später als location.replace() kennengelernt hätte. Ist also wirklich unnütz und jetzt raus.

Gruß
Ingo

[molily]

Hallo,

Dies sollte kein ausschließendes »oder« sein. Ein breadcrumb trail bzw. ein statischer Link, welcher die aktuelle Seite im Frameset nachlädt, sollte immer angeboten werden.

Damit hast Du ja eigentlich recht, auch wenn es wohl Viele für überflüssig, doppelt und nicht ins Design passend ansehen.

Tja, das lässt sich schlecht verhindern. Im Übrigen denke ich nicht, dass ein zusätzlicher breadcrumb trail zur Orientierung überflüssig ist - aber das hängt von der Sitestruktur ab. Verschachtelte Sitestrukturen sind mit Frames nicht einfach intuitiv zu lösen, da helfen solche Pfadangaben durchaus, ganz unabhängig von der Nachlade-Problematik.

eine komplette Weiterleitung zu realisieren, und zwar mit location.href, nicht mit location.replace. Denn es gibt viele Fälle, in welchen die Seite bewusst außerhalb des Framesets gezeigt werden soll

Dem steht jedoch entgegen, daß die meisten Browser nichts davon haben und das Frameset erneut nachgeladen werden muß.

Deshalb liegt es eher näher, auf automatische Weiterleitungen zu verzichten.

Und wer die Seite ohne Frameset nutzen will, kann dies bei meinem Script auch tun, nachdem er sie lokal gespeichert hat...

Solche umständliche Lösungen würde ich den Benutzern möglichst nicht zumuten. Im Idealfall müsste eine Kaskade von Links angeboten werden, um die gängigen Probleme von Frames umgehen zu können:

• Ein breadcrumb trail mit Frameset-URLs, falls Frames zur Verfügung stehen und gewünscht sind - die Notwendigkeit kann nicht überprüft werden.
• Ein breadcrumb trail mit direkten URLs zu den Verzeichnisdokumenten, welche meinst als Navigationen fungieren (logisch gesehen ein rel="up toc" o.ä.), falls Frames nicht zur Verfügung stehen oder unerwünscht sind - dies ist ansatzweise mit noframes lösbar, aber generell ist die Notwendigkeit nicht überprüfbar.
• Ein Link, um das aktuelle Dokument im Frameset anzuzeigen - ist immer nötig, wenn Frames zur Verfügung stehen und per JavaScript-Überprüfung kein Frameset nachweisbar ist, aber generell ist die Notwendigkeit nicht überprüfbar.
• Ein Link, um das aktuelle Dokument einzeln anzuzeigen - ist immer nötig, wenn Frames zur Verfügung stehen und per JavaSscript-Überprüfung das Frameset nachweisbar ist, aber generell ist auch hier nicht möglich, zuverlässig zu überprüfen, ob der Link angezeigt werden sollte oder nicht.

Das ist insgesamt Overkill und nicht praktikabel.
Einiges ließe sich bspw. so lösen:

<script type="text/javascript">
if (parent.navigation)
 document.write('<p id="footer"><a href="inhalt.html" target="_top">Dieses Dokument einzeln und außerhalb des Framesets zeigen (beispielweise zum Drucken)</a></p>');
else
 document.write('<p id="footer"><a href="frameset.html?'+escape(location.pathname)+'" target="_top">Dieses Dokument im Frameset mit Navigation anzeigen</a></p>');
</script>

Deckt aber nur einige wenige Fälle ab, ohne JavaScript läuft auch nichts. Das Herumdoktern an Symptomen bringt hier wenig.

Aber mich stört doch mehr, wenn zunächst die Standardseite des Sets geladen wird und danach erst die eigentliche Seite.

Ja, daher mein Rat, diesen Part serverseitig zu lösen.

Die Abfrage von navigator.appName ist letztlich sinnfrei

Das sehe ich nun in diesem Fall aber nicht so. Wenn sich z.B. ein Opera als IE ausgibt, bekommt er die IE-Routine, mit der er auch etwas anfangen kann.

Ärgerlich, damit nützt deine präferierte Lösung faktisch noch weniger Besuchern.

Es geht mir hierbei lediglich darum, dem IE nicht die Alternativroutine vorzusetzen, da sie bei ihm nicht funktioniert.
Und den IE kann man damit doch zuverlässig erkennen, oder irre ich mich hier?

Falls du fragst, ob du sicher sein kannst, dass jeder MSIE auch diese Kennung sendet: Du bist nicht von Proxies gefeit, welche nachträglich Scripte einbinden, um diese Objekte zu überschreiben, sodass sie unbrauchbar werden. Zuverlässigkeit ist somit Definitionssache.

onerror = FremdURL ist insofern blöd, dass auch andere unkalkulierbare Fehler auftreten können und in diesen Fällen unpassend ist, die Funktion FremdURL auszuführen.

zugegeben... aber ich möchte mit meiner Routine ja auch fremde Framesets sprengen. Wenn hier Jemand eine Möglichkeit kennt, wie man die Anzeige im fremden Frameset zuverlässig ohne Fehler bei der Domainüberschreitung erkennen kann, wäre ich sehr froh.

Mir ist auch keine robuste Methode bekannt, außer auf Frames zu verzichten, sodass die standardmäßigen Abfragen à la top!=self funktionieren. Ich muss auch gestehen, dass ich es sowieso nicht für essentiell erachte, solche Scripte einzusetzen. Das Überprüfen der Referrer und das eventuelle Verschicken von freundlichen Hinweisen hilft in der Regel.

Grüße,
Mathias

[Steve]

Hy Mathias

ich hab was anderes versucht - aber das klappt so noch nicht. Kannste mir da nicht weiterhelfen?

<SCRIPT language="JavaScript">
<!--
{ if(!parent.home)
location.href="http://www.buerogummi.ch/?" + location.pathname;
 }
//-->
</SCRIPT>

wo liegen da die Fehler, dass die Unterseite
location.pathname
nicht aufgerufen wird? ( möchte anschliessend das js in eigene Datei auslagern, da über 400 Seiten mit dem Script versehen werden sollen und der Besucher auf keinenfall auf eine Unterseite bleiben soll ohne Frames)

Ich wäre so dankbar, damit ich die Seiten überarbeiten kann!

Lieben Gruss Steve

[Andreas Schneider]

Hallo Steve,

<SCRIPT language="JavaScript">

Das type-Attribut (type="text/javascript") fehlt.

{ if(!parent.home)
location.href="http://www.buerogummi.ch/?" + location.pathname;
}
wo liegen da die Fehler, dass die Unterseite
location.pathname
nicht aufgerufen wird?

location.pathname liefert den Pfad incl. führenden Slash ("/"). Wenn Du das erste Zeichen entfernst, sollte es gehen.

Grüße
Andreas

[Andreas Schneider]

Hallo nochmal,

Hallo nochmal,

location.href="http://www.buerogummi.ch/?" + location.pathname;

Das ? ist übrigens zuviel. Also hast Du jetzt die Wahl: Entferne das erste Zeichen aus location.pathname oder schreib's gleich so:
location.href="http://www.buerogummi.ch" + location.pathname;

Grüße
Andreas

[molily]

Hallo,

location.href="http://www.buerogummi.ch/?" + location.pathname;

Das ? ist übrigens zuviel.

Ja, aber der Slash nicht.

location.href="http://www.buerogummi.ch" + location.pathname;

location.href="http://www.buerogummi.ch/" + location.pathname;
                                       ^ Der war durchaus richtig.

Mathias

[Andreas Schneider]

Hallo Mathias,

location.href="http://www.buerogummi.ch/" + location.pathname;
                                       ^ Der war durchaus richtig.

Der String, den location.pathname zurückliefert beginnt mit einem Slash. Also muß entweder der weg, oder eben der hinter dem ".ch", sonst hast Du zwei davon hintereinander.

Grüße
Andreas

[molily]

Hallo,

Der String, den location.pathname zurückliefert beginnt mit einem Slash. Also muß entweder der weg, oder eben der hinter dem ".ch", sonst hast Du zwei davon hintereinander.

Stimmt. Ich habe es verwechselt.

Mathias

[Steve]

Ciao Andreas

hat nicht funktioniert!
So bekomme ich immerhin die Hauptseite, aber die Unterseite erscheint nicht im Frame!

<script type="text/javascript">
<!--
{ if(!parent.home)
location.href="http://www.buerogummi.ch?" + location.pathname;
 }
//-->
</SCRIPT>

Wenn ich das ? weglasse gehts nicht. Wo kann denn das Problem sonst liegen?

Dieses Script hatte ich noch in der index.html datei:
<SCRIPT language="JavaScript">
<!--
 function checkFramecall() {
  var Adressanhang=location.search;
  if(Adressanhang)
  frames.home.location.href=Adressanhang.substring(1,Adressanhang.length);
 }
//-->
</SCRIPT>

Hallo Mathias,

location.href="http://www.buerogummi.ch/" + location.pathname;
                                       ^ Der war durchaus richtig.

Der String, den location.pathname zurückliefert beginnt mit einem Slash. Also muß entweder der weg, oder eben der hinter dem ".ch", sonst hast Du zwei davon hintereinander.

Grüße
Andreas

[Andreas Schneider]

Hallo Steve,

location.href="http://www.buerogummi.ch?" + location.pathname;
Wenn ich das ? weglasse gehts nicht. Wo kann denn das Problem sonst liegen?

Mit dem ? hängst Du Parameter an, landest also logischerweise auf der Hauptseite.
Bau doch mal alerts ein, und lass Dir location.pathname bzw. den zusammengebauten String anzeigen, vielleicht sieht man ja dann, woran es liegt.

Dieses Script hatte ich noch in der index.html datei:
<SCRIPT language="JavaScript">
<!--
function checkFramecall() {
  var Adressanhang=location.search;
  if(Adressanhang)
  frames.home.location.href=Adressanhang.substring(1,Adressanhang.length);
}
//-->
</SCRIPT>

Wo wird dieses Script aufgerufen?

Grüße
Andreas

[Michael Schröpl]

Hi Steve,

location.href="http://www.buerogummi.ch?" + location.pathname;

vorher war das Fragezeichen (als Bestandteil des URL-localpart) nur 'zuviel' - jetzt (als Bestandteil des Domain-Namens) ist es 'ganz falsch'. Also: Weg damit.

Viele Grüße
      Michael

[Ingo]

Hallo Mathias,

ein zusätzlicher breadcrumb trail zur Orientierung

wie ich schon sagte: ich finde die idee so langsam auch sinnvoll und wenn man das recht unscheinbar aber einheitlich am seitenande platziert, spicht eigentlich (bis auf die arbeit;-) nichts dagegen.

Im Idealfall müsste eine Kaskade von Links angeboten werden, um die gängigen Probleme von Frames umgehen zu können:

...
Wobei ich anstelle Deiner lösung lieber entsprechend vorbereitete texte am seitenanfang per Javascipt sichtbar machen würde.

Deckt aber nur einige wenige Fälle ab, ohne JavaScript läuft auch nichts. Das Herumdoktern an Symptomen bringt hier wenig.

deshalb verzichte ich bei neuen seiten ja schon drauf und realisiere bei bedarf die gewünschten effekte über css.

gruß
Ingo