none
Aggiornare il client web da un thread secondario RRS feed

  • Domanda

  • Ciao a tutti,

    Ho una pagina che lancia un thread che fa delle elaborazioni e poi deve aggiornare il mio client web con un messaggio di qualche tipo che l'operazione è compiuta (magari sollevando un'alert tramite javascript). L'utente però nel frattempo potrebbe aver cambiato pagina in quanto l'interfaccia non risulta bloccata ed il thread intanto lavora per i fatti suoi.

    Come posso fare da un'altra pagina a fare questo? Il mio codice è simile a questo:

    Thread mioThread = new Thread(() =>
    {
        Elaborazione elaborazione = new Elaborazione(); elaborazione.FaiQualcheCosa();
        elaborazione.MyEvent += new EventHandler(elaborazione_MyEvent);
    });
    mioThread .Start();

    GRAZIE

    martedì 19 luglio 2011 07:14

Risposte

  • Pengo11 wrote:

    Ciao Raffaele,

    Tu dici: "Io parlavo della classica postback ajax in cui, a pagina caricata, jquery esegue una nuova richiesta al web server che la esegue in modo asincrono (cioè la pagina nel frattempo è usabile dal client)."

    Comincia a fare un po' di confusione...ma è colpa mia; avresti un esempio di questo tipo di scenario?

    Per chiarirti il discorso faccio alcune premesse:
    - al contrario di qualche anno fa, adesso i browser si stanno allineando sugli standard. Perciò html (non necessariamente html5), css, javascript sono strumenti fondamentali per un sito web. La parte client sempre più spesso è fondamentale per risolvere in modo semplice una grossa quantità di problematiche.

    - javascript è troppo poco e faticoso. Ormai tutti stanno cominciando ad utilizzare jQuery che usa in modo decisamente moderno javascript.
    jQuery ha una ampia serie di plugin (librerie) che rendono comodo lo sviluppo di problematiche che diversamente sarebbero improponibili.
    http://jquery.com/

    - modernizr è una libreria che consente di utilizzare facilmente le caratteristiche avanzate (html5/css3) dei browser senza dover diventare matti nel capire cosa si può fare un browser e non un altro.
     Tornando al tuo problema...
    Il browser fa una request, asp.net risponde producendo l'html corrispondente alla pagina che hai creato sul lato server e una volta spedita la response, il server ha finito completamente tutto il suo lavoro. Fine.

    Il browser riceve la pagina e qui comincia il bello. Una volta finito il caricamento, viene invocato un tuo script javascript (scritto con l'ausilio di jQuery).
    Lo script può essere avviato a seguito del caricamento della pagina:
    <script type="text/javascript">
    $().ready(function () {
        init();
    });
    </script>
    Oppure può essere eseguito in seguito a qualsiasi altro evento che venga scaturito dagli eventi del DOM DHTML (mouseover dell'utente su un elemento, click di un bottone, etc.)

    All'interno dello script chiami in modo asincrono la tua webapp (oppure un servizio REST o quant'altro vogliamo inventarci) grazie alla funzione di libreria "ajax":
    http://api.jquery.com/jQuery.ajax/
    Gli esempi che trovi al link sono molto semplici ed autoesplicatori
    Tutto questo avviene mentre il browser è "fermo" cioè la pagina è già stata caricata e l'utente è libero di "giocare" con la pagina come meglio crede.

    La chiamata ajax arriva al tuo webserver e puoi gestirla come meglio credi. Non devi generare una pagina ma semplicemente erogare i dati che servono al tuo script lato client. Il risultato di una chiamata ajax è tipicamente una stringa in formato JSON che javascript/jQuery sono in grado di deserializzare in oggetti che sono più facilmente utilizzabili dal lato client in javascript.

    Appena hai il risultato della chiamata Ajax puoi continuare a lavorare con gli script che elaboreranno il risultato della chiamata, aggiornando la pagina html.
    Facebook funziona con questo tipo di logica.
     Per la cronaca, ajax è una tecnologia che esiste dalla fine degli anni '90, inventata da Microsoft sotto il nome di XmlHttp, un activex in grado di eseguire chiamate asincrone.
    Ajax è diventato famoso a partire dal 2004 grazie a google suggest come scrivevo qui:
    http://blogs.ugidotnet.org/raffaele/archive/2004/12/14/7033.aspx
     Un esempio di applicazione tutta fatta con html5 e jquery che attinge dati dai RIA services (WCF):
    http://blogs.ugidotnet.org/raffaele/archive/2011/05/04/il-cambio-delle-ui-e-del-ruolo-di-silverlight.aspx
    Ogni click su pagina avanti/indietro, filtro, etc. esegue script jQuery con chiamate ajax per avere dal server i dati.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    • Contrassegnato come risposta Pengo11 venerdì 22 luglio 2011 13:42
    giovedì 21 luglio 2011 19:29

Tutte le risposte

  • Se l'utente cambia la pagina... l'unico modo è utilizzare una tabella da interrogare per vedere lo stato dell'elaborazione e modificare le tue pagine per interrogare la tabella e mandare a video un messaggio nel caso in cui l'elaborazione sia stata eseguita.

    Ciao


    Luca Congiu (congiuluc)
    martedì 19 luglio 2011 07:40
    Moderatore
  • Ciao,
    la questione diventa un pochetto difficile se cambi pagina, solo perché devi predisporre tutto il sito in modo che controlli l'esecuzione del thread.

    La soluzione sarebbe quella di creare una classe che si occupa di far partire il thread, aggiungere un paio di proprietà a questa classe tipo isRunning, IsAsync ecc (in base alle esigenze), e salvare la classe in session (o cache).
    Ecco che invecie di stare a scrivere e leggere su una tabella, basta fare:

    BackgroundProcess bgkP = (BackgroundProcess)Session["BackgroundProcess"];
    if (bgkP != null)
      bool stillExecuting = bgkP.isRunning;
    
    

    Quello che devi implementare è un polling continuo che esegue il codice sopra, e nel momento in cui stillExecuting risulta false, puoi avvertire l'utente. Però, come ti ripeto, se l'utente cambia pagina, capisci che attivare un polling sermpre esistente in tutto il sito, non è una cosa bellissima. Puoi pensare di ampliare un po il codice e magari implementare una soluzione che utilizza COMET, dovresti riuscire a risolvere con più stile.

    Comunque vedi un esempio completo qui: Long Running Task

    Non puoi impedire all'utente di cambiare pagina? o perlomento avvertire che un processo è in esecuzione e se cambia pagina non saprà l'esito del processo (vedi myGoogle).


    Programamtore ASP.NET
    http://glucolo.wordpress.com
    martedì 19 luglio 2011 07:54
  • Pengo11 wrote:

    Ciao a tutti,

    Ho una pagina che lancia un thread che fa delle elaborazioni e poi deve aggiornare il mio client web con un messaggio di qualche tipo che l'operazione è compiuta (magari sollevando un'alert tramite javascript). L'utente però nel frattempo potrebbe aver cambiato pagina in quanto l'interfaccia non risulta bloccata ed il thread intanto lavora per i fatti suoi.

    Come posso fare da un'altra pagina a fare questo? Il mio codice è simile a questo:

    Thread mioThread = new Thread(() =>
    {
        Elaborazione elaborazione = new Elaborazione(); elaborazione.FaiQualcheCosa();     elaborazione.MyEvent += new EventHandler(elaborazione_MyEvent); });
    mioThread .Start();

    GRAZIE

    Non mi sembra che abbia molto senso.
    Quel codice è lato server e tu parli di un alert sul lato client.
    Se lanci il thread in quel modo:
    - nel frattempo la pagina viene creata e spedita al lato client, quindi il thread primario termina
    - il thread secondario andrà "perso"
    - visto che la connessione è chiusa il server non avrà alcun modo di informare il client

    Se vuoi eseguire un'operazione asincrona una soluzione semplice è quella di farla iniziare con una chiamata ajax via jquery. Con MVC è triviale.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    martedì 19 luglio 2011 09:05
  • Ciao a tutti,

    Implementare un polling è un'operazione che vorrei evitare di implementare a causa della scalabilità del sito. Se con un'operazione asincrona evito il timeout mi andrebbe anche bene.

    In effetti con un thread secondario non riesco poi a chiamare il client. Se lancio un'operazione asincrona, e blocco l'utente sulla pagina, non mi va in ogni caso in timeout la pagina aspx?

    Grazie

    giovedì 21 luglio 2011 08:11
  • Pengo11 wrote:

    Ciao a tutti,

    Implementare un polling è un'operazione che vorrei evitare di implementare a causa della scalabilità del sito. Se con un'operazione asincrona evito il timeout mi andrebbe anche bene.

    Il polling migliora la scalabilità, mentre tenere aperta la comunicazione più a lungo la peggiora notevolmente, specie se apri thread differenti (aumentano il numero di thread contemporaneamente aperti, mettendo in croce il server).

    Un esempio per tutti è Facebook che esegue tutto lato client con chiamate ajax. Direi che il loro carico sia un esempio di buona scalabilità.


    In effetti con un thread secondario non riesco poi a chiamare il client. Se lancio un'operazione asincrona, e blocco l'utente sulla pagina, non mi va in ogni caso in timeout la pagina aspx?

    Dipende dal timeout che imposti ma qui nascono altri problemi.
    Se l'utente si scoccia e fa refresh il thread lato server abortisce, quindi devi essere in grado di far fronte ad un'interruzione del tuo codice in qualsiasi punto accada, il che non è propriamente banale.

    Con le chiamate ajax il problema non esiste. La pagina carica velocemente e l'utente è "soddisfatto". Nel frattempo in modo asincrono esegui delle chiamate ajax al server recuperando quello che ti serve.

    Per tua info, in futuro avrai anche la possibilità di usare le websockets:
    http://html5labs.interoperabilitybridges.com/
    Ma per il momento lo standard è ancora in discussione tra le parti e quindi non stabile da poter essere utilizzato.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    giovedì 21 luglio 2011 09:08
  • Ciao Raffaele,

    ci sono delle affermazioni che non mi tornano in quello che dici, e secondo me sono proprio errate!!!!!

    1. Se lanci il thread in quel modo il thread secondario andrà "perso"

      Non sono affatto d'accordo. Il thread secondario continua per conto suo, nessuno lo blocca. casomai non ci sono molte possibilità di reperirlo dal thread di esecuzione della pagina.
    2. Il polling migliora la scalabilità, mentre tenere aperta la comunicazione più a lungo la peggiora notevolmente, specie se apri thread differenti (aumentano il numero di thread contemporaneamente aperti, mettendo in croce il server).

      È un po' una contraddizione: eseguire un polling è per forza un thread differente da quello che sta girando sul server "in background", inoltre non credo che bastino un paio di thread contemporanei a mettere in croce un server. Anche le chiamate ajax e l'uso di IAsyncResult sono thread diversi!!!!


    Programamtore ASP.NET
    http://glucolo.wordpress.com
    giovedì 21 luglio 2011 11:09
  • Glauco Cucchiar wrote:
    [...]

    Ciao Glauco,

    1. Se lanci il thread in quel modo il thread secondario andrà "perso"

       Non sono affatto d'accordo. Il thread secondario continua per conto suo, nessuno lo blocca. casomai non ci sono molte possibilità di reperirlo dal thread di esecuzione della pagina.

    Dal primo post di Pengo11 ho capito che lui volesse poi parlare con il client. Interpretazione che poi era giusta visto che lui stesso ha affermato "In effetti con un thread secondario non riesco poi a chiamare il client".
    Per "perso" (virgolettato) intendevo proprio dire che quando il thread termina, non ha più modo di parlare con il client a meno che il thread principale non tenga in sospeso la response della pagina.
     >  2. Il polling migliora la scalabilità,

    mentre tenere aperta la comunicazione più a lungo la peggiora notevolmente, specie se apri thread differenti (aumentano il numero di thread contemporaneamente aperti, mettendo in croce il server).

       È un po' una contraddizione: eseguire un polling è per forza un thread differente da quello che sta girando sul server "in background", inoltre non credo che bastino un paio di thread contemporanei a mettere in croce un server. Anche le chiamate ajax e l'uso di IAsyncResult sono thread diversi!!!!

    Per avere scalabilità conta il picco di CPU che raggiungi, non certo il numero di thread.
    Caso 1: la pagina viene tenuta aperta attendendo che il thread secondario termini, dopo di che response del risultato.
    Qui hai due thread aperti per tutto il periodo, dall'inizio della request alla response finale. Le risorse sono allocate per tutto il periodo e la connessione tcp al webserver rimane aperta per tutto il periodo.

    Caso 2: la pagina viene restituita senza operazioni asincrone. Finita la response il client inizia una nuova request verso il server chiedendo quanto gli manca.
    Qui hai dei vantaggi in termini di scalabilità:
    - hai sempre un solo thread alla volta che impegna il server, cosa molto importante visto che il thread-pool di asp.net non è infinito.

    - finita la response c'è un periodo di "pausa" prima della request asincrona, cosa che permette ad IIS di bilanciare meglio le risorse

    - la request secondaria può essere dirottata su una webapp/servizio/server differente qualora il carico diventasse maggiore. Il tutto in totale trasparenza rispetto a quanto vede l'utente.

    - espandendo il punto precedente, puoi usare servizi REST per le postback abbattendo ancora di più il carico sul lato server. (per esempio le nuove WCF Http API ancora in CTP)

    - se usi asp.net, puoi usare meno risorse rispetto ad una request normale perché molti moduli della pipeline di asp.net potrebbero non servire affatto (es: session)

    - la decisione di avviare il postback è nelle mani dell'utente (pagina html/javascript). In alcuni casi questo può evitare del tutto il postback
     In sostanza la soluzione polling "spalma" il carico nel tempo o addirittura permette di distribuirlo su hardware differente mentre la richiesta asincrona obbliga a sincronizzare la richiesta al thread principale, cosa che aumenta il carico sul server.

    Spero di aver reso l'idea.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    giovedì 21 luglio 2011 11:44
  • Per "perso" (virgolettato) intendevo proprio dire che quando il thread termina, non ha più modo di parlare con il client a meno che il thread principale non tenga in sospeso la response della pagina

    A parer mio non deve essere il thread secondario a parlare con il client, ma deve essere il client a cercare il thread secondario/backgroud, appunto con polling e variabile di sessione, senza quindi rimanere in sospeso:
    Long Running Task e Long Running Process.
    Altrimenti ci vorrebbe una implementazione COMET molto più complessa.


    Caso 2: la pagina viene restituita senza operazioni asincrone. Finita la response il client inizia una nuova request verso il server chiedendo quanto gli manca.

    pienamente d'accordo!!! Abbiamo detto praricamente la stessa cosa..... basta intenderci... ;-)

    P.S.: consa intendi per: "se usi asp.net, puoi usare meno risorse rispetto ad una request normale perché molti moduli della pipeline di asp.net potrebbero non servire affatto (es: session)"?
    puoi spiegarmi meglio?

     

    Ciao


    Programamtore ASP.NET
    http://glucolo.wordpress.com
    giovedì 21 luglio 2011 12:26
  • Glauco Cucchiar wrote:

    Per "perso" (virgolettato) intendevo proprio dire che quando il thread termina, non ha più modo di parlare con il client a meno che il thread principale non tenga in sospeso la response della pagina

    A parer mio non deve essere il thread secondario a parlare con il client, ma deve essere il client a cercare il thread secondario/backgroud, appunto con polling e variabile di sessione, senza quindi rimanere in sospeso: Long Running Task <http://glucolo.wordpress.com/2011/06/20/long-running-task-with-asp-net/> eLong Running Process <http://www.ajaxmatters.com/2006/05/dealing-with-long-running-processes-in-asp-net/>. Altrimenti ci vorrebbe una implementazione COMET molto più complessa.

    Il problema di scalabilità non sta tanto nel "chi parla con chi" (che merita certamente un discorso ampio a parte) ma quanto al fatto che il thread primario e la connessione attiva TCP non deve essere chiusa fino a che il thread secondario sta svolgendo il suo lavoro. E questo è un problema di scalabilità.

    Per la cronaca è una situazione analoga a quando si usa Workflow Foundation in asp.net. Fin dall'inizio il team raccomandava infatti di non utilizzare lo scheduler di default (che apriva un thread secondario) ma di utilizzare lo scheduler manuale in modo da far eseguire il workflow nel contesto del thread che genera la pagina asp.net.
     > pienamente d'accordo!!! Abbiamo detto praricamente la stessa cosa..... basta

    intenderci... ;-)

    bene :)
     >

    P.S.: consa intendi per: "se usi asp.net, puoi usare meno risorse rispetto ad una request normale perché molti moduli della pipeline di asp.net potrebbero non servire affatto (es: session)"? puoi spiegarmi meglio?

    La pipeline di asp.net ha un costo misurabile nel numero di Module da cui passa la request. Mentre una pagina asp.net classica ha bisogno di un certo numero di Module (alcuni di default, altri custom, specifici dell'applicazione), quando invece la richiesta è generata da ajax per avere dei dati, molti Module sono inutili e quindi è opportuno evitare che vengano attivati.
    Un esempio (proprio quella della session):
    http://blogs.ugidotnet.org/raffaele/archive/2011/07/05/asp.net-mvc-immagini-dinamiche-e-performance.aspx

    Ovviamente si può fare di meglio, cioè chiamando dei servizi REST invece che una webapp perché verrebbero usate meno risorse/Module.
    Tra l'altro se il servizio gira in una application differente avresti il vantaggio di non intaccare il thread-pool dell'applicazione principale e quindi di fatto dimezzando l'uso dei thread nella webapp.

    Ciao

    Ciao!


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    • Contrassegnato come risposta Pengo11 venerdì 22 luglio 2011 13:40
    • Contrassegno come risposta annullato Pengo11 venerdì 22 luglio 2011 13:42
    giovedì 21 luglio 2011 13:36
  • La pipeline di asp.net ha un costo misurabile nel numero di Module da cui passa la request. Mentre una pagina asp.net classica ha bisogno di un certo numero di Module (alcuni di default, altri custom, specifici dell'applicazione), quando invece la richiesta è generata da ajax per avere dei dati, molti Module sono inutili e quindi è opportuno evitare che vengano attivati.

    Avevo immaginato che stavi parlando di questo, ma la mia domanda si riferiva più che altro sul come. L'esempio che mi hai dato (molto ben spiegato) si riferisce a MVC. In WebForm, la stessa cosa la potrei risolvere con Handler Generici? Dove posso usare "[SessionState(System.Web.SessionState.SessionStateBehavior.Disabled)]"??

    Il problema di scalabilità non sta tanto nel "chi parla con chi" (che merita certamente un discorso ampio a parte) ma quanto al fatto che il thread primario e la connessione attiva TCP non deve essere chiusa fino a che il thread secondario sta svolgendo il suo lavoro. E questo è un problema di scalabilità.

    È quì che non ci capiamo.......
    In entrambe le soluzioni proposte sopra, il thread primario viene chiuso, il secondario lavora, e nuovi thread/request vengono attivate (polling con javascript) per "parlare" con il secondario.
    Dov'è il punto di rottura tra i nostri punti di vista? Non lo trovo!
    Perché mi dici che il thread primario NON deve essere chiuso?

    ciao


    Programamtore ASP.NET
    http://glucolo.wordpress.com
    giovedì 21 luglio 2011 14:07
  • Glauco Cucchiar wrote:

    Avevo immaginato che stavi parlando di questo, ma la mia domanda si riferiva più che altro sul come. L'esempio che mi hai dato (molto ben spiegato) si riferisce a MVC. In WebForm, la stessa cosa la potrei risolvere con Handler Generici? Dove posso usare "[SessionState(System.Web.SessionState.SessionStateBehavior.Disabled)]"??

    Per la session hai la direttiva Page in cui puoi disabilitare la session per quella pagina specificamente.

    Per agire sui custom Module devi implementare le factory e decidere se creare il Module oppure "cortocircuitare" la pipeline in modo da attivare solo l'handler che si prenderà cura della richiesta.
     > È quì che non ci capiamo.......

    In entrambe le soluzioni proposte sopra, il thread primario viene chiuso, il secondario lavora, e nuovi thread/request vengono attivate (polling con javascript) per "parlare" con il secondario. Dov'è il punto di rottura tra i nostri punti di vista? Non lo trovo! Perché mi dici che il thread primario NON deve essere chiuso?

    Non è quello che intendevo io.
    Io parlavo della classica postback ajax in cui, a pagina caricata, jquery esegue una nuova richiesta al web server che la esegue in modo asincrono (cioè la pagina nel frattempo è usabile dal client). È molto più semplice e nella maggior parte di scenari non penalizza l'utente.
     Volendo invece far partire l'elaborazione lunga fin dalla prima richiesta della pagina, non andrei a recuperare il thread perché ti lega a quell'istanza di worker process, cosa che farebbe fallire la richiesta se capitasse durante un recycle.
    Adotterei invece un'architettura differente... una cosa di questo tipo:
    - invoco un servizio eterno che accoda una richiesta e svolge in modo asincrono l'elaborazione (workflow / message queue / ...)
    - creo una sorta di cookie (ottenuto con un'operazione crittografica) che restituisco al client
    - la persistenza dello stato di avanzamento o del risultato va in un db in modo da disaccoppiare la webapp dal servizio che dialoga via ajax
    - ad ogni richiesta ajax del client restituisco il prossimo intervallo di polling o il risultato se l'operazione è terminata.

    Se però il dialogo non è autenticato / non protetto, è complicato difendersi da attacchi che tentino di ottenere i risultati di un altro utente. Il meccanismo di anti-forgery di asp.net (mvc) può non essere sufficiente a seconda del tipo di attacco.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    giovedì 21 luglio 2011 14:30
  • Ciao Raffaele,

    Tu dici: "Io parlavo della classica postback ajax in cui, a pagina caricata, jquery esegue una nuova richiesta al web server che la esegue in modo asincrono (cioè la pagina nel frattempo è usabile dal client)."

    Comincia a fare un po' di confusione...ma è colpa mia; avresti un esempio di questo tipo di scenario?

     

    Grazie!

    giovedì 21 luglio 2011 18:14
  • Pengo11 wrote:

    Ciao Raffaele,

    Tu dici: "Io parlavo della classica postback ajax in cui, a pagina caricata, jquery esegue una nuova richiesta al web server che la esegue in modo asincrono (cioè la pagina nel frattempo è usabile dal client)."

    Comincia a fare un po' di confusione...ma è colpa mia; avresti un esempio di questo tipo di scenario?

    Per chiarirti il discorso faccio alcune premesse:
    - al contrario di qualche anno fa, adesso i browser si stanno allineando sugli standard. Perciò html (non necessariamente html5), css, javascript sono strumenti fondamentali per un sito web. La parte client sempre più spesso è fondamentale per risolvere in modo semplice una grossa quantità di problematiche.

    - javascript è troppo poco e faticoso. Ormai tutti stanno cominciando ad utilizzare jQuery che usa in modo decisamente moderno javascript.
    jQuery ha una ampia serie di plugin (librerie) che rendono comodo lo sviluppo di problematiche che diversamente sarebbero improponibili.
    http://jquery.com/

    - modernizr è una libreria che consente di utilizzare facilmente le caratteristiche avanzate (html5/css3) dei browser senza dover diventare matti nel capire cosa si può fare un browser e non un altro.
     Tornando al tuo problema...
    Il browser fa una request, asp.net risponde producendo l'html corrispondente alla pagina che hai creato sul lato server e una volta spedita la response, il server ha finito completamente tutto il suo lavoro. Fine.

    Il browser riceve la pagina e qui comincia il bello. Una volta finito il caricamento, viene invocato un tuo script javascript (scritto con l'ausilio di jQuery).
    Lo script può essere avviato a seguito del caricamento della pagina:
    <script type="text/javascript">
    $().ready(function () {
        init();
    });
    </script>
    Oppure può essere eseguito in seguito a qualsiasi altro evento che venga scaturito dagli eventi del DOM DHTML (mouseover dell'utente su un elemento, click di un bottone, etc.)

    All'interno dello script chiami in modo asincrono la tua webapp (oppure un servizio REST o quant'altro vogliamo inventarci) grazie alla funzione di libreria "ajax":
    http://api.jquery.com/jQuery.ajax/
    Gli esempi che trovi al link sono molto semplici ed autoesplicatori
    Tutto questo avviene mentre il browser è "fermo" cioè la pagina è già stata caricata e l'utente è libero di "giocare" con la pagina come meglio crede.

    La chiamata ajax arriva al tuo webserver e puoi gestirla come meglio credi. Non devi generare una pagina ma semplicemente erogare i dati che servono al tuo script lato client. Il risultato di una chiamata ajax è tipicamente una stringa in formato JSON che javascript/jQuery sono in grado di deserializzare in oggetti che sono più facilmente utilizzabili dal lato client in javascript.

    Appena hai il risultato della chiamata Ajax puoi continuare a lavorare con gli script che elaboreranno il risultato della chiamata, aggiornando la pagina html.
    Facebook funziona con questo tipo di logica.
     Per la cronaca, ajax è una tecnologia che esiste dalla fine degli anni '90, inventata da Microsoft sotto il nome di XmlHttp, un activex in grado di eseguire chiamate asincrone.
    Ajax è diventato famoso a partire dal 2004 grazie a google suggest come scrivevo qui:
    http://blogs.ugidotnet.org/raffaele/archive/2004/12/14/7033.aspx
     Un esempio di applicazione tutta fatta con html5 e jquery che attinge dati dai RIA services (WCF):
    http://blogs.ugidotnet.org/raffaele/archive/2011/05/04/il-cambio-delle-ui-e-del-ruolo-di-silverlight.aspx
    Ogni click su pagina avanti/indietro, filtro, etc. esegue script jQuery con chiamate ajax per avere dal server i dati.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    • Contrassegnato come risposta Pengo11 venerdì 22 luglio 2011 13:42
    giovedì 21 luglio 2011 19:29
  • Tutto questo avviene mentre il browser è "fermo" cioè la pagina è già stata caricata e l'utente è libero di "giocare" con la pagina come meglio crede.

    tranne che spostarsi (tramite menu ad esempio), ovvero cambaire pagina o inviare postback sincroni

    Per la cronaca, ajax è una tecnologia che esiste dalla fine degli anni '90, inventata da Microsoft sotto il nome di XmlHttp, un activex in grado di eseguire chiamate asincrone.

    questa è grossa!!!!!!!!!!!!!!
    Alcune citazioni:

    Asynchronous loading of content first became practical when Java applets were introduced in the first version of the Java language in 1995. These allow compiled client-side code to load data asynchronously from the web server after a web page is loaded.

    The earliest form of asynchronous remote scripting was developed before XMLHttpRequest existed, and made use of very simple process: a static web page opens a dynamic web page (e.g. at other target frame) that is reloaded with new JavaScript content, generated remotely on the server side.

    The concept behind the XMLHttpRequest object was originally created by the developers of Outlook Web Access (by Microsoft) for Microsoft Exchange Server 2000. An interface called IXMLHTTPRequest was developed and implemented into the second version of the MSXML library using this concept. The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.

    In the early 2000s, as author of the popular Ashley IT Remote Scripting Resources site and the JSRS and RSLite JavaScript Remote Scripting libraries, Brent made his mark as a recognized expert and pioneer in Ajax rich web application development techniques.

    Le mie conclusioni:
    - Le prime forme embrionali di AJAX nascono con RemoteScripting (a+j+a+x è un termine coniato in seguito) sono iniziate nel 1995 con applet java, capaci di fare chiamate al server (le vecchie CGI) senza ricaricare la pagina.
    - Altre fome embrionali usavano javascript per caricare pagine dentro FRAME che restituivano dati, html e javascript che modificava la pagina nel frame principale. Tecnica evoluta poi nel 1997 con la nascita di IFRAME.
    - La base dell'attuale AJAX possiamo datarla tra il 1999 e il 2000 con l'arrivo di due diverse classi/librerie create da Microsoft: Microsoft's Remote Scripting e XMLHttpRequest

    http://simpletutorials.com/?path=tutorials/javascript/jsrs
    http://developer.apple.com/internet/webcontent/iframe.html
    http://js-rs.sourceforge.net/
    http://www.alexhopmann.com/xmlhttp.htm


    Programamtore ASP.NET
    http://glucolo.wordpress.com
    venerdì 22 luglio 2011 13:30
  • Glauco Cucchiar wrote:

    tranne che spostarsi (tramite menu ad esempio), ovvero cambaire pagina o inviare postback sincroni

    beh sul web è sempre una possibilità. Ma se crei un meccanismo per recuperare i risultati partendo da un altro postback, almeno l'elaborazione in background non va persa.
    Inoltre l'utente va poco daccordo con le pagine che non finiscono di caricare e solitamente il pulsante refresh è la prima cosa che fa.
     > questa è grossa!!!!!!!!!!!!!!

    Alcune citazioni:

    [...]

    Quello che oggi viene usato come ajax deriva da xmlhttp.
    Non ho mai detto cosa facessero o non facessero i java applet, ma ajax è nato grazie a xmlhttp.

    http://www.w3.org/TR/XMLHttpRequest/


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    venerdì 22 luglio 2011 14:16
  • mettendo in sieme tutte le tue affermazioni in unica pagina, e leggendole di seguito, il discorso cambia strada un paio di volte e ci sono un paio di affermazioni che contraddicono altre.
    Comuqnue.... l'importante è che il concetto sia stato capito da Pengo11

    Quello che oggi viene usato come ajax deriva da xmlhttp

    Possiamo stare a disquisire per ore intere su quello che viene usato ora e quello che era prima, e su chi per primo abbia inventato l'ultimo strumento per "fare" ajax.
    Chi ha inventato l'ultimo strumento non vuol dire che abbia inventato la metodologia.
    Il fatto che la metodologia prima sconosciuta sia venuta fuori grazie a google (GMail prima, ma ancor più clamorosamente con Suggest poi) che ha usato xmlhttp, non vuol dire che xmlhttp "sia la" medotologia, o tutto deriva da xmlhttp.

    Asynchronous JavaScript And XML
    java applet, FRAME, IFRAME facevano uso di javascript per effettuare richieste asincrone e recuperare xml (ed altro).
    Il fatto che xmlhttp sia stato il punto di partenza per "integrare" il tutto direttamente dentro il browser, non è la nascita della metodologia ma dell'integrazione.
    Prima che l'oggetto fosse integrato nei browser, si usava appunto "new ActiveXObject("Msxml2.XMLHTTP.6.0");"
    che differanza c'è tra usare un ActiveXObject o un Applet?????
    Allora i browser che non supportavano xmlhttp ma altri oggetti non permettevano l'utilizzo AJAX?

    function load(url, targetObj) { 
    if (typeof (targetObj) == "string") {
    targetObj = document.getElementById(targetObj);
    }


    if (typeof (XMLHttpRequest) != "undefined") {
    loadXML(url, targetObj); //usa new XMLHttpRequest();
    } else if (navigator.javaEnabled()) {
    loadJava(url, targetObj); //usa new java.net.URL(new java.net.URL(window.location.href),srcUrl);
    } else {
    loadFrame(url, targetObj); //usa IFRAME
    }
    }

    una pagina web con questo script, sara sempre AJAX anche se visualizzata con un Opera/Geko vecchio (quindi va nel secondo if con java se abilitato nelle preferenze, altrimenti usa iframe), o è AJAX solo in base a chi la visualizza?

    DEFINIZIONE:
    Ajax (also AJAX; pronounced /ˈeɪdʒæks/; an acronym for asynchronous JavaScript and XML)<sup id="cite_ref-garrett_0-0" class="reference">[1]</sup> is a group of interrelated web development methods used on the client-side to create interactive web applications. With Ajax, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page.

    Non si parla di "con che cosa", ma di "metodo"

    Se i dici che il "TERMINE" AJAX è nato con XMLHttp, posso sforzarmi e dirti di si,
    se midici che ajax in senso di metodologia, o meglio "insieme di tecniche", NO secco!!!!!!

    Poi, se vogliamo riderci sopra, il termine AJAX è nato per un "cesso"
    http://hishamgalal.blogspot.com/2010/11/first-use-of-ajax-terminology.html


    Programamtore ASP.NET
    http://glucolo.wordpress.com


    venerdì 22 luglio 2011 15:09
  • Glauco Cucchiar wrote:

    mettendo in sieme tutte le tue affermazioni in unica pagina, e leggendole di seguito, il discorso cambia strada un paio di volte e ci sono un paio di affermazioni che contraddicono altre. Comuqnue.... l'importante è che il concetto sia stato capito da Pengo11

    Non capisco proprio dove dici che prende strade diverse.
    Se intendi ancora il discorso del "perso", credevo di averlo chiarito. Era virgolettato e il suo significato l'ho chiarito.

    Quello che oggi viene usato come ajax deriva da xmlhttp

    Possiamo stare a disquisire per ore intere su quello che viene usato ora e quello che era prima, e su chi per primo abbia inventato l'ultimo strumento per "fare" ajax.

    Non era questo il punto da cui è partito il discorso.
    Ajax è nato da xmlhttp. Questo non esclude che altri facessero postback in altro modo (dovremmo anche andare a vedere tutti gli activex che facevano postback o parlavano via socket) ma non sarebbero comunque ajax che si riferisce specificamente ad uno specifico modo di fare postback e cioè di usare xmlhttprequest.

    Mi sembra che il sito w3c sia eloquente soprattutto quando, al link che ho postato, scrivono: "Special thanks to the Microsoft employees who first implemented the XMLHttpRequest interface, which was first widely deployed by the Windows Internet Explorer browser."
     [...]

    Se i dici che il "TERMINE" AJAX è nato con XMLHttp, posso sforzarmi e dirti di si, se midici che ajax insenso di metodologia, o meglio "insieme di tecniche", NO secco!!!!!!

    Ajax non è solo un termine perché definisce un'interfaccia che è stata integrata nel DOM di tutti i browser (XMLHttpRequest) ed utilizzata da jQuery (e non solo) per fare postback.

    Perciò quando scrivo che "ajax è una tecnologia che esiste dalla fine degli anni '90, inventata da Microsoft sotto il nome di XmlHttp" e che questo risulta chiaramente dal sito w3c, mi sembra che non ci sia molto nè da discutere nè da chiarire.
     -- Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    venerdì 22 luglio 2011 16:09
  • Appunto, stiamo pure a disquisire.......

    Premessa:
    per capirci meglio scriverò
    "Ajax" quando vorrò intendere la metodologia, il fatto di effettuare richieste asincrone,
    "AJAX" quando vorrò intendere il termine, ovvero l'uso di Ajax con XMLHttp

    ma non sarebbero comunque ajax che si riferisce specificamente ad uno specifico modo di fare postback e cioè di usare xmlhttprequest.

    Quello che dici tu è il TERMINE.
    Jesse James Garrett, nel 2005, per spiegare "a new approach to web applications" ha fatto riferimento a Goolge Maps e Google Suggest, ed ha coniato il "TERMINE" AJAX. Queste applicazioni facevano effettivamente uso di XmlHttpRequest (ma anche ActiveX e IFRAME)
    (Maps fa ancora uso di IFRAME, vieni a dirmi che non è Ajax Google Maps)

    Il sito W3C è eloquente nel ringraziare Microsoft che ha introdotto per prima l'oggetto/interfaccia, "uno dei tanti modi per effettuare richieste HTTP verso il server", ma mai parla di AJAX/Ajax.
    Il fatto che W3C abbia, nell'aprile 2005, pubblicato le prime specifiche per:
    goal is "to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code." scritto tra l'altro da un componente di Opera Software ASA, come ho già detto è l'inizio della creazione di specifiche per la standardizzazione su tutti i browser di uno dei metodi, diventato poi IL metodo, per effettuare richieste "asincrone".

    Ajax non è solo un termine perché definisce un'interfaccia che è stata integrata nel DOM di tutti i browser (XMLHttpRequest) ed utilizzata da jQuery (e non solo) per fare postback. Perciò quando scrivo che "ajax è una tecnologia che esiste dalla fine degli anni '90, inventata da Microsoft sotto il nome di XmlHttp" e che questo risulta chiaramente dal sito w3c, mi sembra che non ci sia molto nè da discutere nè da chiarire.
    1. Ajax non definisce un'interfaccia e nemmeno una tecnologia, ma una metodologia che mette assieme diverse tecniche/tecnologie. Di conseguenza nemmeno AJAX è un'interfaccia, ma la descrizione di una metodologia, una implementazione specifica.
    2. Sotto il nome di XmlHttp microsoft ha inventato una "INTERFACCIA/OGGETTO/API" atta a implementere/utilizzare una tecnica usata da oramai molti anni: effettuare richieste HTTP "asincrone"

    In 1999, Microsoft utilized its iframe technology to dynamically update the news stories and stock quotes on the default page for Internet Explorer. (usava la tecnica/metodologia di quello che è stato chiamato jsRemoteScripting)
    Quindi non è Ajax questo?

    In seguito, visti i buoni risultati ed il successo di questa metodologia, (per l'ennesima volta..) gia utilizzata da molte aziende in molti siti da diverso tempo (circa 3 anni ...), ha deciso in creare XMLHttp per integrare quello che stava gia facendo con IFRAME, direttamente nel suo browser IE con un ActiveX prima, con API dopo.
    Microsoft ha INVENTATO/INTEGRATO oggetti nel suo browser per fare Ajax

    1. Ajax è una metodologia?
      SI
    2. Microsoft ha inventato Ajax usando IFRAME nel 1999?
      Forse, chi mai lo saprà........
    3. XmlHttpRequest è diventato lo standard?
      SI
    4. Microsoft ha inventato Ajax sotto il nome di XmlHttp?
      NOOOOOOOOOOOOOOOOOOOOOOOOO

     


    Programamtore ASP.NET
    http://glucolo.wordpress.com

    • Modificato Glauco Cucchiar sabato 23 luglio 2011 04:19 inserita citazione
    sabato 23 luglio 2011 04:04
  • Glauco Cucchiar wrote:

    1. Ajax non definisce un'interfaccia e nemmeno una tecnologia, ma una metodologia che mette assieme diverse tecniche/tecnologie. Di conseguenza nemmeno AJAX è un'interfaccia, ma la descrizione di una metodologia.

    Stando al link che ho postato di w3c questo è falso

    2. Sotto il nome di XmlHttp microsoft ha inventato una "INTERFACCIA/OGGETTO/API" atta a implementere/utilizzare una tecnica usata da oramai molti anni: effettuare richieste HTTP "asincrone"

    ok

    In 1999, Microsoft utilized its iframe technology to dynamically update the news stories and stock quotes on the default page for Internet Explorer. Quindi non è Ajax questo?

    Se usava xmlhttprequest si altrimenti no.

    [...]

    1. Ajax è una metodologia?
       SI
    2. Microsoft ha inventato Ajax usando IFRAME nel 1999?
       Forse, chi mai lo saprà........ 3. XmlHttpRequest è diventato lo standard?
       SI

    dimentichi di specificare che ajax fa uso di una specifica interfaccia di comunicazione.
    Se io creo un nuovo componente C++ che parla con il lato server in modo asincrono ma ha un'interfaccia differente, non posso certo appiccicargli il nome di ajax
     > 4. Microsoft ha inventato Ajax sotto il nome di XmlHttp?

       NOOOOOOOOOOOOOOOOOOOOOOOOO

    È w3c a smentirti, non io


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    sabato 23 luglio 2011 09:20
  • Io non mi capacito..............

    Adesso per cortesia mi citi il pezzo di w3c che dice che ajax è stato inventato da microsoft,
    e mi citi il pezzo che dice che ajax è una metodologia strettamente e obbligatoriamente legata a XmlHttpRequest
    (tralasciando il fatto che il termina ajax è stato coniato 4 anni dopo l'utilizzo di questa metodologia)

     


    Programamtore ASP.NET
    http://glucolo.wordpress.com

    lunedì 25 luglio 2011 07:37
  • Glauco Cucchiar wrote:

    Io non mi capacito..............

    Adesso per cortesia mi citi il pezzo di w3c che dice che ajax è stato inventato da microsoft,

    - XmlHttpRequest è il "core component" di ajax
    - XmlHttpRequest è stato inventato da MS (come anche scritto qui http://www.w3.org/TR/XMLHttpRequest/)
    - quindi non mi pare di dire cose strane quando ho affermato:
     1. "Quello che oggi viene usato come ajax deriva da xmlhttp.
    Non ho mai detto cosa facessero o non facessero i java applet, ma ajax è nato grazie a xmlhttp."
    e poi precisato:
     2. "Quello che oggi viene usato come ajax deriva da xmlhttp. Non ho mai detto cosa facessero o non facessero i java applet, ma ajax è nato grazie a xmlhttp."
     > e mi citi il pezzo che dice che ajax è una

    metodologia strettamente e obbligatoriamente legata a XmlHttpRequest (tralasciando il fatto che il termina ajax è stato coniato 4 anni dopo l'utilizzo di questa metodologia)

    http://www.w3.org/News/2007.html

    "The Web API Working Group released an updated Working Draft of The XMLHttpRequest Object. The core component of Ajax, the XMLHttpRequest object is an interface that allows scripts to perform HTTP client functions, such as submitting form data or loading data from a remote Web site. Read about the Rich Web Clients Activity."
      Ad ogni modo se non sei daccordo me ne farò una ragione, la cosa non mi interessa più di tanto.
    Non lavoro per Microsoft nè guadagno grazie a Microsoft; spendo solo quel poco di tempo disponibile per passione e quindi non ho voglia di 'bruciarlo' in discussioni sterili.
    Senza rancore ovviamente ...


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    lunedì 25 luglio 2011 09:23
  • Assolutamente senza rancore!!!!!!!!!!!

    Anche a me se sei in disaccordo con la mia visione, non mi interessa un gran che, il fatto è che questo blog lo leggono in tanti, e visto che sei MVP, magari prendono per oro colato le tue affermazioni.
    Secondo me, e secondo tanti altri, Ajax non l'ha inventato microsoft.

    È vero che XmlHttpRequest è il "core component" di ajax, ma non vuol dire che sia stato il primo, lo è diventato.
    È vero che "Quello che oggi viene usato come ajax deriva da xmlhttp", ma non vuol dire che xmlhttp sia il padre. Ancora tanta applicazioni usano alternative nate prima di xmlhttp.

    Nessun domcumento specifica la nasciata di ajax con xmlhttp, ma semplicemente che XmlHttpRequest è un'api, attualmente la core api, per fare ajax.

    La mia testi:
    Ajax tecnica - nata intorno al 1997 con utilizzo massiccio di javascript e IFRAME, perfezionata in seguito nel 2000 con l'utilizzo di ActiveX MSXML (ancora non vedo il perché ActiveX=ajax e Applet<>ajax), ed integrata nei browser negli anni successivi con XmlHttpRequest.

    AJAX Termine - Nato nel 2005 come acronimo per descrivere la tecnica utilizzando XHTML, DOM, XML, XMLHttpRequeset, Javascript (ovvero ciò che usava google)

     


    Programamtore ASP.NET
    http://glucolo.wordpress.com
    • Modificato Glauco Cucchiar lunedì 25 luglio 2011 10:02 corretta definizione
    lunedì 25 luglio 2011 10:00
  • Glauco Cucchiar wrote:

    Assolutamente senza rancore!!!!!!!!!!!

    Credo che ci legga e voglia farsi un'idea del discorso abbia materiale e link a sufficienza per approfondire.

    Ciao


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    lunedì 25 luglio 2011 11:00
  • ma secondo me ci si scrive pure un libro..........

    ha ha ha


    Programamtore ASP.NET
    http://glucolo.wordpress.com
    lunedì 25 luglio 2011 11:04