2011-01-19 16 views
6

Io uso PHP un bel po ', e ogni volta che vedo un "PHP-odio" filo su qualche forum o discussioni anche popolari PHP legati qui, di solito vedo qualcosa sulla falsariga di:Come non mescolare la presentazione con la logica?

PHP è troppo disordinato/sciatto/schifoso, perché hai una rete intricata di presentazione e logica.

Quindi vedo i difensori PHP che rispondono ad alcune versioni del detto precedente che non è necessariamente vero. Ho avuto modo di pensare "Com'è possibile ...?" e "Che cosa conta come un mix di presentazione con la logica?" Non riuscivo a capirlo, quindi ora sono qui.

Quale di queste è la migliore pratica? O c'è un modo ancora migliore di cui non sono a conoscenza?

<?php 
    if(!function()) { 
     echo '<div id="results">The result is a lie.</div>'; 
     } 
?> 

O

<div id="results"> 
    <?php 
     if(!function()) { 
      echo 'The result is a lie.'; 
      } 
    ?> 
</div> 

So che gli esempi di cui sopra in realtà non sembra un grosso problema, ma dopo la navigazione attraverso applicazioni web miei, ho capito che era tutto il genere di disordine (perché io stava mescolando HTML e PHP), quindi speravo che ci fosse un buon modo per sviluppare mantenendo le cose belle e pulite.

+0

Mi attengo personalmente alla prima opzione e invio tutto tramite codice. Trovo che sia molto più pulito. – Brad

+0

Non è una bacchetta, è un mago. Uno sempre in grado di separare le cose. Se lo vogliono. –

+0

* (correlato) * [MVC: quanto codice deve essere in una vista?] (Http://stackoverflow.com/questions/4698880/mvc-how-much-code-should-be-in-a-view/ 4699689) – Gordon

risposta

11

Forse si vuole guardare un motore di template, come smarty. Questo può separarlo per te.

Linkage: http://www.smarty.net/

Alcuni (si spera bilanciati) aggiunte vedendo piuttosto grande commento-sezione sottostante:

Sembra che ci sia un sacco di discussioni su Smarty. Ci sono due campi extra in questo per quanto posso dire,

uno dice: motore di modello, ok, ma smarty non è il migliore; usa (inserisci la tua scelta qui). ad esempio: twig o dwoo.

e un altro dice: non utilizzare un motore di modello separato! Come PHP è perfettamente in grado di farlo da solo. Esempi dalle osservazioni comprendono:

Usa Zend_View e Savant

+0

+1: questa è la risposta giusta. Scrivi il tuo HTML come modello e usa PHP per riempire gli spazi vuoti e servirlo. –

+0

Non sono proprio sicuro del motivo per cui ho appena ottenuto un -1? Non è un "look da qualche altra parte sollution", Questo è davvero un modo per fermare tutti quei problemi PHP di mixaggio ... – Nanne

+1

anche dare un'occhiata a Twig! http://www.twig-project.org/ – Paul

1

Il secondo esempio è meglio.

Il modo più semplice per evitare di mescolare la presentazione con la logica sarebbe utilizzare un framework MVC come Symfony o CakePHP. Ciò consente di separare i dati (modelli) dalla logica (controller) e dalla presentazione (viste).

L'altra risposta è buona: utilizzare i modelli. I templati sono quasi sempre parte di un framework MVC.

+0

Il templating è * sempre * parte di MVC. Ecco a cosa serve la V. ;) – netcoder

+0

@netcoder non tutti i framework MVC sono dotati di un motore di template, però :) Alcuni ti fanno scegliere da solo –

+0

Hai ragione, ma stavo parlando del modello di progettazione, non dei framework. ;) – netcoder

0

È possibile definire metodi di supporto in un file incluso o nella parte superiore della pagina:

<?php 
function result_if_good() 
{ 
    if (!function()) { 
     return 'The result is a lie.'; 
    } 
} 
?> 

E poi altrove, nel codice HTML:

<div id="results"><?php echo result_if_good();?></div> 

Mantenendo tutta la tua logica di la tua presentazione.

+0

C'è un problema. Quella funzione di supporto diventa lo stesso pasticcio –

+0

