Template Engine - Usare codice php nei template o no?

**jan267** · 13-04-2008, 12:03

Ma infatti il punto è proprio questo.
Il codice php deve stare fuori dal template, però capita che possa essere comodo avere delle piccole funzioni all'interno del template.
Faccio un esempio: il classico

Codice PHP:


($ciao == true ? 'ciao' : 'no')

può essere comodo in un template...

**whisher** · 13-04-2008, 12:03

Segnalo che con php nel template
se il grafico combina qualche casino
hai la possibilità di bloccare l'esecuzione
dello script con gli altri metodi non saprei

Oltre hai templates ci sarebbero pure i
widgets generati o con le dom functions
e con i vari tags devo dire che non sono
male per la separazione logica/presentazione
ma qui il grafico scappa

Ps

Una cosa veramente cool sarebbe poter
utilizzare xslt ma per adesso ...........
per quanto ne so ci sono ancora dei problemi

**daniele_dll** · 13-04-2008, 12:08

Originariamente inviato da andr3a
non è esoso se hai un JIT ONCE del template file ... da farci una ragionata sopra, nel frattempo mi documenterò in merito

smarty ha un, se lo vogliamo chiamare, compilatore JIT, che "compila" il pseudo linguaggio in PHP e poi lo include, ma ti assicuro che è lento ... se poi non abiliti la cache dei file su disco è da suicidio assoluto

**andrea.paiola** · 13-04-2008, 12:09

Originariamente inviato da whisher
Una cosa veramente cool sarebbe poter
utilizzare xslt ma per adesso ...........
per quanto ne so ci sono ancora dei problemi

PHPTAL

già che ci sono vi segnalo invece i template in Yaws/Erlang
http://yaws.hyber.org/simple.yaws
http://yaws.hyber.org/dynamic.yaws

un'occhiata più approfondita nel manuale http://yaws.hyber.org/doc.yaws

**daniele_dll** · 13-04-2008, 12:11

Originariamente inviato da whisher

Codice PHP:


<?php foreach ($resultset as $result) : ?>

  <h2>[url="<?php echo $result->href; ?>"]<?php echo $result->title; ?>[/url]</h2>

  <span class="date"><?php echo $result->published; ?></span>

  

<?php echo $result->excerpt; ?></p>

<?php endforeach; ?>



<p class="pager">

  <?php foreach ($pagination as $link) : ?>

    [url="<?php echo $link->href; ?>"]<?php echo $link->index; ?>[/url]

  <?php endforeach; ?>

  [url="<?php echo $create; ?>"]create[/url]

</p>

prendo in esempio solo sto pezzo ... tu li come ci arrivi? questo "brandello" di codice sta insieme al codice che estrae i dati e li prepara (ergo estrae e prepara $resultset e $pagination)? perché se si è un gran gran gran casino ... se no è esattamente quello che voglio fare io ovvero carico esternamente i template (questo brandello può essere un esempio), li spezzo in base ai blocchi e poi li parso con eval

**jan267** · 13-04-2008, 12:15

Se si parsa tutto con eval si creano un sacco di problemi con apici ecc...
Se invece si usa preg_replace con il modificatore "e" si parsa solo una piccolissima porzione (non con eval) di codice e il risultato parsato lo si ottiene con "return"...

**andr3a** · 13-04-2008, 12:20

Originariamente inviato da whisher
Una cosa veramente cool sarebbe poter
utilizzare xslt ma per adesso ...........
per quanto ne so ci sono ancora dei problemi

nessun problema, in cocoon xslt è pane quotidiano ... ma dopo averci lavorato 4 mesi, mi sono accorto che richiede più competenza o esperienza xslt che php (ovveri si impara prima il secondo del primo)

qualunque grafico incompetente, giustamente o meno, è in grado di capire che {Persona} è l'informatione che contiene {Persona.Nome} e/o {Persona.Info} escrivere queste informazioni in un layout (x)html è molto più semplice che conoscere XML + XSLT + XPath + CSS + Parte Server side perchè per trasformare devi sapere cosa + possibilità di creare macro nello strato intermedio tra il linguaggio server e l'output finale

codice:

[loop:foreach Persone as Persona]
    {Persona.Nome}
    [nested:foreach range(0, Persona.Anni.Length) as i]
        {Persona.Anni[i]}
    [/nested]
[/loop]

non so ... forse sono un visionario, ma di base quello che si fa in un template è sempre la stessa cosa, un loop per liste di info, un if con eventuale else ... fine.

Il template riceve dati gestiti da un'altra parte ... avere il PHP dentro il template significa che il grafico potrebbe far veramente danni ... io la vedo così

grafico - ciao programmatore, in questa pagina dovrei presentare la scheda utente con nome, cognome, anni e foto
prog - Ok, ti passo una variabile {User} che contiene Name Surname Age e Image
grafico - bene, mi serve anche un numero random e il totale visite per questo profilo
prog - Ok, ti aggiungo Visited nello User, e per il numero random usa {rand()}

... boh, probabilmente sono un visionario, scusate il delirio

**andrea.paiola** · 13-04-2008, 12:24

Originariamente inviato da andr3a et modificato

grafico - ciao programmatore, in questa pagina dovrei presentare la scheda utente con nome, cognome, anni e foto
prog - Ok, ti passo una variabile $User che contiene Name Surname Age e Image
grafico - bene, mi serve anche un numero random e il totale visite per questo profilo
prog - Ok, ti aggiungo Visited nello $User, e per il numero random usa rand()

