Il linguaggio JavaScript
 

Variabili vuote fuori da $.get()!!

joseph.aiello.74@gmail.com 12 Mar 2015 13:10
Ciao a tutti,
sono nuovo e vorrei sottoporvi un problema che mi assilla.
uso la funzione $.get per accedere/interrogare un ******* xml ma quando sono
fuori dal get() le variabili sono null!!
Grazie in anticipo per l'aiuto.

ecco un codice di esempio:
-------------------------------------------------- ******* user.xml:

<?xml version="1.0" encoding="utf-8" ?>
<users>
<user>
<name>Barack Obama</name>
<age>53</age>
</user>
</users>
--------------------------------------------------
codice script:

$(document).ready(function(){
var Name;
var Age;
$.get("user.xml", function(data){
$(data).find('users').find("user").each(function(){

Name = $(this).find("name").text(); // <----- la variabile viene
assegnata correttamente
Age = $(this).find("age").text(); // <----- la variabile viene
assegnata correttamente
});
},
"xml"
);
$("#info").html(Name+", "+Age); // <----- le variabili sono null!!!
});
Nino Maravita 12 Mar 2015 14:13
Ciao,
le variabili sono null perché non ancora assegnate.
Mentre il codice prosegue, la memorizzazione nelle variabili avviene al
completamento della richiesta.
joseph.aiello.74@gmail.com 12 Mar 2015 14:47
Il giorno giovedì 12 marzo 2015 14:13:59 UTC+1, Nino Maravita ha scritto:
> Ciao,
> le variabili sono null perché non ancora assegnate.
> Mentre il codice prosegue, la memorizzazione nelle variabili avviene al
> completamento della richiesta.

Grazie per la tua risposta ma ... non capisco.
scusami ma provengo da c++ e da poco mi sono dedicato al web.
la chiamata a get() avviene prima e a seguire $("#info").html(Name+", "+Age).
Perché dici che "la memorizzazione nelle variabili avviene al
completamento della richiesta"?
Grazie.
fmassei@gmail.com 12 Mar 2015 15:04
On Thursday, March 12, 2015 at 2:47:44 PM UTC+1, joseph.a...@gmail.com wrote:
> Il giorno giovedì 12 marzo 2015 14:13:59 UTC+1, Nino Maravita ha scritto:
>> Ciao,
>> le variabili sono null perché non ancora assegnate.
>> Mentre il codice prosegue, la memorizzazione nelle variabili avviene al
>> completamento della richiesta.
>
> Grazie per la tua risposta ma ... non capisco.
> scusami ma provengo da c++ e da poco mi sono dedicato al web.
> la chiamata a get() avviene prima e a seguire $("#info").html(Name+", "+Age).
> Perché dici che "la memorizzazione nelle variabili avviene al
> completamento della richiesta"?
> Grazie.

.get chiama la funzione a secondo parametro dopo il completamento della
richiesta, che sicuramente avverrà dopo l'esecuzione della riga sotto.
E' uguale in C++, se immagini che quella che passi a .get sia una callback.

Ciao!
Andrea Scartabelli 12 Mar 2015 15:11
On 12/03/15 14:47, joseph.aiello.74@gmail.com wrote:
> Il giorno giovedì 12 marzo 2015 14:13:59 UTC+1, Nino Maravita ha scritto:
>> Ciao,
>> le variabili sono null perché non ancora assegnate.
>> Mentre il codice prosegue, la memorizzazione nelle variabili avviene al
>> completamento della richiesta.
>
> Grazie per la tua risposta ma ... non capisco.
> scusami ma provengo da c++ e da poco mi sono dedicato al web.
> la chiamata a get() avviene prima e a seguire $("#info").html(Name+", "+Age).
> Perché dici che "la memorizzazione nelle variabili avviene al
> completamento della richiesta"?

