Visualizzazione dei risultati da 1 a 10 su 10
  1. #1
    Utente di HTML.it
    Registrato dal
    Dec 2009
    Messaggi
    5

    gestire chiamate XMLHTTPrequest con Ajax

    Ciao a tutti,
    non riesco a fare una cosina che forse, in realtà è semplicissima. Vediamo se qualcuno può aiutarmi.

    Semplifico al massimo l'esempio.
    Immaginate di dover creare un semplice contatore. Visualizzo sullo schermo i numeri da 1 a 100. Ovviamente si può fare senza scomodare Ajax, ma io voglio farlo in questo modo, perchè una volta appresa la tecnica posso utilizzarla per situazioni più complesse.

    Quindi... click su un bottone, associato ad un gestore di evento che richiama una funzione javascript. Questa funzione JS invia N richieste ad una procedura PHP, fino a quando questa non restituisce il numero 100.
    La procedura è molto semplice, non fa altro che incrementare un contatore e restituirlo.
    Di seguito il codice:

    Codice PHP:

    <?php

    class contatore
    private 
    $counter
    public function 
    __construct(){ 
          
    $this->counter 0

    public function 
    incrementa(){ 
          
    $this->counter = ++$this->counter
          return 
    $this->counter



    header ("Content-Type: text/plain"); 

    if(!
    $countObj)  // evidentemente questo controllo non serve a nulla
         
    $countObj = new contatore(); 

    $progress $countObj->incrementa();

    echo (string)
    $progress

    ?>
    il problema è che ad ogni chiamata in realtà sto instanziando un nuovo oggetto "contatore" ($countObj), pertanto ad ogni chiamata questo script mi restituirà sempre 1.
    COme fare a gestire questa cosa? Esiste un modo per gestire le chiamate XMLHTTPRequest con PHP? Non sono ancora molto esperto di PHP 5, ma con altri llinguaggi sono riuscito.
    Vorrei applicare la stessa tecnica utilizzando PHP.

    Any suggestions?
    Grazie

  2. #2
    Utente di HTML.it L'avatar di luca200
    Registrato dal
    Apr 2002
    Messaggi
    4,120
    Dal punto di vista del server, una chiamata "di tipo Ajax" non è diversa dalle altre.
    Ergo, se ti serve mantenere dei dati, devi metterli in sessione, o comunque dove possano essere conservati (su un db, su un file, su un cookie ecc)

  3. #3
    Utente di HTML.it
    Registrato dal
    Dec 2009
    Messaggi
    5
    Sessione!!!! come ho fatto a non pensarci.
    Ci proverò, funzionerà sicuramente. I cookies per una cosa del genere con credo siano indicati.

    In ogni modo, ero curioso di sapere se si riusciva a fare in altro modo.
    Ho realizzato giusto oggi uno scripr in Ruby, si riesce a fare benissimo senza scomodare sessioni, cookies e quant'altro.
    Però naturalmente non sono un esperto ruby (me lo sto studiando un pochino) e lo script l'ho praticamente copiato. Quindi non so se, da linguaggio di alto livello ad oggetti quale è, in realtà non stia anche lui, a mia insaputa, utilizzando qualche variabile di sessione.

    Comunque lo script Ruby è una cosa del genere:

    Codice PHP:
       server.mount_proc('/nomeProcedura') do |requestresponse
      
      
    response['Content-Type'] = 'text/html'  

      
    progress += progress
      response
    .body progress.to_s   <<< risposta definitiva  

    end 
    Praticamente se nel codice implemento un contatore, ogni volta che viene richimata la procedura "nomeProcedura" tramite Ajax, lo scripr di Ruby "NON" crea una nuova istanza dell'oggetto, quindi la variabile "progress" viene incrementata ad ogni chiamata.
    Qualcuno sa cosa succede dietro le "quinte" di questo codice?

    Grazie comunque per la risposta

  4. #4
    Utente di HTML.it
    Registrato dal
    Feb 2010
    Messaggi
    1
    Ciao..

    Se vuoi un metodo semi alternativo, puoi provare a creare una classe singleton...
    Singleton significa che può esserci una sola istanza nella tua applicazione...

    Ti riporto un esempio..

    Codice PHP:
    <?php


    class Singleton {

            
    /**
             * attributo statico "Istanza della classe"
             */
        
    private static $instance;

            
    /**
             * il mio counter
             */
        
    private $counter;

            
    /**
             * costruttore di classe PRIVATO
             */
        
    private function __construct() {
            
    $this->counter 0;
        }

            
    /**
             * funzione che richiama l'istanza della classe
             */
        
    public static function getInstance(){
                   
    //controllo se non è definita l'istanza
            
    if(Singleton::$instance == null) {
                            
    //creo l'istanza
                
    Singleton::$instance = new Singleton();
            }
                    
    //ritorno l'istanza
            
    return Singleton::$instance;
        }
        
            
    /**
             * funzione di incremento
             */
        
    public function increaseCounter(){
            
    $this->counter++;
        }

            
    /**
             * Getter
             */
        
    public function getCounter(){
            return 
    $this->counter;
        }

            
    /**
             * Setter
             */
        
    public function setCounter($counter){
            
    $this->counter $counter;
        }
    }

    Dove mi serve posso richiamare la classe in questo modo..
    Anche all'interno di dichiarazione di funzioni..

    Codice PHP:

    $sing 
    Singleton::getInstance();
    $sing->increaseCounter();

    echo 
    "il counter vale : " $sing->getCounter();

    function 
    incrementaSingleton(){
        
    $singeltonVariabileLocale Singleton::getInstance();
        
    $singeltonVariabileLocale->increaseCounter();
    }

    incrementaSingleton();

    echo 
    "
    ora il counter vale : " 
    $sing->getCounter();

    ######## OUTPUT ##########
      
    il counter vale 1
      ora il counter vale 
    2
    # ####################### 

    Cosi implementata la singleton permette di avere la stessa istanza ovunque a ogni chiamata di pagina (PHP reinizializza tutto a ogni nuova richiesta).. Andando a modificare il metodo getInstance si può però tenere la vibilità di sessione o addirittura di applicazione usando le variabili speciali...

    Esempio

    Codice PHP:

    <?php

    session_start
    ();

    class 
    Singleton {

    ......

            
    /**
             * funzione che richiama l'istanza della classe
             */
        
    public static function getInstance(){
                   
    //controllo se non è definita l'istanza
            
    if(Singleton::$instance == null) {
                            
    //creo l'istanza
                            
    if($_SESSION['Singleton'] == null){
                                  
    Singleton::$instance = new Singleton();
                                  
    $_SESSION['Singleton'] = Singleton::$instance;
                            }

                            
    Singleton::$instance =  $_SESSION['Singleton'];
            }
                    
    //ritorno l'istanza
            
    return Singleton::$instance;
        }

    ...
    }
    Questo tipo ti classi sono molto comode per scrivere codice più pulito senza usare variabili globali importate con global etcc...

    Trovi anche una guida su questo sito se non erro..

    Ciaooo

  5. #5
    Utente di HTML.it L'avatar di bubi1
    Registrato dal
    Dec 2009
    Messaggi
    1,230
    Non c'e' nessun dietro le quinte, sono due cose diverse (e non mi riferisco ai linguaggi di programmazione).
    Semplicemente tu fai partire il processo ruby. Ruby fa partire il suo modulo webrick. Webrick resta in ascolto, mappa una url ad un servlet astratto, ma questo e' irrilevante. Cio' che e' importante, e' il fatto che la tua variabile e' nella tabella di memoria di ruby, e rimane finche' il processo e' in esecuzione.

    Puoi replicare esattamente lo stesso comportamento anche in php.

  6. #6
    Utente di HTML.it
    Registrato dal
    Dec 2009
    Messaggi
    5
    Il metodo di niscio con la Class singleton mi piace parecchio. Non conoscevo, si ha sempre da imparare. Grazie infinite.

    Invece non riesco a capire cosa intende bubi1 quando dice che la stessa cosa del codice Ruby si può implementare anche in PHP. In che modo? C'è un ulteriore metodo?

    Grazie a tutti per le info, sono utilissime
    Ciao

  7. #7
    Utente di HTML.it L'avatar di bubi1
    Registrato dal
    Dec 2009
    Messaggi
    1,230
    Singleton o no, sempre di sessione si tratta.

    Per il resto provo a spiegarmi meglio. Non stiamo parlando di metodi, ma di scenari web.

    Scenario che hai prensentato tu: il programma in esecuzione e' ruby, chiamiamolo programma parent. Il parent si mette in ascolto su una porta, attraverso webrick.
    Tu fai una richiesta http, e il servlet incrementa una variabile. Questa variabile e' inserita nella memoria del parent, e sara' viva finche il parent e' in esecuzione. Quindi sara' viva anche alla richiesta successiva.

    Scenario apache/php: il programma in esecuzione e' apache, e in ascolto su una porta e' apache (parent). Tu fai una richiesta http: apache fa partire un child per servire quella richiesta. Tu imposti una variabile con php, e quella variabile sara' viva solo durante la tua richiesta, perche' alla richiesta successiva, apache fara' partire un altro child.
    (In realta' non e' proprio cosi', ma ho semplificato tutto al massimo per rendere l'idea)

    In un ambiente web di produzione, multiutente, lo scenario 1 non viene mai utilizzato: Pensa a cosa succederebbe se tu assegnassi la variabile admin=1, e questa variabile fosse viva ad ogni richiesta
    Nel mondo reale, webrick si usa solo per sviluppo, in produzione si usa un server vero come apache, lighthttp, o quant'altro, e ruby via cgi/fastcgi. O variazioni tipo apache+mongrel, apache+mod_ruby, etc.

    Ps: e quando dicevo che si puo' replicare in php, non mi riferivo a metodi, ma al fatto che puoi fare lo scenario1 anche in php. Basta eseguire php dalla riga di commando, metterlo in ascolto su una porta, e servire richieste senza chiudere la porta dopo ognuna di loro.

  8. #8
    Utente di HTML.it L'avatar di luca200
    Registrato dal
    Apr 2002
    Messaggi
    4,120
    Originariamente inviato da bubi1
    In un ambiente web di produzione, multiutente, lo scenario 1 non viene mai utilizzato: Pensa a cosa succederebbe se tu assegnassi la variabile admin=1, e questa variabile fosse viva ad ogni richiesta
    Succederebbe quello che un programmatore consapevole sarebbe capace di far succedere. Esattamente come in ambiente Java, in cui esiste lo scope Application.
    Io ruby non lo conosco, ma in php questo non è possibile, a meno di novità di cui qualcuno si sia scordato di farmi partecipe. Quindi si torna al punto iniziale: sessioni o equivalente

  9. #9
    Utente di HTML.it
    Registrato dal
    Dec 2009
    Messaggi
    5
    perfetto, mi hai chiarito le idee. Adesso è tutto limpido come il mar di Sardegna (scorie nucleari a parte).
    Siete grandi, compliementi

  10. #10
    Utente di HTML.it L'avatar di bubi1
    Registrato dal
    Dec 2009
    Messaggi
    1,230
    Originariamente inviato da luca200
    Succederebbe quello che un programmatore consapevole sarebbe capace di far succedere. Esattamente come in ambiente Java, in cui esiste lo scope Application.
    Io ruby non lo conosco, ma in php questo non è possibile, a meno di novità di cui qualcuno si sia scordato di farmi partecipe. Quindi si torna al punto iniziale: sessioni o equivalente
    Beh si, ma come dicevo, ho semplificato tutto Cmq, non contestavo le sessioni, contestavo il discorso: in ruby si puo' e' in php no, perche' erano 2 scenari diversi, non limitazione del linguaggio..

    Per quanto riguarda php, lo so che mi spiego a volte di merda, ma intendevo di aprire dei socket in ascolto senza apache e servire delle richieste. E' la stessa cosa che fa ruby con webrick.
    E' inutile, ma e' la stessa cosa.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.