boh non vedo tutte sta differenza, per uno che non conosce PHP... anzi c'è lo svantaggio che dovrai scriverci la documentazione su questo "nuovo" pseudolinguaggio per template

conoscete ErlTL ?

**daniele_dll** · 13-04-2008, 12:28

Originariamente inviato da jan267
Ciao a tutti,
secondo me usare il codice php in un template è davvero un'idea pessima.
La soluzione migliore (che fra l'altro io utilizzo nel template engine che ho creato io) è quella suggerita da andr3a.
Ossia emulare il codice php e poi trasformarlo... forse è leggermente più lento ma la sicurezza è di sicuro maggiore!
.
.
.

un pò quello che fa il lentissimo smarty e tanti altri come lui, però giusto una domanda: se devo lavorare con un, ad esempio, database oracle? o un webservice? come aggiri la cosa?

devi prevedere TUTTE queste situazioni a livello di template engine o permettere la possibilità di richiamare funzioni/metodi, includere file e cosi via rendendo infinitamente complesso il template engine, rendendolo soggetto potenzialmente a maggiori bug e vulnerabilità

inoltre con questo sistema il codice del template non è direttamente editabile con un qualsiasi WSYWIG che supporti PHP (è c'è ne sono tanti) perché dovrebbe supportare il tuo meta linguaggio nativamente

Hai pienamente ragione!
Ma difatti lo pseudo-code è da usare in modo limitato!
Può essere utile ma è evidente che la maggior parte del codice php non deve andare in un template, ma nella pagina che lo richiama.

Per quanto riguarda la giustificata "ignoranza" del grafico, è un problema che ci sarà sempre.

quindi se io devo integrare i dati che il modulo/addon/componente mi passa per una specifica pagina con un webservice o con un database diverso o ancora con dei file xml sul disco devo andare a modificare la logica del componente ottenendo cosi due versioni diverse, o un'unica versione molto più complessa? no grazie

Però il template riduce molto il rischio di manomissioni...

non riduce affatto nessun rischio: se possono modificare il template vuol dire che via ftp o via php, per qualche pagina fallata, hanno accesso ai file e a quel punto non gli interesserà più di tanto modificare i template perché possono accedere al sito e rubare tutti i dati

Il codice php deve stare fuori dal template...

è sconsigliato perché "rischia" di rendere il codice confusionario e "rischia" di essere lento, ma guarda che moltissimi template engine convertono il proprio meta-linguaggio in codice php perché altrimenti l'esecuzione sarebbe lenta da fare schifo

non ci sto niente con un set di preg ed un pò di codice a far diventare

codice:

<?php foreach ($resultset as $result) : ?>
  <h2><?php echo $result->title; ?></h2>
  <span class="date"><?php echo $result->published; ?></span>
  

<?php echo $result->excerpt; ?></p>
<?php endforeach; ?>

<p class="pager">
  <?php foreach ($pagination as $link) : ?>
    <?php echo $link->index; ?>
  <?php endforeach; ?>
  create
</p>

cosi

codice:

<?php

foreach ($resultset as $result)
{
  echo <<< HTML_EOF
  <h2>{$result->title}</h2>
  <span class="date">{$result->published}</span>
  

{$result->excerpt;}</p>
HTML_EOF;
}

echo "  <p class=\"pager\">"
foreach ($pagination as $link)
{
    {$link->index}
}

echo <<< HTML_EOF
    create
  </p>
HTML_EOF;

?>

ma quale sarebbe il reale vantaggio? un minimo di performance in più? si? e quanti potenziali bug introduco nel motore di parsing e quanto lo faccio diventare grande? attualmente il mio TPL è 27kb, di cui 5kb sono solo eccezioni ed un altro paio di kb sono le intestazioni ... e da questi ci devi ancora togliere i commenti che inserisco una riga si e una riga no ... se dovessi fare una cosa del genere diventerebbe per lo meno 100kb di codice ... quasi 4 volte tanto ... potenazialmente almeno il 400% in più di possibilità di beccare codice fallato ...

non conviene

------

@whisher

XSLT è bello, sicuramente, ma siam sempre li

aumentare il numero componenti per utilizzarne uno aumenta la complessità e riduce la flessibilità e nel caso di XSLT entrano in ballo tanti fattori

sicuramente avresti il vantaggio di poter far convertire l'xslt direttamente al browser scaricando di molto il lavoro del server, però aumenteresti consistentemente il lavoro di sviluppo e realizzazioni del tutto :\

**daniele_dll** · 13-04-2008, 12:30

Originariamente inviato da jan267
Se si parsa tutto con eval si creano un sacco di problemi con apici ecc...

dove, scusami? io non ne vedo di problemi con eval e gli apici

Se invece si usa preg_replace con il modificatore "e" si parsa solo una piccolissima porzione (non con eval) di codice e il risultato parsato lo si ottiene con "return"...

mmm

$parsedBlock = eval("return <<<HTML_EOF\r\n" . $this->__blockList[$Name]['Content'] . "\r\nHTML_EOF;\r\n");

perché, qua cosa cambia? :master:

facendo cosi io continuo a parsare una microscopica porzione di codice, non scomodo il motore delle espressioni regolari, ed ottengo lo stesso risultato

Discussione: Template Engine - Usare codice php nei template o no?

Strumenti discussione

Ricerca discussione

Visualizza

Permessi di invio