Oppdage hash-forandring ved frem/tilbake-klikking

[Twinflower]

Jeg holder på med en side som er delvis ajax-basert.

Problemet jeg har støtt innpå nå, er at om jeg skal gå *tilbake* fra side.com/index.html#side2 til side.com/index.html#side1, så klarer ikke javascript å oppdage at url'en har skiftet. Da blir heller ikke innholdet forandret til side1-innhold.

 

 

Her er problemet i praksis:

http://foniks.bluescape.org/site/kurs

 

Kurs-siden består av noen sider dere kan klikke dere frem og tilbake på, men man kan altså ikke bruke frem/tilbake-knapper.

 

 

Eneste jeg kan tenke meg som kan løse dette er en timerfunksjon, som sjekker url'en hvert 100 ms eller noe, og reagerer om den skifter.

Men som den elektrikeren jeg er, så vet jeg ikke helt hvordan jeg skal få det til i praksis.

 

 

Andre løsninger som ikke baserer seg på timere, er også å foretrekke.

[luxus]

Tror kanskje dette kan hjelpe deg: http://code.google.com/p/reallysimplehistory/.

 

Når det er sagt er jeg usikker på om det er verdt bryet på en slik side der det fungerer vel så bra å bare gjøre vanlige GET kall. Men, du må så klart gjøre som du vil (Om jeg ikke så feil så det ut til at du gjorde POST-kall til server under AJAX-kallet ditt, noe som egentlig burde vært GET i denne sammenhengen).

Endret 26. januar 2009 av luxus

[cbastus]

Hva med en onchange trigger på window.location.hash?

Da kan du kalle funksjonene på nytt med hash verdiene som parameter.

[Twinflower]

Tror kanskje dette kan hjelpe deg: http://code.google.com/p/reallysimplehistory/.

 

Når det er sagt er jeg usikker på om det er verdt bryet på en slik side der det fungerer vel så bra å bare gjøre vanlige GET kall. Men, du må så klart gjøre som du vil (Om jeg ikke så feil så det ut til at du gjorde POST-kall til server under AJAX-kallet ditt, noe som egentlig burde vært GET i denne sammenhengen).

 

 

Takk for godt svar, jeg skal se på det siden.

Det er egentlig ikke så veldig viktig, men om jeg kan lære noe og slipper å bruke 2-3 dager på å forstå det, så blir det vel til at jeg prøver meg

 

Grunnen til at jeg bruker POST istedenfor GET til ajax er at jeg fikk streng beskjed om det på en eller annen #php-irckanal. Det var i løpet av min første time med ajax, så jeg klarer ikke å huske grunnen. Tror det har noe med sikkerhet å gjøre.

 

Hvorfor vil du bruke GET i så fall?

 

Hva med en onchange trigger på window.location.hash?

Da kan du kalle funksjonene på nytt med hash verdiene som parameter.

 

Hvis det er mulig, virker det som en veldig fornuftig løsning

[luxus]

Grunnen til at jeg bruker POST istedenfor GET til ajax er at jeg fikk streng beskjed om det på en eller annen #php-irckanal. Det var i løpet av min første time med ajax, så jeg klarer ikke å huske grunnen. Tror det har noe med sikkerhet å gjøre.

 

Hvorfor vil du bruke GET i så fall?

 

Jeg ville ha brukt GET her rett og slett fordi man med et POST kall implisitt sier til web-serveren at her kommer det noe som endrer en tilstand til resurser på webserveren. F.eks. når man skriver inn et svar i denne tråden gjør man et POST kall til server, men når du henter tråden for å lese gjøres et GET kall. Et GET kall bør, selv om det er mulig, ikke endre tilstand til resurser på serveren. I så tilfelle kan vi begynne å snakke om dårlig sikkerhet. I ditt tilfelle henter du kun innhold, ergo bør GET kall brukes

 

(Tviler sterkt på at window.location.hash fyrer av change event på lik linje i alle browsere - hvorfor i all verden skulle noen tatt seg bryet med å skrive "reallysimplehistory" dersom det var så enkelt? :-p)

Endret 30. januar 2009 av luxus

[Twinflower]

hehe, I *get* it

 

POST for å lagre,

GET for å hente.

 

Men blir serveren fornærmet om jeg bruker post til alt?

[saivert]

Tror ikke dere helt har forstått problemstillingen.

Når du trykker tilbakeknappen i nettleser så går den til en url med en annen anchor uten at sideinnholdet oppdateres.

F.eks går den fra #kursets-gang til #noe-for-meg, men siden viser fortsatt innholdet som om det var #kursets-gang som ble vist fremdeles.

Her trenger vi noe JavaScript kode som trigges når nettleser endrer URL i location bar.

Jeg sjekket litt rundt på nettet og fant ut at det å oppdage når brukern trykker tilbakeknappen i nettlesern sin ikke er mulig på noe god måte. Så en timer vil være å foretrekke. En timer er ikke så ille heller. Mange nettsider bruker timers til forskjellige ting i dag.

 

function sjekk_side() {
 // gjør noe med window.location.hash her
}

function onloadhandler() {
 setTimeout('sjekk_side()', 500);
}

document.onload = onloadhandler;

 

Når det kommer til GET vs POST så er den eneste forskjellen her at ved et GET kall så sendes data i Requestlinja og ved POST-kall så sendes det i meldingshodet (message body).

 

GET-kall:

GET /serverressurs?attr1=val&attr2=val HTTP/1.1

 

POST-kall:

GET /serverressurs HTTP/1.1
Content-length: 19

attr1=val&attr2=val