[js] history.back laat inhoud van de dir zien

[Verwijderd]

Ik heb een pagina met een framestructuur die o.a. een navigatiebalk heeft met een terug en vooruit knop (history.back en history.forward).
Daar deed zich een klein probleem mee voor: als er in de 'content' frame een pagina werd geopend via een link (binnen het frame) en die pagina zette heel eigenwijs z'n eigen window.name, dan werkte m'n navigatie knoppen niet meer (omdat de target name niet meer bestond.
Dat heb ik toen op de volgende manier opgelost:

code:

function terug()
{
    top.frames[3].location.href = history.back();
}

en m'n link zo gemaakt:

code:

<a href="#" onClick="terug();">back</a>

Het gekke is alleen, dat history.back en history.forward er nu voor zorgen dat na de eerste of laatste pagina, de inhoud van de directory getoond wordt (er staat geen index.html ofzo in). En dat komt door m'n functie want als ik gewoon <a href="javascript:jistory.back();">back</a> doe, dan stopt ie netjes bij de eerste of laatste pagina.

Dus stel ik open een nieuwe browser (met about:blank), ik ga naar die pagina toe, ik klik naar pagina 2, ik klik vervolgens op m'n backbutton (sta nu weer op de eerste pagina) en daarna nog eens op m'n backbutton, dan krijg ik de inhoud van die directory te zien. Zelfde geldt voor de vooruit knop.

Waar ligt dit aan?

[Hangloozz]

ik denk dat die hash in je href de zaak opfokt.
Probeer het eens zo:
[code]
<a href="javascript:terug();">back</a>
[/code]
edit: kontverhaal...ben nog niet wakker

dit blijft wel van toepassing:
en ik zou zowiezo ff een index.html in je map zetten om directorybrowsing te voorkomen.

[Verwijderd]

history.back() is een functie die geen url teruggeeft.
<a href="#" onClick="history.back();return false;">back</a>

of

function terug()
{
history.back();
}

met:

<a href="#" onClick="terug();return false;">back</a>

[Annie]

Je terug() functie klopt niet helemaal (of helemaal niet? )

deze

code:

function terug()
{
    top.frames[3].history.back();
}

gebruiken kan al een heleboel schelen.

[Verwijderd]

history.back werkt ongeacht het actieve frame. Het is ook geen onderdeel van het frame object of location object, maar van het window object.

[Verwijderd]

aaahhhhh ok.
wat annie zei werkt inderdaad prima!

[Bosmonster]

gebruik trouwens bij voorkeur history.go(-1) ipv history.back()

wat compatibeler

[Annie]

Verwijderd schreef op 17 oktober 2002 @ 13:50:
history.back werkt ongeacht het actieve frame. Het is ook geen onderdeel van het frame object of location object, maar van het window object.

Je hebt imho gedeeltelijk gelijk. Een frame is een window object en heeft dan ook, afaik, gewoon een history property.
Correct me if I'm wrong.

Echt veel nut heeft de frame verwijzing in dit geval overigens niet aangezien ze allemaal naar hetzelfde history object verwijzen.

[Verwijderd]

Bosmonster schreef op 17 oktober 2002 @ 14:29:
gebruik trouwens bij voorkeur history.go(-1) ipv history.back()

wat compatibeler

Hoe bedoel je compatibeler?
Ik vind 'm juist minder compatibel, in die zin dat ie niet compatibel is met de back-button in je browser en history.back(); wel

[Bosmonster]

Verwijderd schreef op 19 oktober 2002 @ 19:03:
[...]
Hoe bedoel je compatibeler?
Ik vind 'm juist minder compatibel, in die zin dat ie niet compatibel is met de back-button in je browser en history.back(); wel

compatible met back-button?

Ik bedoelde browser compatible. history.go(x) werkt overal in, history.back() niet in een aantal browsers (IE4? Mac IE's?).

[Verwijderd]

Een frame is een window object en heeft dan ook, afaik, gewoon een history property.

het is window.history en niet frame.history. Check de DOM. En idd van history is maar een enkel object, geen property.

AFAIK history.go en history.back zijn allemaal Dom functies ondersteund op alle platformen en browsers (vanaf versie 4 voor NS en IE).

[Annie]

Verwijderd schreef op 20 oktober 2002 @ 14:21:
[...]

het is window.history en niet frame.history. Check de DOM. En idd van history is maar een enkel object, geen property.

Window.history is dan toch een property welke een reference is naar het history object? Of ben ik nu helemaal gek geworden (graag alleen een antwoord op de eerste vraag ).

En als ik de DOM goed begrijp kan je van een frame het window object aanspreken. En daarop voortredenerend dus ook de history property.

Maar zoals ik al eerder zei bestrijd ik niet dat het history object via een window object aangesproken wordt en dat er 1 history object is waarmee je de history van de browser kan aanspreken. Je hebt me echter niet overtuigd dat bovenstaande redenering niet correct is.

[Bosmonster]

Verwijderd schreef op 20 oktober 2002 @ 14:21:
[...]

het is window.history en niet frame.history. Check de DOM. En idd van history is maar een enkel object, geen property.

AFAIK history.go en history.back zijn allemaal Dom functies ondersteund op alle platformen en browsers (vanaf versie 4 voor NS en IE).

Goed man.. heb je dat ook ff getest? Op IE4 en op de Mac? Want misschien ben ik gewoon blind

[Verwijderd]

IE4 op de Mac ook geloof ik... maar weet dat niet voor de volle 100% zeker.

[Verwijderd]

Ik loop toch nog tegen een probleem aan.
Als ik deze code gebruik:

code:

function terug()
{
    top.frames[3].history.back();
}

Dan werkt dat gek genoeg alleen voor pagina's die lokaal (onder hetzelfde domeinnaam) staan. Als ik een pagina open binnen dat frame - stel gathering.tweakers.net - dan werkt de backbutton toch niet meer. Ik krijg dan deze foutmelding:

Fout: Toegang geweigerd

En dat is op die regel waar top.frames[3].history.back(); staat.
Het kan niet aan de broncode van die pagina(s) liggen, want als ik die in z'n geheel copy en paste in een nieuw bestand, die op de server neerzet en 'm op die manier open, dan gaat het prima.
Heb geen idee waar ik de oplossing moet zoeken...

[Hangloozz]

je kunt met javascript geen pagina's/code besturen die buiten je domein valt, in het kader van beveiliging.
Een workaround kun je zoeken in het hard plaatsen van een link voor de terugbutton en anders met includes gaan werken maar da's ook niet alles.

[Verwijderd]

Hangloozz schreef op 24 oktober 2002 @ 08:14:
je kunt met javascript geen pagina's/code besturen die buiten je domein valt, in het kader van beveiliging.

Dat snap ik niet helemaal. De pagina valt toch binnen _mijn_ framestructuur?

Een workaround kun je zoeken in het hard plaatsen van een link voor de terugbutton en anders met includes gaan werken maar da's ook niet alles.

includes kan gewoon niet. dan wordt het onmogelijk een pagina binnen je eigen pagina te openen.

ik snap niet helemaal wat je met hard plaatsen van een link voor de terugbutton bedoelt. Als je daarmee bedoelt: <a href="javascript:history.back();"> Dat werkt dus niet. Hij moet namelijk op een ander frame van toepassing zijn.
Je kan dan wel <a href="javascript:history.back();" target="framename"> doen, maar zoals ik in m'n eerste bericht al aangaf krijg je problemen op het moment dat er een pagina binnen dat frame wordt geopend wat z'n eigen window.name zet. Want dan verwijst die target nergens meer naar.

Weet iemand misschien een oplossing voor dit probleem?

[Verwijderd]

linux-newbie, op het moment dat je iets in een frame opent in een ander domein, dan kun je bijna niets met dat document, dat is gewoon zo.

Annie, alert(typeof window.history) retourneert 'object' als waarde.

[Hangloozz]

Verwijderd schreef op 24 oktober 2002 @ 23:47:
[...]
Dat snap ik niet helemaal. De pagina valt toch binnen _mijn_ framestructuur?

klopt... maar de pagina is niet van jou!
stel:
jij hebt www.mijndomein.nl.
Je zet in een frameset een pagina neer die van www.anderdomein.nl komt.
Op het moment dat je dan een javascript handeling uitvoert die betrekking heeft op het andere domein dan krijg je een foutmelding.
Sinds Netscape versie 3 ofzo is het niet meer toegestaan om javascript cross-domein te gebruiken.

includes kan gewoon niet. dan wordt het onmogelijk een pagina binnen je eigen pagina te openen.

eh
je kunt via bijv. PHP een script maken dat elke pagina van dat andere domein via een include() functie binnenhaald (dat gebeurt dus al op de server!!) en dan doorstuurt naar de client.
Op dat moment denkt de client-side javascripting dat het van hetzelfde domein komt. Mean huh

ik snap niet helemaal wat je met hard plaatsen van een link voor de terugbutton bedoelt. Als je daarmee bedoelt: <a href="javascript:history.back();"> Dat werkt dus niet. Hij moet namelijk op een ander frame van toepassing zijn.
Je kan dan wel <a href="javascript:history.back();" target="framename"> doen, maar zoals ik in m'n eerste bericht al aangaf krijg je problemen op het moment dat er een pagina binnen dat frame wordt geopend wat z'n eigen window.name zet. Want dan verwijst die target nergens meer naar.

Weet iemand misschien een oplossing voor dit probleem?

met hard plaatsen bedoelde ik dit:

HTML:

<a href="http://www.anderdomein.nl/fetchpagina.html" target="bestemmingsframe">terug naar vorige pagina</a>

je stampt dus hard het pad in van het bestand waar de bezoeker vandaan komt.

Verdere workarounds zou ik ff niet weten

[Annie]

Verwijderd schreef op 25 oktober 2002 @ 00:19:
Annie, alert(typeof window.history) retourneert 'object' als waarde.

Ja, en alert(typeof window.location.href) geeft string terug. Is href dan geen property?

[ Voor 0% gewijzigd door Annie op 25-10-2002 00:42 . Reden: deze vraag is natuurlijk retorisch bedoeld ]

[Verwijderd]

Hangloozz schreef op 25 oktober 2002 @ 00:39:
eh
je kunt via bijv. PHP een script maken dat elke pagina van dat andere domein via een include() functie binnenhaald (dat gebeurt dus al op de server!!) en dan doorstuurt naar de client.
Op dat moment denkt de client-side javascripting dat het van hetzelfde domein komt. Mean huh

Wordt dat niet een beetje onmogelijke opgave?
Want als ik een index.php maak met daarin
<?php
include "http://www.site.nl";
?>
Gaat dat al niet werken. Dan moet ik eerst de output van die pagina naar een string wegschrijven en alle relatieve verwijzingen (plaatjes, etc) dmv regex absoluut maken, want daarvan denkt ie dan ook dat ze op mijn server staan. En ik moet ook nog eens alle linken gaan vervangen, zodat ze naar index.php blijven verwijzen maar dan met een ?page=whatever. Maar wat als ze van onclick gebruik maken. Of een drop downmenu met een onChange event die er voor zorgt dat er een nieuwe pagina geladen wordt, etc. etc.
Dat gaat dus nooit lukken volgens mij

met hard plaatsen bedoelde ik dit:

HTML:

<a href="http://www.anderdomein.nl/fetchpagina.html" target="bestemmingsframe">terug naar vorige pagina</a>

je stampt dus hard het pad in van het bestand waar de bezoeker vandaan komt.

Verdere workarounds zou ik ff niet weten

Da's dan jammer, want daar heb ik ook nix aan

Ze moeten namelijk binnen die pagina kunnen navigeren en de backbutton op de site (zoals ik 'm dus gemaakt heb) moet precies hetzelfde blijven doen als de browser button. Ze moeten dus niet weer in 1 klap terugkomen bij mijn pagina als ze binnen die andere site al meerdere keren geklikt hebben.

Nouja...in iedergeval erg bedankt voor het meedenken. Ik hoop dat iemand anders nog een oplossing kan bedenken

[Annie]

Verwijderd schreef op 25 oktober 2002 @ 00:55 o.a.:
en alle relatieve verwijzingen (plaatjes, etc) dmv regex absoluut maken, want daarvan denkt ie dan ook dat ze op mijn server staan.

Dit kan je waarschijnlijk nog wel oplossen met een <base href>, maar andere genoemde zaken maken het dan misschien weer ingewikkelder.

Zomaar een brainstorm (disclaimer: het is nacht dus helder denken wordt steeds moeilijker ):
Kan je geen extra hidden frame toevoegen waar je bij het openen van een pagina de location van wijzigt met daarin de gewenste info?
Dus domein A opent frameset met pagina uit A (met back-knop) en pagina uit domein B en natuurlijk de hidden frame. Pagina B opent in hidden frame bij doornavigeren een pagina uit domein A met in de querystring de url die in de history moet komen (bijv. tracker.html?hist=vorigeBpagina.html). En tracker.html voegt de meegegeven url toe aan een self-made history.