Perché le chiamate HTTP in genere sono asincrone.
Per la verità si possono fare anche sincrone, ma non è bello bloccare il
browser dell'utente in attesa di una risposta.

La funzione che passi come parametro a "get" è appunto una callback che
verrà (futuro) invocata quando la richiesta è completata, quindi è lì
che devi agire.

Questo in breve, poi, per tenere organizzato il codice ed evitare il
classico "spaghetti callback", è meglio spezzare il tutto in funzioni
più specializzate e ricorrere ad altri strumenti come le Promises
(chiamate anche Futures in altri linguaggi).

Dai una bella letta qui:

<http://www.html5rocks.com/en/tutorials/es6/promises/>
bramante 12 Mar 2015 15:21
Il 12/03/2015 15:11, Andrea Scartabelli ha scritto:

> Perché le chiamate HTTP in genere sono asincrone.
??????

il protocollo HTTP è SINCRONO

> Per la verità si possono fare anche sincrone, ma non è bello bloccare il

????
per la verità si possono anche fare ASINCRONO utilizzando la tecnica che
viene chiamata AJAX tramite il comando javascript XMLHttpRequest.

NON diamo informazioni sbagliate a chi sta iniziando.

Ciao
joseph.aiello.74@gmail.com 12 Mar 2015 15:38
Il giorno giovedì 12 marzo 2015 15:21:37 UTC+1, bramante ha scritto:
> Il 12/03/2015 15:11, Andrea Scartabelli ha scritto:
>
>> Perché le chiamate HTTP in genere sono asincrone.
> ??????
>
> il protocollo HTTP è SINCRONO
>
>> Per la verità si possono fare anche sincrone, ma non è bello bloccare il
>
> ????
> per la verità si possono anche fare ASINCRONO utilizzando la tecnica che
> viene chiamata AJAX tramite il comando javascript XMLHttpRequest.
>
> NON diamo informazioni sbagliate a chi sta iniziando.
>
> Ciao


GRAZIE A TUTTI, adesso è più chiaro
GRAZIE, GRAZIE.
Andrea Scartabelli 12 Mar 2015 16:27
On 12/03/15 15:21, bramante wrote:
> Il 12/03/2015 15:11, Andrea Scartabelli ha scritto:
>
>> Perché le chiamate HTTP in genere sono asincrone.
> ??????
>
> il protocollo HTTP è SINCRONO

E chi ha parlato di protocollo HTTP?

Peraltro avrei da ridire su questo, visto che non credo che il
protocollo di per sé possa essere considerato sincrono o asincrono:
dipende dal trasporto da come viene usato, ecc.

Vedi, ad esempio, HTTP Pipelining, che ha tutti gli aspetti di un
processo asincrono.

>> Per la verità si possono fare anche sincrone, ma non è bello bloccare il
>
> ????
> per la verità si possono anche fare ASINCRONO utilizzando la tecnica che
> viene chiamata AJAX tramite il comando javascript XMLHttpRequest.

Le chiamate HTTP fatte dall'interno di una pagina web sono in genere
asincrone (il flusso sul browser non si ferma in attesa della risposta)
e per questo si ragiona ad eventi e callback, anche da prima di "ajax".
Asincrona è anche l'impostazione predefinita di XMLHttpRequest, come
pure dei vari metodi "ajax" di jQuery.

Le chiamate sincrone hanno impatto sulla user experience e sono
solitamente sconsigliate, quando non addirittura deprecate.

> NON diamo informazioni sbagliate a chi sta iniziando.

Non mi sembra proprio questo il caso, non credi?
fmassei@gmail.com 12 Mar 2015 16:43
On Thursday, March 12, 2015 at 3:21:37 PM UTC+1, bramante wrote:
> Il 12/03/2015 15:11, Andrea Scartabelli ha scritto:
>
>> Perché le chiamate HTTP in genere sono asincrone.
> ??????
>
> il protocollo HTTP è SINCRONO
>
>> Per la verità si possono fare anche sincrone, ma non è bello bloccare il
>
> ????
> per la verità si possono anche fare ASINCRONO utilizzando la tecnica che
> viene chiamata AJAX tramite il comando javascript XMLHttpRequest.
>
> NON diamo informazioni sbagliate a chi sta iniziando.
>

