Visualizzazione dei risultati da 1 a 8 su 8
  1. #1
    Utente di HTML.it
    Registrato dal
    May 2009
    Messaggi
    192

    scrittura del codice:come è meglio?

    Per visualizzare in un form i dati che ho ad es. in 2 variabili $var1, $var2 posso scrivere il form in 2 modi.
    Uno che apre il tag php una volta sola, l'altro tante volte quante sono le variabili.

    Modo 1

    Codice PHP:
    <?php
    $content
    =echo "<form action=\"salva.php\"> 
    <label for=\"abc\">ABC:<input name=\"abc\" id=\"abc\" value=\"
    $var1\"></label> 
    <label for=\"def\">DEF:<input name=\"def\" id=\"def\" value=\"
    $var2\"></label> 
    <input type=\"submit\" name=\"submit\" value=\"Submit\">
    echo 
    $content;
    ?>
    Modo 2
    Codice PHP:
    <form action="salva.php">
    <label for="abc">ABC:<input name="abc" id="abc" value="<?php echo $var1;?>></label> 
    <label for="def">DEF:<input name="def" id="def" value="<?php echo $var2;?>></label> 
    <input type="submit" name="submit">
    Quale è preferibile e perchè?

  2. #2
    Utente di HTML.it L'avatar di neroux
    Registrato dal
    Aug 2009
    Messaggi
    1,973
    Assolutamente e senza dubbio la seconda versione.

    www.sitemeer.com » Quando un sito pare irraggiungibile

    Se ti piace ci puoi trovare anche su Facebook

  3. #3
    Utente di HTML.it
    Registrato dal
    May 2009
    Messaggi
    192
    Mi potresti spiegare perchè la seconda versione è meglio della prima? Aprendo e chiudendo il tag php tante volte? E' proprio avere un'idea del perchè il succo di questo post.

  4. #4
    Utente di HTML.it L'avatar di neroux
    Registrato dal
    Aug 2009
    Messaggi
    1,973
    Non c'entra quante volte li apri.
    Secondo me è evidente il perché. La seconda versione è diecimila volte più leggibile dell'altra.

    PHP in pratica è un template engine, e quindi dovrebbe essere usato come ciò. Vuol dire che il codice PHP va immerso nel HTML, non vice versa. E' proprio questo la bellezza e il vantaggio di PHP in confronto a Perl per esempio.

    www.sitemeer.com » Quando un sito pare irraggiungibile

    Se ti piace ci puoi trovare anche su Facebook

  5. #5
    Utente di HTML.it L'avatar di Kups
    Registrato dal
    May 2013
    Messaggi
    20
    Fai un utilizzo di più risorse del dovuto nel primo modo.
    Mi spiego: nel primo caso stai dicendo al server di processare quella stringa e di stamparla, per fare ciò la allocherà nella ram.

    Mettiamo che sono 100byte di informazioni, quindi per 100 utenti che richiedono quella pagina in contemporanea il server ne usa 10000 per processare l'informazione mentre, se ti limitassi a stampare solo i 10byte di dati realmente utili, -sempre con i famosi 100 utenti d'esempio- ti ritroveresti a far utilizzare al server solo 1000byte. (Ovviamente è un esempio in linea di massima, ci sono poi diversi fattori che intervengono all'atto pratico in un tipico sistema server odierno)

    In sostanza la soluzione migliore è quella di innestare solo l'indispensabile per l'output che ti occorre da php e se temi che il caos cominci a diffondersi nel tuo codice, ricorda sempre di separare come si deve la logica di lavoro da quella visiva ( possibilmente infilandole in due file ben distinti ) e donerai nuovo equilibrio alla forz.. al sorgente

  6. #6
    Utente di HTML.it
    Registrato dal
    May 2009
    Messaggi
    192
    per Kups....
    Ho capito perfettamente quello che mi hai detto.
    Il mio dubbio nasceva dal fatto che mi sono detto:
    Il php è un linguaggio interpretato. Vediamo il modo 2. Il server incomincia a leggere sequenzialmente...da sinistra a destra....incontra HTML...quindi va avanti...quando incontra il tag <?php scomoda l'interprete... legge la variabile e chiude l'interprete....va avanti..ecco di nuovo html...poi incontra ancora il tag <?php riapre di nuovo l'interprete legge la seconda variabile...richiude...ed ho detto: se in una form ho 15 dati da far vedere allora fa questo lavoro 15 volte e mi sembrava che il server si stressasse. Per di più, venendo al tuo ragionamento, se queste 15 volte le moltiplichiamo per i 100 utenti..alla fine apre e chiude l'interprete 1500 volte....ma probabilmente è molto più importante valutare il consumo di ram che di processore....

  7. #7
    Utente di HTML.it L'avatar di Kups
    Registrato dal
    May 2013
    Messaggi
    20
    Non è proprio così: l'interprete legge da sinistra a destra tutto il sorgente, è vero, ma non converte al volo ogni blocco di php che incontra strada facendo.

    Tutta la struttura di php letta nel file viene estrapolata, viene verificata e, se la sintassi risulta essere valida ( da qui il fatto che è ingrado di dirti immediatamente il codice è invalido, anche se prima del punto di invalidità metti uno sleep(10) ), l'interprete provvede a convertirlo in una sorgente c++ altamente ottimizzato, ed è a quel punto che il codice viene eseguito.

    In seguito i vari blocchi di php nel sorgente originario vengono rimpiazzati con l'eventuale output da loro prodotti.

    Si parla di un operazione che ormai PHP riesce a fare a regola d'arte e con tempistiche e risorse veramente irrisorie.


    -- Off Topic:
    Ad ogni modo, in generale, usare eccessivamente la cpu è il male: non sto estremizzando dal lato opposto, ma se realizzi un applicazione che impegna la cpu già di suo immagina la catastrofe che molti utenti possano portare avviando quel medesimo processo.
    L'importante è trovare un buon equilibrio tra l'uso di cache, l'impiego di memoria virtuale, e cpu.

    La regola d'oro è che se puoi risparmiarti una quantità non indifferente di operazioni mediante l'archiviazione di un dato, fallo. A te poi stabilire se si tratta di un dato frequentemente richiesto e ti converebbe quindi mantenerlo in RAM oppure piazzarlo sull'hard disk.

    Comunque è un discorso generico, che col caso da te esposto in questa discussione ha poco a che vedere.
    -- Fine OT

  8. #8
    Utente di HTML.it
    Registrato dal
    Oct 2009
    Messaggi
    292
    Aggiungerei solo che in caso di numerosi output farei uso di ob_start()

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.