Oliver Bildesheim: history.back() bei Frames

Hallo zusammen,

folgende Situation: Ich habe zwei Frames A und B. In Frame A wird über einen Link eine neue Seite geladen. Anschliessend erfolgt das auch in Frame B. In Frame A wird nun z.B. über einen Link history.back() oder history.go(-1) aufgerufen. Das hat zur Folge, dass (zumindest im IE - NS noch nicht probiert) im Frame B die vorherige Seite geladen wird. Das ist aber gar nicht in meinem Sinne. Ich möchte in Frame A zurück gehen (wo auch history.back() aufgerufen wird).

Das müsste eigentlich funktionieren - tut es aber nicht (siehe oben). Auch wenn ich explizit über parent.frameName oder parent.frames[frameIndex] gehe, um auch ganz sicher das History-Objekt des gewünschten Frames A anzusprechen, wird die Back-Funktionalität in Frame B verwendet.

Das lässt mich vermuten, dass es unter IE keine frame-lokale, sondern nur eine globale History gibt.

Kennt jemand das Problem - oder besser: hat jemand eine Lösung?

Es gibt ein Beispiel in selfhtml oder einen Artikel, der einen Back-Link auf zwei Frames anwendet. Der Back-Link steht dabei in einem dritten Frame. Das Beispiel scheint aber nur zu funktionieren, weil die Ladereihenfolge entsprechend ist u. auch im Falle einer globalen History kein Problem auftreten kann.

Bin dankbar für jeden Tipp.

