Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1
    Utente di HTML.it
    Registrato dal
    Dec 2008
    Messaggi
    505

    delucidazione sull'effettivo comportamento dell'output in php

    salve, leggendo una guida su html.it (la potete trovare quì) ho effettivamente appurato (cosa che non sapevo hehe) che l'invio dei dati che php elabora/genera viene inviato in "real-time" al client. io credevo che prima generasse tutta la pagina, poi inviasse progressivamente il contenuto al client (cosa che succede quando invece si utilizza la bufferizzazione).

    ora, nella guida (per esempio) c'è scritto che a ogni echo corrisponde una connessione TCP/IP per l'invio della stringa.

    quello che mi chiedo è : ma per gli altri dati stampati/inviati al client che non utilizzano la echo o print? per esempio del semplice codice html incluso tra dei marcatori php :
    codice:
    ?>
        ciao sono una stringa html contenuta dentro al body
    <?
    anche quì l'invio è in "real-time"? s'inviano i dati all'eseguzione di ogni riga? o come avviene il trasferimento?

    cordiali saluti

  2. #2
    Mai sentita sta cosa.

  3. #3
    Utente di HTML.it
    Registrato dal
    Mar 2007
    Messaggi
    143

    Re: delucidazione sull'effettivo comportamento dell'output in php

    Originariamente inviato da markzzz
    salve, leggendo una guida su html.it (la potete trovare quì) ho effettivamente appurato (cosa che non sapevo hehe) che l'invio dei dati che php elabora/genera viene inviato in "real-time" al client. io credevo che prima generasse tutta la pagina, poi inviasse progressivamente il contenuto al client (cosa che succede quando invece si utilizza la bufferizzazione).

    ora, nella guida (per esempio) c'è scritto che a ogni echo corrisponde una connessione TCP/IP per l'invio della stringa.

    quello che mi chiedo è : ma per gli altri dati stampati/inviati al client che non utilizzano la echo o print? per esempio del semplice codice html incluso tra dei marcatori php :
    codice:
    ?>
        ciao sono una stringa html contenuta dentro al body
    <?
    anche quì l'invio è in "real-time"? s'inviano i dati all'eseguzione di ogni riga? o come avviene il trasferimento?

    cordiali saluti
    Sì é come se ci fosse un echo.
    Se ad esempio in uno script php del genere metti un timer che inizia al principio dello script e stampa il time alla fine, noterai che questo tempo finale dipende dalla velocitá della tua connessione, ovvero non é il tempo di esecuzione del codice lato server, ma il tempo che ci impiega per elaborare e printare sul browser.

  4. #4
    Utente di HTML.it L'avatar di dottwatson
    Registrato dal
    Feb 2007
    Messaggi
    3,012

    Re: delucidazione sull'effettivo comportamento dell'output in php

    Originariamente inviato da markzzz
    salve, leggendo una guida su html.it (la potete trovare quì) ho effettivamente appurato (cosa che non sapevo hehe) che l'invio dei dati che php elabora/genera viene inviato in "real-time" al client. io credevo che prima generasse tutta la pagina, poi inviasse progressivamente il contenuto al client (cosa che succede quando invece si utilizza la bufferizzazione).

    ora, nella guida (per esempio) c'è scritto che a ogni echo corrisponde una connessione TCP/IP per l'invio della stringa.

    quello che mi chiedo è : ma per gli altri dati stampati/inviati al client che non utilizzano la echo o print? per esempio del semplice codice html incluso tra dei marcatori php :
    codice:
    ?>
        ciao sono una stringa html contenuta dentro al body
    <?
    anche quì l'invio è in "real-time"? s'inviano i dati all'eseguzione di ogni riga? o come avviene il trasferimento?

    cordiali saluti
    si è così, infatti un errore php spezza la pagina in cui si verifica, mostrando a video tutto ciò che è stato eleaborato fino all'errore stesso.

    è per questo che è sempre buona abitudine, quando c'è un errore php non limitarsi a dire 'mi da pagina bianca', ma vedere realmente il codice HTML generato fino a quel momento. spesso gli errori si verificano in zone del foglio in cui lo style omette la visualizzazione del messaggio di errore.
    Non sempre essere l'ultimo è un male... almeno non devi guardarti le spalle

    il mio profilo su PHPClasses e il mio blog laboweb

  5. #5

    Re: Re: delucidazione sull'effettivo comportamento dell'output in php

    Originariamente inviato da dottwatson
    si è così, infatti un errore php spezza la pagina in cui si verifica, mostrando a video tutto ciò che è stato eleaborato fino all'errore stesso.

    è per questo che è sempre buona abitudine, quando c'è un errore php non limitarsi a dire 'mi da pagina bianca', ma vedere realmente il codice HTML generato fino a quel momento. spesso gli errori si verificano in zone del foglio in cui lo style omette la visualizzazione del messaggio di errore.
    Ma questo non ha alcun legame col comportamento descritto. Il fatto che si interrompa e ti mostri un ouput parziale non significa che te lo mandi un po' per volta: puo' elaborare tutto (fino all'errore) e inviare solo alla fine.

    Infatti esiste la funzione http://uk.php.net/flush

  6. #6
    Utente di HTML.it L'avatar di dottwatson
    Registrato dal
    Feb 2007
    Messaggi
    3,012

    Re: Re: Re: delucidazione sull'effettivo comportamento dell'output in php

    Originariamente inviato da k.b
    Ma questo non ha alcun legame col comportamento descritto. Il fatto che si interrompa e ti mostri un ouput parziale non significa che te lo mandi un po' per volta: puo' elaborare tutto (fino all'errore) e inviare solo alla fine.

    Infatti esiste la funzione http://uk.php.net/flush
    flush non fa altro che raccogliere il contenuto di un precedente output buffer attivato in precedenza.. non output buffer, no flush...

    are you agree?
    Non sempre essere l'ultimo è un male... almeno non devi guardarti le spalle

    il mio profilo su PHPClasses e il mio blog laboweb

  7. #7
    No. Prova la differenza tra

    Codice PHP:
    foreach ( range(15) as $num ) {
        echo 
    $num;
        
    sleep(1);

    e

    Codice PHP:
    foreach ( range(15) as $num ) {
        echo 
    $num;
        
    flush();
        
    sleep(1);


  8. #8
    Utente di HTML.it
    Registrato dal
    Dec 2008
    Messaggi
    505
    bhè da quanto ho capito, se usi un flush (e relativo buffer) il comportamento di invio non è in "real time", ma "flusha" solo quando glielo dici te (come k.b ha descritto, fermo restando che secondo me viene realmente bufferizzato solo se inizializzi il tutto con ob_start).

    non capivo come venisse inviato il codice html tra <? e ?>.
    quindi a ogni apertura-chiusura dei marcatori php viene eseguito un "send sostanzialmente".
    Originariamente inviato da kiboo
    Sì é come se ci fosse un echo.
    Se ad esempio in uno script php del genere metti un timer che inizia al principio dello script e stampa il time alla fine, noterai che questo tempo finale dipende dalla velocitá della tua connessione, ovvero non é il tempo di esecuzione del codice lato server, ma il tempo che ci impiega per elaborare e printare sul browser.
    ah quindi una volta elaborato lato server lo invia, aspetta che effettivamente sia andato a buon fine, e poi continua l'elaborazione? credevo che i due processi andassero in parallelo, indipendentemente l'uno dall'altro...

    comunque dovrò rivedere molto del mio codice, perchè apro molto spesso <? e ?> per del semplice codice html che può essere opportunamente formattato in altro modo.

    altra questione : ma e per le immagini per esempio? se a un div associo un foglio di stile con relativo background-image come si comporta? carica prima l'html e poi le relative immagini? oppure le carica in parallelo?

  9. #9

    Re: Re: delucidazione sull'effettivo comportamento dell'output in php

    messaggio cancellato

  10. #10
    messaggio cancellato

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 © 2025 vBulletin Solutions, Inc. All rights reserved.