Tranne che sono PHP e condizioni condizionali senza HTML. Anche con un motore di template, puoi ancora mettere troppa logica condizionale nei tuoi template, ed è bene iniziare a metterli in view helper. – scragz

0

Se si desidera una vera separazione tra la logica e l'interfaccia, è necessario controllare lo MVC pattern.

Io uso il punto di vista del pattern MVC con il motore di un modello per ottenere i file HTML pulito per le mie opinioni

0

Preferisco una situazione in cui uno script inserisce l'HTML e il javascript se necessario. In altre parole, qualcosa di più simile (in pseudo python):

#Primitives 
def htmlheader(title): 
    return "<html><head><title>%title</title></head>" % title 

def body: 
    return "<body>" 

def para(content): 
    return "<p>%content</p>" % content 

def htmlend: 
    return "</body></html>" 

#New file: View 

print htmlheader() 
print body() 
print para("This is my paragraph") 
print para("Hello, %salatation %lastname" % dbresult.salutation, dbresult.lastname) 
print htmlend() 

PHP soffre di essere circondato da <>, che sono già abbastanza difficile da leggere.

YMMV

Con primitive in atto per mettere fuori quello attuale HTML, è possibile poi fare uno strato di controllo che si limita a mani i dati puri alla vista. Più pseudoPython:

#ViewController 

db = dbconnect("host", "user", "password"); 

view.mainbody.show(getCurrentNews(db)) 
view.header.show(getTopHeadLines(db)) 
if (user.isLoggedIn): 
    view.footer.userNavigation() 
else: 
    view.footer.showDefault() 
view.render 
+0

Esempio molto poco chiaro che in realtà non emette un singolo tag HTML –

+0

Ho aggiunto le primitive per aiutare l'esempio. –

+0

Bene, il tuo codice HTML non sembra HTML. è tutto in stringhe delimitate da virgolette. Nessuna evidenziazione della sintassi, pasticcio di fuga e tutta quella merda. Lo usi davvero? Per i modelli del mondo reale? –

2

Pensate logica e presentazione in cui la logica è un tipo di presa elettrica e la presentazione è una lampadina. Ora puoi avere un numero di prese in casa, alcune con fili di dimensioni diverse. Puoi anche avere un mazzo di lampadine, di colori diversi, alcune a buon mercato, alcune costose. Il punto è che una lampadina può entrare in uno o più calzini e una presa può accettare più di una lampadina, ma è possibile abbinare solo una lampadina a una presa alla volta.

Quindi, se si dispone di un bulbo davvero bello (o di un modello html veramente bello), si desidera essere in grado di spostare quella lampadina nel punto in cui è necessario (o applicare la stessa logica). E se un giorno decidessi di usare una lampadina blu, puoi semplicemente cambiare la lampadina, non devi installare una presa elettrica completamente nuova solo per cambiare il colore.

Tornando alla logica e alla presentazione, se si ha il caso comune in cui si dispone di un modulo su una pagina Web, a volte viene visualizzato tale modulo la prima volta che un utente carica la pagina e talvolta si desidera mostrarlo dopo la l'utente ha inserito alcuni degli input, ma forse c'erano errori o informazioni mancanti. In questo caso la logica non farebbe nulla, mostrerebbe semplicemente il modulo, o tenterà di elaborare il modulo, trovare l'errore e quindi visualizzare il modulo che rivela gli errori.

È possibile farlo con logica mista e presentazione nello stesso file, certo, ma cosa succede quando più di una persona inizia a modificare lo script? Forse la sceneggiatura si interrompe e non sanno cosa fare, quindi commentano alcune sezioni importanti per farlo funzionare di nuovo. È come se qualcuno cambiasse una lampadina e poi decidesse di ricollegare i tuoi interruttori della luce. Ma a volte quando ci si trova di fronte a problemi di cablaggio non c'è altro modo per risolvere il problema, il problema va da un semplice "Si prega di cambiare la lampadina" a "Far funzionare le luci". In un sistema progettato correttamente, in cui i componenti sono isolati in modo ragionevole, le cose sono in genere più facili da risolvere.

In altre parole, la logica di mixaggio e la presentazione sono come cablaggi fissi delle lampadine usando il filo nudo e quindi collegano i fili alla rete senza nemmeno un interruttore automatico per sicurezza.

Problemi correlati