Viele Grüsse,
Oliver Bildesheim

  1. Kennt jemand das Problem - oder besser: hat jemand eine Lösung?

    Ja, auf Frames verzichten.

    Struppi.

    1. Hallo Struppi,

      Hm - hatte eigentlich auf konstruktive Antworten gehofft.

      Es gibt nun einmal Situationen, in denen NICHT auf Frames verzichtet werden kann. Die Diskussionstriaden diesbezüglich sollte man seit einigen Jahren eigentlich hinter sich haben.

      Beste Grüsse,
      Oliver

      Kennt jemand das Problem - oder besser: hat jemand eine Lösung?

      Ja, auf Frames verzichten.

      Struppi.

      1. Hallo Oliver!

        Zu deiner Frage: Ja, der IE verwaltet eine "globale history" für alle Frames.
        Um dein Problem zu lösen, bedarf es einigen Aufwands.
        Ansatz:
        Du erzeugst dir deine eigene Historyverwaltung und zwar so:
        Auf einem Frame (evtl Hidden, auf jeden Fall immer vorhanden), nennen wir ihn Navigate, führst du die Verwaltung mit den Funktionen
        1. saveHistoryPos(Framenr, Pos)
        2. getBackHistoryPos(Framenr)
        und einem zweidimensionalen dynamischen Array, in dem bei Aufruf von (1) ein entsprechender eintrag vorgenommen wird.

        Jede deiner Frames führt folgenden Eintrag: <body onload="saveHistoryPos(<Framenr, const>, history.length)" >

        Somit merkst du dir, an welcher position die Seite in der History steht.

        Um nun zurück zu kommen, benötigst du ein history.go(-(Historyposition der akt. Seite(a) - Historypos der backSeite(b)))

        (b) lassen wir uns von der Funktion (2) für den entsprechenden Farme aus dem Array zurückgeben.
        (a) ist wie bereits bekannt history.length, da jede Seite immer nach dem Laden hinten in die History eingehängt wird.

        Viel Glück,
        Richard

        1. Hallo Richard,

          hatte schon befürchtet, dass es auf einen eigenen Mechanismus zur Protokollierung des Page Flows hinausläuft :-(

          Aber das ermöglicht mir dann auch einige Dinge über die History-Funktionalität hinaus. Dein Vorschlag ist mir also sehr willkommen :-)

          Vielen Dank und beste Grüsse,
          Oliver

          1. Hallo Oliver,

            hatte schon befürchtet, dass es auf einen eigenen Mechanismus zur Protokollierung des Page Flows hinausläuft :-(

            Das funktioniert aber nur solange der "Zurück"-Link auf deiner Seite verwendet wird. Mit dem Browser "Zurück"-Button werden die gleichen Probleme auftreten. Ich vermute, dass du so etwas wie die "ZweiFrames()" Funktion verwendest, ist das richtig?
            Du solltest zusätzlich die Archivsuche bemühen http://selfsuche.teamone.de/cgi-bin/such.pl, oder einen Blick auf http://www.maxx4u.de/drweb/frames werfen.

            Viel Spaß,

            Jochen

            1. Hallo Oliver, Jochen!
              Dass ein anderer als der seiteneigene HistoryButton verwendet wird, kann verhindert werden, indem die Framemainpage bereits in ein eigenes Window, das vorher mittels JS geöffnet wurde, geladen wird.
              (Bei eigenem Fenster kann man nämlich die Anzeige der Navigation verhindern...)
              MFG,
              Richard
              (Und an die Puristen: ja, jetzt ist alles da: Frames, Popupfenster und mit deaktiviertem JS geht nichts mehr...)

              1. (Und an die Puristen: ja, jetzt ist alles da: Frames, Popupfenster und mit deaktiviertem JS geht nichts mehr...)

                Was hat purismus damit zu tun, dass eine Seite funktioniert?

                Es geht ja nicht darum eine Intranetseite mit genau definierter Umgebung zu erstellen, sondern eine Internetseite die dank html/css die Möglichkeit bietet auf allen erdenklichen Anzeigemedien Inhalte zu vermitteln.

                Struppi.

                1. Hallo Struppi,

                  Es geht ja nicht darum eine Intranetseite mit genau definierter Umgebung zu erstellen

                  In meinem Fall stimmt das nicht. Es geht zwar nicht um eine Intranetseite. Aber es geht auch nicht um eine "normal öffentliche" Webpräsenz, sondern um ein Online Tool mit "geschlossener Benutzergruppe". Und wenn es die fachlichen Anforderungen erfordern, wird eben die Menge der zugelassenen Browser reduziert und wenn es sein muss noch weitere Systemvoraussetzungen definiert.

                  Von daher können prinzipiell alle - auch nicht cross-browser-fähigen - Features genutzt werden. Es geht um eine Arbeitsumgebung mit einer Menge Funktionalität auf einer Art Desktop. Das erfordert um handlich zu sein ganz einfach Frames (schliesslich gibt es x gleichzeitige Formulare / Infopages, die gleichzeitig und vor allem nebeneinander angezeigt, teilweise regelmässig automatisch refreshed etc. werden. So etwas kennt man ja z.B. von Webchats. Da ist halt nix mit "no frames", "no javascript" et al. Da stehen konkrete Use Cases in genau definierter Umgebung im Vordergrund. Schliesslich kann man nicht in einem Fenster / Frame gleichzeitig regelmässig die Anzeige neu laden und ein Eingabeformular bereitstellen.

                  Beste Grüsse,
                  Oliver

                  1. In meinem Fall stimmt das nicht. Es geht zwar nicht um eine Intranetseite. Aber es geht auch nicht um eine "normal öffentliche" Webpräsenz, sondern um ein Online Tool mit "geschlossener Benutzergruppe". Und wenn es die fachlichen Anforderungen erfordern, wird eben die Menge der zugelassenen Browser reduziert und wenn es sein muss noch weitere Systemvoraussetzungen definiert.

                    Naja, ich hab ja auch nirgendwo gesagt dass man das nicht machen kamn oder soll. Ich hab lediglich einen Vorschlag gemacht und den kleinen Seitenhieb (mit den Puristen) halt auf meine Lösung bezogen - ich kann damit leben ;-)

                    Mich nervt nur immer dieses S/W denken, nur weil der einfachere praktikablere Weg nicht immer der gewünschte ist, hat das nichts mit ablehnung der Technik zu tun. Es ist ja nicht so dass man von einer einfachen Frage direkt auf die Anforderungen und Kenntnisse des Fragenden schliessen kann. Insofern ist ein Tipp wie man ein Problem umgehen kann, in meinen Augen sinnvoll.

                    Und gerade die verwendung von JS ist in Anbetracht der monatlichen Meldungen über Sicherheitslöcher und das M$ darauf hingewiesen wurde, doch ihre Standardeinstellungen restriktiver zu machen, nicht unbedingt sinnvoll sollen die Seiten langfristig für einen grossen Besucherkreis nutzbar bleiben. Evtentuell sind nächstes Jahr alle neu installierten IE's ohne ActiveScripting unterwegs, wer weiß das heute schon.

                    Struppi.

                2. Hallo Struppi!

                  Was hat purismus damit zu tun, dass eine Seite funktioniert?

                  Ich bin nicht gegen eine allgemeine Lesbarkeit von Internet Seiten, da ja (Gottseidank) nicht nur ein Browser existiert.
                  Aber: Ich finde es nicht so schön, wie es hier im Forum immer wieder zu lesen ist, das Leute, die ungewöhnliche Probleme zu lösen haben und dabei auf unkonventionelle Techniken zurückgreifen (müssen) immer mit dem Kommentar abgespeist werden: "Dann mach es nicht so!"
                  Man kann nämlich auch helfen und dabei dann auf die Nachteile dieser Technik hinweisen.

                  Grüsse,
                  Richard

        2. Hallo Richard,

          es könnte noch ein Problem auftreten - werde ich austesten:

          Wenn ich für die Back-Funktionalität history.go(- ...) verwende, dann werden evtl. auch die anderen Frames (im Beispiel der Frame B) zurückgesetzt. Oder "überspringt" das go(-x) die späteren Einträge?

          Beste Grüsse,
          Oliver

          1. Hallo Oliver!
            History.go(x) wirkt sich nur auf den Frame aus, von dem es aufgerufen wird.
            Die anderen Frames bleiben stehen (war zumindest bei mir im IE6 so).
            Allerdings: Wenn du eine Position in der History anspringst, der nicht in diesem Frame dargestellt wurde, so führt dies zu "unberechenbaren" Ergebnissen.
            Wichtig auch:

            CGI erzeugt neuen History Eintrag
            innerHTML erzeugt keinen neuen Eintrag

            Interessant könnte für dich in diesem Zusammenhang auch die Befehle document.location.href und document.location.replace sein.
            Die beiden sind u.U. hilfreich ;)

            Viel Glück,
            Richard

      2. Hm - hatte eigentlich auf konstruktive Antworten gehofft.

        Es gibt nun einmal Situationen, in denen NICHT auf Frames verzichtet werden kann. Die Diskussionstriaden diesbezüglich sollte man seit einigen Jahren eigentlich hinter sich haben.

        Ich hatte nicht vor eine Diskussion anzuzetteln, dann hätte ich versucht Argumente zu bringen.
        Ich hab dir eine lediglich eine konstruktive Lösung angeboten. Wenn dir der umständlichere Weg besser erscheint ist das ja in Ordnung.

        Struppi.