Come mantenere i file .phtml snelli e puliti?


14

Come suggerisce l'estensione del file, un .phtmlfile consente di mescolare il codice PHP con HTML. Tuttavia, il fatto che si può , non deve essere visto come una licenza per scatenarsi.

Perché vediamo ancora così tanti file .phtml pieni di PHP? E qual è un buon approccio per ridurre la quantità di PHP in un .phtmlfile?

Risposte:


10

Infatti, meno PHP è nella tua .phtml, meglio è perché:

  1. il mix di PHP e HTML è molto più difficile da decifrare rispetto a ciascuno di essi singolarmente, specialmente per quelli che si sentono a proprio agio con uno solo di essi (ad es. designer front-end)
  2. ha senso logico collocare l'interazione con il codice del server nel Blocco, lontano da ciò che deve essere presentato nel browser: questo è il vecchio mantra della "separazione delle preoccupazioni".

Il file core di Magento /app/design/frontend/base/default/template/catalog/product/price.phtml è un caso doloroso al punto. Questo codice HTML di "presentazione" mostra un prezzo. È lungo 471 linee! Principalmente a causa della logica di PHP.

Per rendere il tuo .phtmlcorpo più magro e pulito:

  1. evitare sequenze inutili di <?php … ?>, raggrupparle insieme in blocchi con un singolo<?php … ?>

  2. inserisci più PHP che puoi nel Blocco, piuttosto che nel .phtml

  3. per aiutare con quanto sopra, nel Blocco utilizzare assign(‘myvar’, [expression])per creare $ variabili a cui si può fare riferimento senza $this->....phtml, in modo da poter avere conciso<?php echo $myvar; ?>

  4. auguro a Magento di adottare Twig in futuro per un look ancora più pulito

Applichiamo quanto sopra su uno snippet dal codice originale dell'esempio fornito sopra: /app/design/frontend/base/default/template/catalog/product/price.phtml

<?php if ($this->getDisplayMinimalPrice() && $_minimalPriceValue && $_minimalPriceValue < $_product->getFinalPrice()): ?>

    <?php $_minimalPriceDisplayValue = $_minimalPrice; ?>
    <?php if ($_weeeTaxAmount && $_weeeHelper->typeOfDisplay($_product, array(0, 1, 4))): ?>
        <?php $_minimalPriceDisplayValue = $_minimalPrice+$_weeeTaxAmount; ?>
    <?php endif; ?>
    ….
             <?php echo $_coreHelper->currencyByStore($_minimalPriceDisplayValue, $_storeId, true, false) ?>
  1. Primo passo: rimuovere la ripetizione di <?php … ?>arrivare a qualcosa del genere:

    if ($this->getDisplayMinimalPrice() && $_minimalPriceValue && $_minimalPriceValue < $_product->getFinalPrice()) { $_minimalPriceDisplayValue = $_minimalPrice; if ($_weeeTaxAmount && $_weeeHelper->typeOfDisplay($_product, array(0, 1, 4))) { $_minimalPriceDisplayValue = $_minimalPrice+$_weeeTaxAmount; } … echo $_coreHelper->currencyByStore($_minimalPriceDisplayValue, $_storeId, true, false) ?>

Quanto sopra mette tutto PHP in un unico blocco di codice.

2 + 3. Sempre evolvendo in qualcosa di meglio, sposta questo codice nel suo blocco:

protected function _prepareLayout() {
    $this->assign(‘minPrice’, $this->calculateMinPrice(…));
}

protected function calculateMinPrice(…) {
    if ($this->getDisplayMinimalPrice() && $_minimalPriceValue && $_minimalPriceValue < $_product->getFinalPrice()) {
       // etc...
    }
}

Si noti l'uso della _prepareLayout()e le assign()funzioni di questo.

Ora quella sezione contorta di .phtml può essere ridotta a questa semplice riga:

<?php echo $minPrice; ?>

Penso che tutti noi possiamo conviverci!


5

Bel commento, @fris, sono d'accordo in quasi tutti i punti.

L'asporto principale è spostare tutta la logica nella classe di blocco e rendere il modello il più "stupido" possibile.

In realtà preferisco le chiamate di metodo nel modello rispetto alle variabili che sono state "assegnate" perché non voglio perdere il completamento del codice IDE e le funzionalità di navigazione. "assegnare" un aspetto più conciso nel modello, ma è troppo magico per i miei gusti, rendendolo anche peggio dei getter e dei setter magici.


Apprezzo il tuo commento @fschmengler. Sì, è un po 'magico, ma all'inizio è il caso di tutte le convenzioni. Usare $ this all'interno di un file .phtml mi è sembrato sicuramente magico per la prima volta che l'ho visto. Ora lo capisco e va bene. Si tratta di apprendere gli schemi e le convenzioni. Il completamento del codice è importante. Tuttavia, è una buona chiamata inserire il pragmatismo derivante da strumenti non sufficientemente sofisticati rispetto a una decisione di programmazione architettonica?
fris il

Usare meno magia possibile è una decisione architettonica. Se hai bisogno di strumenti aggiuntivi per lavorare con una base di codice che è un brutto segno ... Ad essere onesti, Magento non ha preso questa decisione, ma possiamo sforzarci di trarne il meglio.
Fabian Schmengler,

cool fris writeup. Sono d'accordo con ogni punto tranne assegnare parte. il motivo è perché diventa troppo difficile trovare quelle variabili magiche per un altro sviluppatore che le sta attraversando. penso che dovremmo evitarlo.
Rajeev K Tomy,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.