Newsgroup: it.comp.lang.javascript
Titolo: Settare una session var PHP da JS

Devo modificare una variabile di sessione PHP alla modifica di un campo 
sulla mia form.
Con
location.href=Scrip_Che_Modifica_SessionVar.php?Var=NomeVar&Valore=123456
Tutto OK ma la pagina attuale sparisce.
Allora ho aggiunto un frame invisibile "frame1" e faccio:
frame1.location.href= <come sopra>
Tutto OK ma ora ho il problema di capire se la modifica e' andata a buon 
fine. Allo scopo, nello script PHP (oltre a settare la sessionVar) 
restituisco una paginetta con una variabile settata a OK o a ERR.
Tutto OK ma ora devo sincronizzare i frame, cioe' fare aspettare che la 
pagina sia caricata sul frame1, per potere leggere la variabile.
A questo punto, lurkando in lungo e in largo, ho iniziato a mettere dei 
timer, dei cicli, delle var di appoggio, dei flag e orpelli vari che 
alla fine FUNZIONA!!! ma non so nemmeno io come.
Ora io mi (e vi) chiedo:
Esiste un sistema piu' semplice per settare una var. PHP e avere dal 
server un "OK" o un "Err" il tutto senza alterare il normale svolgimento 
della pagina HTML che richiama questa modifica ?
Qualcosa tipo:
onchange="(SendServer("NomeVar=123456")) ? alert(OK) : alert(Err)"
(Meglio se senza usare i cookie)
Grazie
Marco

 della pagina HTML che richiama questa modifica ?
Si. Vi e' il metodo "pulito" ed il "trick".
Il metodo "pulito" funziona solo su IE>=5.x e sui browser Gecko based
(mozilla,netscape,firefox) da una certa versione in poi.
Consiste nel fare un XmlHttpRequest ad una pagina server, inviando le
informazioni che poi questa pagina prendera' in input, elaborera', e del
quale restituira' poi un output.
Il vantaggio non indifferente e' che queste chiamate possono essere
sincrone. Il che significa che fintanto che non ottieni una risposta dal
server, il codice javascript resta in attesa e quindi puoi porre le
istruzioni in sequenza:
chiamata();
visualizzavariabile();
Il trick funziona bene o male su tutti i browser recenti e meno recenti, e
si tratta essenzialmente di usare un immagine.
Molti "counter" su web usano come src una pagina server per generare
l'immagine che serve.. ebbene, il concetto e' piu' o meno il medesimo.
A differenza del metodo "pulito", pero', non e' un approccio sincrono,
quindi devi basarti su eventi.. inoltre poi al massimo considerare due tipi
di risposta.. ok/errore (nel tuo caso va bene), mentre con XmlHttpRequest
puoi avere un output molto piu' articolato.
Uno stralcio di codice:
var imgreq=new Image();
imgreq.onload=function(){alert("script eseguito correttamente");};
imgreq.onerror=function(){alert("esecuzione script fallita");};
e poi quando vuoi eseguire lo script, ti bastera':
imgreq.src="settassesione.php?nome=nomevar&value=valore&timestamp="+(new
Date()).getTime();
Lato server dovrai ricordarti di restituire in output un immagine in caso
la funzione abbia successo (1x1 gif, ad esempio) e niente in caso
contrario.. in questo modo riesci a gestire la risposta tramite gli eventi.
Ripeto, considera che tale codice e' event-driven, e *non*e'* a esecuzione
sincrona.
-- 
ZER0://coder.gfxer.web-designer/
~ "Lo dice il buon senso, ma il buon senso non e' uno standard".
(Jeffrey Zeldman)
on air ~ "Unknown Artist - Track 20"

 quale restituira' poi un output.
mmhh... usare SOAP per passare dati a javascript ti pare esagerato?
-- 
<artemis:alpeia xmlns:artemis="
http://utenti.lycos.it/artemis
" />

 visualizzavariabile();
MITTTTTTTTTIIIIIIIICCCCOOOOOOOOOOO!!!!!!!
Mi lancio nello studio di XmlHttpRequest.
Mannaggia al pomeriggio intero perso per syncronizzare i frame.
Grazie 100000000000
Marco

 Grazie 100000000000
De nada.
-- 
ZER0://coder.gfxer.web-designer/
~ Il computer e' una macchina progettata per velocizzare e automatizzare
gli errori.
on air ~ "Strong and strike"

 mmhh... usare SOAP per passare dati a javascript ti pare esagerato?