Il protocollo HTTP non è né sincrono né asincrono, visto che è stateless.

Ciao!
bramante 12 Mar 2015 20:04
Il 12/03/2015 16:43, fmassei@gmail.com ha scritto:
> On Thursday, March 12, 2015 at 3:21:37 PM UTC+1, bramante wrote:
>> Il 12/03/2015 15:11, Andrea Scartabelli ha scritto:
>>
>>> Perché le chiamate HTTP in genere sono asincrone.
>> ??????
>>
>> il protocollo HTTP è SINCRONO
>>
>>> Per la verità si possono fare anche sincrone, ma non è bello bloccare il
>>
>> ????
>> per la verità si possono anche fare ASINCRONO utilizzando la tecnica che
>> viene chiamata AJAX tramite il comando javascript XMLHttpRequest.
>>
>> NON diamo informazioni sbagliate a chi sta iniziando.
>>
>
> Il protocollo HTTP non è né sincrono né asincrono, visto che è stateless.
>
> Ciao!
>


il protocollo HTTP effettua una richiesta e attende una risposta.

il fatto che sia stateless vuol semplicemente dire che una volta
effettuata la richiesta e ricevuta la risposta chiude la comunicazione
tra le parti (client/server).

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

http://en.wikipedia.org/wiki/Request-response

http://stackoverflow.com/questions/17481397/what-is-the-difference-between-synchronous-and-asynchronous-transmission-in-tcp

http://www.answers.com/Q/Why_http_is_asynchronous

http://hc.apache.org/httpcomponents-core-ga/tutorial/html/fundamentals.html

http://research.gigaom.com/2013/05/the-synchronous-vs-asynchronous-communication-debate-is-like-deja-vu-all-over-again/

Ciao
fmassei@gmail.com 12 Mar 2015 20:20
On Thursday, March 12, 2015 at 8:04:00 PM UTC+1, bramante wrote:
> Il 12/03/2015 16:43, fmassei@gmail.com ha scritto:
>> On Thursday, March 12, 2015 at 3:21:37 PM UTC+1, bramante wrote:
>>> Il 12/03/2015 15:11, Andrea Scartabelli ha scritto:
>>>
>>>> Perché le chiamate HTTP in genere sono asincrone.
>>> ??????
>>>
>>> il protocollo HTTP è SINCRONO
>>>
>>
>> Il protocollo HTTP non è né sincrono né asincrono, visto che è
stateless.
>>
>> Ciao!
>>
>

Mi sa che li dovevi leggere i link prima di metterli ;)
Comunque lascia perdere wikipedia e answers.com, leggiti gli rfc dal 7230 al
7235, quello serve.

> il protocollo HTTP effettua una richiesta e attende una risposta.
>

Il protocollo HTTP non effettua nulla. Il protocollo specifica come i messaggi
sono fatti ed il flow che due le parti devono seguire per utilizzarlo per
comunicare.
Nello specifico, ci sono domanda e risposta.

> il fatto che sia stateless vuol semplicemente dire che una volta
> effettuata la richiesta e ricevuta la risposta chiude la comunicazione
> tra le parti (client/server).
>

Mai sentito parlare di keep-alive? :) Sì, è definito nello standard HTTP.

E comunque, il fatto che sia stateless elimina la possibilità di definire
il flow come sincrono/asincrono: sincrono rispetto a cosa, visto che ogni
domanda/risposta è a se stante? :)

Ciao!

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio JavaScript | Tutti i gruppi | it.comp.lang.javascript | Notizie e discussioni javascript | Javascript Mobile | Servizio di consultazione news.