Visualizzazione dei risultati da 1 a 9 su 9
  1. #1

    Template Engine - Perché No?

    Leggendo questo thread mi sono chiesto come gestire l'html nel php senza Template engine, dato che daniele.dll e k.b hanno sconsigliato Smarty e affini per il semplice motivo che PHP è già un Template Engine.

    Ora, se eliminassimo completamente i TE, quale sarebbe il modo migliore di sostituire questi? Cioè, dovremmo avere una marea di include e cose del genere nei file?

  2. #2
    Non trovo utili i template engine perche' non aggiungono nulla a PHP. Giacche' PHP viene interpretato direttamente dal webserver, un template engine (TE per brevita') esterno non e' necessario, quindi i vantaggi di un TE si riducono fondamentalmente a due:
    1. forzare la suddivisione tra elaborazione dei dati e presentazione
    2. fornire una sintassi semplificata

    il punto 1 e' soggettivo, uno bravo sviluppatore PHP lo fa comunque. Il punto 2 e' altrettanto soggettivo: se sviluppo da solo vuol dire che il PHP lo conosco comunque, quindi non mi serve il sistema "facilitato". Inoltre semplificazione significa anche meno flessibilita', quindi perche' usare un TE quando si puo' sfruttare il PHP con tutti gli strumenti che mette a disposizione?

    Per quanto riguarda come fare senza TE, sono fermamente convinto che il modo migliore per sviluppare un'applicazione PHP - per quanto semplice - sia usare un framework, ma anche senza si puo' fare un semplice esempio di template PHP: basta smettere di mischiare codice PHP e HTML. Esempio:

    codice:
    ** esempio di codice PHP mischiato all'HTML
    ** leggibilita' scarsissima dovuta alla quantita' di virgolette e backslash
    ** impossibilita' di modificare una parte in maniera indipendente dall'altra
    <?php
    echo "<table id=\"someid\">";
    while ( $line = mysql_fetch_array() ) {
    	echo "<tr>";
    	echo "<td class=\"someclass\">".$line['campo1']." - ".strtoupper($line['campo2'])."</td>";
    	echo "</tr>";
    }
    echo "</table>";
    codice:
    ** esempio di codice PHP separato dall'HTML
    ** il codice e' molto piu' ordinato e leggibile e le due parti
    ** possono anche essere separate in due file distinti
    <?php
    $data = array();
    while ( $line = mysql_fetch_array() ) {
    	$local = array(
    		'campo1' => $line['campo1'],
    		'campo2' => strtoupper($line['campo2']),
    	);
    	$data[] = $local;
    }
    ?>
    ...
    
    <table>
    <?php foreach ( $data as $item ): ?>
    <tr>
    <td><?php echo $item['campo1']; ?></td>
    <td><?php echo $item['campo2']; ?></td>
    </tr>
    <?php endforeach; ?>
    </table>
    usando un framework la cosa viene naturale per la suddivisione tra controller/model da una parte e view dall'altra. Credo che l'abitudine a rivolgersi ai template venga solo dal fatto che tutti pensano sempre al minestrone di PHP/HTML che rende i siti illeggibili e impossibili da mantenere; se ci si abitua a separare i file di calcolo da quelli di visualizzazione, la necessita' di un TE sostanzialmente sparisce.

  3. #3
    Innanzitutto vorrei dire che io non mi reputo un bravo programmatore, cioè, se volessi creare una applicazione impegnativa ci riuscirei senza problemi, ma quello che mi manca sono proprio queste chicche. Sarà che non leggo i blog giusti?

    Ritornando al discorso dei TE, possiamo dire allora che questi, invece di semplificare il lavoro lo complicano? O magari è solo una questione di estetica e di leggibilità? Non avevo mai preso in considerazione i TE sotto quest'aspetto. Ho sempre pensato che fossero degli "Helper" nella programmazione.

    Tutto quello che hai detto quadra alla grande, ma per quanto riguarda i Framework ho letto in giro che pure questi sono degli optional nel PHP, e che parecchia gente si astiene dall'usarli per un semplice fatto di etica. In questo articolo prendevano in esempio come reputare un bravo cuoco. Diceva qualcosa del genere in grosso modo:

    "Un cuoco non si può definire bravo se compra una gustosissima torta già pronta, ma al contrario, un bravo cuoco si può definire tale solo se prepara tutto dalla base mescolando e preparando gli ingredienti."

    Più o meno diceva questo, non ricordo perfettamente, ricordo solo questa frase e devo dire che mi ha colpito, forse è per questo non uso un framework, comunque se trovo il link lo posto. Il titolo forse era "Frameworks? Pfff..." o qualcosa del genere.
    Se non sei d'accordo o se questa è solo una c*zz*t* allora possiamo affermare che non leggo i blog giusti.

  4. #4
    Premetto che fino a qualche hanno fa, dalla mia bocca, o dalle mie dita in questo caso, non avresti mai sentito dire/visto scrivere qualcosa del genere: già c'è php che fa da template engine

    Sono sempre stato un fermo sostenitore dei template engine e me li sono sempre scritti per i fatti miei fino a quando non ho fatto un pò di test di performances: mediamente un template engine aumenta il tempo di elaborazione da qualche centesimo di secondo fino a qualche decimo di secondo, senza considerare l'aumento spropositato di memoria e del processore

    In quel momento ho capito che se ne poteva anche fare a meno di un template engine inteso nel senso tradizionale: mi sono scritto un "wrapper" che simulasse le funzionalità di un template engine, aggiungendomi il supporto per la cache, ma che per effettuare l'elaborazione non facesse altro che l'inclusione (piuttosto che l'eval)

    L'inclusione è dovuta al semplice motivo che un file incluso può essere messo in cache da componenti come APC, eAccelerator, WinCache e via dicendo ... codice interpretato con eval no!

    Detto tutto questo, come ha detto k.b., tutto quello che fai con un template engine utilizzando un pseudo linguaggio lo fai normalmente anche con php ... anzi ... ti dirò di più ... certe cose con un template engine non puoi farle linearmente!

    Per farti un esempio pratico: realizzi un framework sul qualche costruisci un CMS estremamente flessibile ... per un cliente hai bisogno di far comparire informazioni aggiuntive in una pagina che devi estrarre dal database ... ma non vuoi cambiare la bussiness logic perché questo significa che dovrai farne una versione "ad-hoc" solo per il cliente avendo poi problemi con gli aggiornamenti! Che fai? Lo fai lato template engine ... ma sul template come fai a interagire con il layer del database se viene utilizzato un pseudo linguaggio? dovresti scrivere un componente per il template engine che ti mette a disposizione le funzionalità del layer di astrazione del database!
    Siccome, almeno per quanto mi riguarda, gli strumenti che uso mi devono semplificare il lavoro e non rendermelo più complicato ... utilizzare un template engine non è sempre la scelta migliore ... soprattutto se si parla di Smarty

    Qui trovi dei numeri "concreti"
    http://209.85.129.132/search?q=cache...&ct=clnk&gl=it

    Speed.

    Well, i won’t bother to attack the fact that it takes time to parse and compile smarty-code into PHP — since Smarty caches the result anyway.

    It (sadly) takes time to include and parse PHP-code, so on heavy sites you may want to keep it on a minimum. Obviously, Smarty contains a lot of code to parse and handle all it’s magic, which slows it down. Let’s make some simple tests.

    benchmark-smarty-include.php:

    Codice PHP:
    <? include_once( '/usr/share/php/smarty/libs/Smarty.class.php' ); ?>
    <? 
    print 'Hello world!'?>
    As you see, we don’t actually do anything with Smarty, we just include it. Now, lets see how fast this goes:

    The command i run: ab -c 10 -n 100 http://localhost/benchmark-smarty-include.php

    *snip*
    Requests per second: 49.23 [#/sec] (mean)
    Time per request: 203.112 [ms] (mean)
    *snip*
    And using our engine created in the examples below, benchmark-smarter-include.php:

    Codice PHP:
    <? include_once( 'smarter.php' ); ?>
    <? 
    print 'Hello world!'?>
    Again, we don’t do anything. The class just gets declared.
    Apache benchmark, with the same parameters gives us..:

    *snip*
    Requests per second: 423.35 [#/sec] (mean)
    Time per request: 23.621 [ms] (mean)
    *snip*
    Now, how about that! The script which includes Smarty uses 179.491 milliseconds more than our small template engine which uses PHP! Thats not good..

    The tests was runned on a basic linux+apache2+php5 installation (my laptop), without any accelerator.
    Detto tutto questo, usare direttamente gli include non è molto conveniente, piuttosto usare una classe che si occupi di gestire le variabili accessibili dal template, effettuare i caricamenti ed infine gestire la cache lo è parecchio
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  5. #5
    Originariamente inviato da daniele_dll
    Premetto che fino a qualche hanno fa, dalla mia bocca, o dalle mie dita in
    Oh meno male che sei rinsavito
    L'articolo benedetto

    http://massassi.com/php/articles/template_engines/


    Without faith, nothing is possible. With it, nothing is impossible
    http://ilwebdifabio.it

  6. #6
    Originariamente inviato da sandro010489
    Tutto quello che hai detto quadra alla grande, ma per quanto riguarda i Framework ho letto in giro che pure questi sono degli optional nel PHP, e che parecchia gente si astiene dall'usarli per un semplice fatto di etica. In questo articolo prendevano in esempio come reputare un bravo cuoco. Diceva qualcosa del genere in grosso modo:

    "Un cuoco non si può definire bravo se compra una gustosissima torta già pronta, ma al contrario, un bravo cuoco si può definire tale solo se prepara tutto dalla base mescolando e preparando gli ingredienti."

    Più o meno diceva questo, non ricordo perfettamente, ricordo solo questa frase e devo dire che mi ha colpito, forse è per questo non uso un framework, comunque se trovo il link lo posto. Il titolo forse era "Frameworks? Pfff..." o qualcosa del genere.
    Se non sei d'accordo o se questa è solo una c*zz*t* allora possiamo affermare che non leggo i blog giusti.
    Mi sembra decisamente una vaccata. Volendo rimanere nell'esempio culinario, un framework non e' affatto una torta gia' pronta ma e' l'equivalente di avere le cipolle gia' tagliate e gli ingredienti gia' pesati. Un cuoco per essere bravo deve per forza sbucciarsi da solo le cipolle ogni singola volta? Deve per forza mettere la farina sulla bilancia personalmente? O deve solo fare dei piatti buoni usando gli ingredienti giusti nel modo giusto?

    Un framework non fa altro che prepararti gli ingredienti in modo piu' comodo, per evitare che tu debba rifare le stesse noiose cose ogni singola volta. Per il resto un framework da solo non fa niente.

    Ovviamente i framework sono "optional" e ovviamente aggiungono carico di calcolo e di memoria, ma il bilancio alla fine e' comunque positivo, e di molto. Un'applicazione PHP non e' come un driver low level scritto in C: le performance non sono da trascurare, ma guadagnare 2 centesimi di secondo di esecuzione quando comunque devi tenere conto della latency di rete, del fatto che una pagina web e' composta anche da decine di richieste diverse, non fa la differenza quanto avere una base di codice ben strutturata, ordinata, sicura e facilmente mantenibile.

    A meno che la tua fonte non intendesse CMS invece che framework, forse ti conviene cambiare blog.

  7. #7
    A quanto pare è proprio sconveniente usare i TE.

    @k.b.
    Mi sa davvero che devo cambiare blogs... Magari se ne conoscete di migliori postate pure... A me mancano queste chicche. Mi manca un blog del genere da seguire costantemente.

    Grazie a tutti per i chiarimenti raga. Come sempre gentili e disponibili.

  8. #8
    Leggo molti articoli di vari blog, ma piu' che altro occasionalmente come risultato di ricerche su qualche argomento specifico. L'unica fonte che seguo costantemente e' http://stackoverflow.com

  9. #9
    Originariamente inviato da k.b
    ... L'unica fonte che seguo costantemente e' http://stackoverflow.com


    consiglio pure io

    cmq, per riassumere ... non è sbagliato usare un Template Engine ... è sbagliato usare un Template Engine che vuole reinventare il php a modo suo per "semplificare"

    probabilmente se si tratta di sostituire variabili, un template engine con un suo pseudo-linguaggio semplifica ... ma fine li ... già gestire cicli all'interno del template diventerebbe più complesso, però non parlare poi delle condizioni e via dicendo

    Un TE che funge da wrapper attorno ad eval/include è la soluzione più efficiente e nel contempo più flessibile: non toglie niente ma nel contempo permette di automatizzare le funzionalità con semplicità ... ad esempio se si vogliono gestire più temi con un wrapper, invece di richiamare gli include direttamente, si ha maggior controllo sulla situazione (altrimenti in ogni include andrebbe inserita la variabile che indica il nome del tema, un gran casino) ... o ancora tramite un wrapper è possibile caricare un Helper del template che si occupi di implementare funzionalità utilizzate dal template stesso ... e via dicendo

    Probabilmente, il modo più sicuro di tutto ciò è usando quest'estensione http://www.php.net/manual/en/book.runkit.php solo che personalmente non l'ho mai usata perché non penso sia supportata da APC, eAccelerator e simili
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

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.