Как сохранить .phtml файлы чистыми и чистыми?


14

Поскольку расширение файла предполагает, что .phtmlфайл позволяет смешивать код PHP с HTML. Однако тот факт, что вы можете не следует рассматривать как лицензию, чтобы сойти с ума.

Почему мы до сих пор видим так много файлов .phtml, пронизанных большим количеством PHP? И каков хороший подход для уменьшения количества PHP в .phtmlфайле?

Ответы:


10

В самом деле, чем меньше PHP в вашем, .phtmlтем лучше, потому что:

  1. Сочетание PHP и HTML гораздо сложнее расшифровать, чем каждый из них в отдельности, особенно для тех, кто предпочитает работать только с одним из них (например, дизайнеры внешнего интерфейса)
  2. Логично иметь смысл размещать взаимодействие с серверным кодом в Блоке, вдали от того, что должно быть представлено в браузере - это старая мантра «разделения интересов».

Файл ядра Magento /app/design/frontend/base/default/template/catalog/product/price.phtml является болезненным примером. Этот HTML-код «презентации» отображает цену. Это 471 строка! Главным образом из-за логики PHP.

Чтобы сделать ваш .phtmlстройнее и чище:

  1. Избегайте ненужных последовательностей <?php … ?>, объединяйте их в куски с одним<?php … ?>

  2. вставьте столько, сколько сможете PHP в блок, а не в .phtml

  3. Чтобы помочь с вышесказанным, в блоке использовать assign(‘myvar’, [expression])для создания $ переменных, которые можно ссылаться без $this->...в .phtml, так что вы можете быть действительно кратким<?php echo $myvar; ?>

  4. желаю Magento принять Twig в будущем для еще более чистого взгляда

Давайте применим вышеизложенное к фрагменту из исходного кода приведенного выше примера: /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. Первый шаг: удалите повторение <?php … ?> чтобы получить что-то вроде этого:

    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) ?>

Выше все помещает весь PHP в один блок кода.

2 + 3. Развиваясь во что-то лучшее, переместите этот код в свой блок:

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

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

Обратите внимание на использование _prepareLayout()и assign()функций для этого.

Теперь этот извилистый раздел .phtml можно сократить до простой строки:

<?php echo $minPrice; ?>

Я думаю, что мы все можем жить с этим!


5

Хорошая рецензия, @fris, я согласен почти во всех аспектах.

Основной вывод заключается в том, чтобы переместить всю логику в класс блоков и сделать шаблон как можно более «глупым».

Я на самом деле предпочитаю вызовы методов в шаблоне переменным, которые были «назначены», потому что я не хочу терять возможности завершения кода IDE и функции навигации. «назначение» в шаблоне выглядит более лаконично, но на мой вкус это слишком много волшебства, что делает его еще хуже, чем магические геттеры и сеттеры.


Ценю ваш комментарий @fschmengler. Да, это немного волшебства, но в первую очередь это относится ко всем соглашениям. Использование $ this внутри .phtml файла, конечно, выглядело как волшебство, когда я впервые увидел это. Теперь я это понимаю, и это нормально. Это вопрос изучения шаблонов и соглашений. Завершение кода важно. Однако справедливо ли призывать к прагматизму, вытекающему из инструментов, которые недостаточно совершенны для архитектурного решения?
Фри

Использование как можно меньшего количества магии - архитектурное решение. Если вам нужны дополнительные инструменты для работы с кодовой базой, это плохой признак ... Честно говоря, Magento не приняла это решение, но мы можем стремиться извлечь из него максимальную пользу.
Фабиан Шменглер

классная рецензия фрис. Я согласен с каждым пунктом, кроме присвоения части. причина в том, что становится слишком трудно найти эти магические переменные для другого разработчика, который проходит через это. Я думаю, что мы должны избегать этого.
Раджив К Томи
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.