La prima risposta era effettivamente visibile, ma l'utente l'ha cancellata (probabilmente a causa della pressione dei colleghi). Fondamentalmente, non vuoi nessuna logica nel tuo modello. In un mondo ideale, avevi un tag per tutti i dati del modello, ma dal momento che siamo in un mondo HTML, non c'è, quindi devi usare XSLT o usare ViewHelpers.
Concentriamoci sull'approccio ViewHelper.
Questo è difficile da mantenere:
<div id="items">
<?php
for($i=0; $i<count($main); $i++) {
echo '<div class="item">
<div class="name">'.$main[$i]['name'].'</div>';
if($main[$i]['icq']=='') { }
else { echo '<div class="phone">'.$main[$i]['phone'].'</div>'; }
echo '</div>';
}
?>
</div>
E non sarà niente di meglio se si sostituisce il PHP con Smarty. Questo è facile da mantenere:
<div id="items">
<?php echo itemlist($items, 'template.htm') ?>;
</div>
Sotto la domanda ora cancellato, c'era una commentor contestare questo codice " non è facile da mantenere per i non programmatori perché ora non sanno dove ITEMLIST è definito e cosa fa." ma questo è senza senso. Pensaci per un secondo.
Da una parte, affermano che i non codificatori avranno problemi con una semplice chiamata di funzione, ma d'altra parte si aspettano che capiscano il guazzabuglio del codice PHP combinato con HTML. A un designer non interessa la logica della presentazione, ma solo la presentazione vera e propria. Il risultato.
Una singola chiamata di funzione dice chiaramente: "qui è un elenco di elementi", che è molto più facile da comprendere di "ecco un for che fa eco a un div e forse qualcos'altro se viene fornito icq". Una chiamata di funzione è valida come un tag. Ha input e output chiaramente definiti. Il modo in cui raggiunge quell'output è irrilevante per chiunque non sia lo sviluppatore.
ViewHelper incapsula la logica di presentazione. È uno snippet che puoi riutilizzare in tutte le tue visualizzazioni. Questo è molto più gestibile rispetto a copiare e incollare tutta la logica più e più volte quando necessario. Nell'esempio di cui sopra, ci sono due argomenti per l'aiutante:
- $ articoli è un array o un altro tipo attraversabile tenendo i dati dell'articolo reale
- 'template.htm' è il nome del modello utilizzato per il rendering i dati
Renderò il secondo opzionale, perché presumo che sia sempre lo stesso modello comunque. Ma dal momento che il commentatore si è lamentato che il non-codificatore non avrebbe saputo dove cercare, ho ritenuto necessario mostrare quanto sia facile dire al non-codificatore dove cercare.
function itemlist($items, $template = './templates/itemlist.htm') {
ob_start();
foreach($items as $item) {
include $template;
}
return ob_get_flush();
}
Ci potrebbero essere approcci più efficienti per risolvere l'inclusione del modello. L'idea principale dovrebbe essere chiara però. Nascondi la logica di presentazione dal modello attuale. Il tuo "template.htm" sarebbe quindi il seguente:
<div class="item">
<div class="name"><?php echo $item['name'] ?></div>
<?php echo contact($item, 'icq' 'phone'); ?>
</div>
No if ed elses. Nessuna concatenazione di stringhe o parentesi graffe. La logica per decidere come contattare l'utente è nascosta anche in ViewHelper. Tutto ciò che il non-coder deve sapere ora sono gli argomenti per ViewHelpers ed è facile come sapere quale attributo scrivere su un tag. Dare loro un foglio cheat, se necessario.
Informazioni correlate:
EDIT
A causa delle due commenti qui sotto ho deciso di espandere su questa risposta. Quanto sopra non è un'astrazione per l'astrazione.È per la riusabilità e la manutenibilità. L'ho già detto sopra, ma lascia che ti spieghi di nuovo qui.
In realtà, trovo strano avere obiezioni sull'uso di ViewHelpers perché "avremo una presentazione in due punti" ma non mi lamento di separare intestazione, banner e piè di pagina. È la stessa cosa. Si isolano le parti riutilizzabili e le si inseriscono nei propri modelli. Separare la logica dal modello in quella fase è solo il naturale passo successivo per ottenere ancora più manutenibilità.
Un modello di vista che contiene la logica è effettivamente uno script e non un modello. Ogni modello di vista che contiene la logica per assemblarsi è destinato a ripetersi. Questo potrebbe non essere un problema con i siti di piccole dimensioni, ma se stai lavorando su un sito con un paio di dozzine o centinaia di viste e widget, non astrarre queste parti porterà alla duplicazione del codice. Metti tutta la logica nel modello e diventerà rapidamente un caos aggrovigliato di c & markup p'ed misto a condizionali. Per qualsiasi duplicazione, raddoppierai il tempo necessario per modificarlo. Aggiungi stili incorporati e Javascript invadente e sei in manutenzione hell.¹
Se usi OOP per le altre parti della tua applicazione, perché dovresti procedere proceduralmente alla tua vista? Se hai capito che dovresti separare Javascript e CSS dal tuo HTML, perché dovresti mischiare PHP nel tuo modello? Non ha senso. Lo snippet di codice dell'OP è uno script e non un modello. In quanto tale, è il dominio dello sviluppatore. E a causa di ciò applicate tutte le buone pratiche applicate anche ad altre parti della vostra applicazione. E questo include l'isolamento della logica in funzioni e/o classi.
Concesso, un designer che sta esaminando una sceneggiatura potrebbe non sapere immediatamente cosa sta succedendo. Ma poi di nuovo, potrebbe non saperlo neanche dopo aver iniziato ad aggiungere le funzioni native di PHP. Cosa sta facendo mb_strimwidth? E substr? Cos'è il costrutto ?:? Il PHP più reale che aggiungi, più difficile sarà leggere per i non sviluppatori.
Se si desidera che i progettisti lavorino sui modelli, non fornire loro script. Dai loro modelli E se lo fai, isolare la logica da esso e sostituirlo con chiamate di funzione facili da afferrare. Usa i nomi delle funzioni che comunicano chiaramente ciò che fa la funzione. Quindi il progettista ha solo bisogno di sapere se "Io uso questo con quell'input, otterrò sempre quell'output. Non m'importa come sarà quel risultato. Lo lascerò allo sviluppatore".
L'isolamento della logica in funzioni (o classi) offre inoltre il vantaggio immediato di poter testare la logica utilizzata per eseguire il rendering di parti specifiche su tale pagina separatamente. Non è necessario configurare l'intero ambiente richiesto per creare una pagina, ma basta inserire l'input richiesto e dichiararne l'output (ecco perché la funzione memorizza la stringa anziché emetterla btw).
¹ Per quelli di voi che pensano che questo non sia un problema, suggerisco caldamente di trovarsi un'applicazione legacy che mantenga davvero tutta la logica nel modello di visualizzazione. Prova a cambiare alcune cose. Una volta che hai avuto il piacere di mangiare attraverso 2500 linee di codice spaghetti con almeno 500 caratteri ciascuna e contenente un mix di PHP, HTML, CSS e JavaScript ripetuto, saprai di cosa sto parlando.
Se short_tags (php.ini) è abilitato, è possibile utilizzare anche "" Invece di –
Ho discusso se metterlo o meno, ma personalmente non mi piace affidarmi ai tag brevi: non so mai quando qualcuno li spegnerà su di te, e poi ti troverai in un mondo di guai. – sevenseacat
Non li uso neanche ... ma credo che in codeigner funzionerebbero non importa se sono disattivati apache ... – rabidmachine9