SOAP? Ma stiamo scherzando? Preferisco di gran lunga REST per questo genere
di cose.
-- 
ZER0://coder.gfxer.web-designer/
~ Plagiarism is copying from one source;
research is copying from two or more
(Wilson Mizner)


imgreq.onerror=function(){alert("esecuzione script fallita");};
[...]
L'evento onload dovrebbe funzionare anche con l'elemento iframe,
almeno per quanto riguarda IE 6.0 e Mozilla 1.7 :-)
'bye

 almeno per quanto riguarda IE 6.0 e Mozilla 1.7 :-)
BTW, se si parte da queste premesse, e' consigliabile l'uso di
XmlHttpRequest. :)
-- 
ZER0://coder.gfxer.web-designer/
~ Un computer e' fondamentalmente stupido.
Non fa cio' che vuoi che faccia, ma cio' che gli dici di fare.
Solo, e' uno stupido dannatamente veloce.

Mhm, ma questo che c'entra?
Ux inizialmente voleva usare un frame/iframe.
'bye

 Ux inizialmente voleva usare un frame/iframe.
No, Ux inizialmente *ha*usato* i frame; voleva solo sapere se esisteva un
metodo piu' semplice per ottenere lo stesso risultato, in conformita' alle
sue esigenze.
-- 
ZER0://coder.gfxer.web-designer/
~ Una mente perversa e' un peccato sprecarla.
(A dirty mind is a terrible thing to waste)
on air ~ "Sexiness"

 
http://www.mozilla.org/xmlextras/
A parte che lo uso solo in intranet, mi sono perň chiesto: se installi
mozilla standard installa anche questi extras, oppure occorre averlo
installato a parte per funzionare?
Credo sia installato di default, leggendo la pagina, chiedo conferma (se
sono sicurissimo che sia installato il tutti i browser Gecko quasi quasi ci
faccio un pensierino anche per internet...che ne pensi? )
-- 
"Emancipate yourselves from mental slavery;
None but ourselves can free our minds"
									    B.M.
--

 quasi quasi ci faccio un pensierino anche per internet...che ne pensi? )
Dipende dal contesto del sito in questione.
-- 
ZER0://coder.gfxer.web-designer/
~ Una mente perversa e' un peccato sprecarla.
(A dirty mind is a terrible thing to waste)
on air ~ "Nine Tail Demon Fox"

 Dipende dal contesto del sito in questione.
Sito di e-commerce; il sito attuale è un sito che funziona solo con IE.
Rifacendolo, ovviamente, lo renderei compatibile Gecko; pensavo IE>=5 e
Gecko-based (escludo netscape4 e, penso ma devo ragionarci, IE4).
Non so, ero convinto di NON usare xmlhttp ma quasi quasi ci sto
ripensando...
-- 
"E' l' ignoranza che crea l'intolleranza
 di gente cieca e senza coscienza"
									  S.S.S.
--

 ripensando...
Se vuoi andare sul sicuro, potresti sempre usarlo come valore aggiunto. 
Ovvero, rendere il sito accessibile in ogni caso; solo che con browser che
possono sfruttare l'XmlHttpRequest la navigazione e' piu' "smart".
-- 
ZER0://coder.gfxer.web-designer/
~ I feel like I'm diagonally parked in a parallel universe.
on air ~ "Need to be strong"

 possono sfruttare l'XmlHttpRequest la navigazione e' piu' "smart".
Può essere una soluzione; stavo però pensando allo sviluppo e testing dei 2
casi (dopo quanto detto sopra non posso adesso scaricarmi io il sorgente e
ricompilarlo per avere una versione di mozilla senza l'oggettino!)
-- 
"That until there is no longer first class
And second class citizens of any nation
Until the colour of a man's skin
Is of no more significance than the colour of his eyes
Me say war"
B.M.
--

 ricompilarlo per avere una versione di mozilla senza l'oggettino!)
Io parlavo in generale. Di browser che non supportano XmlHttpRequest, quali
IE4 o Opera o quel che decidi piu' o meno di supportare.
Inoltre, il problema che sollevi su un "Mozilla che implementa
l'XmlHttpRequest ed uno che non lo implementa, a parita' di versione"
sarebbe stata un'annosa questione ai tempi del browser sniffing; ma adesso,
"nell'epoca dell'object checking", non devi preoccupartene.
-- 
ZER0://coder.gfxer.web-designer/
~ Il computer e' una macchina progettata per velocizzare e automatizzare
gli errori.
on air ~ "Victory"