¿Cómo mantener los archivos .phtml esbeltos y limpios?


14

Como su extensión de archivo sugiere, un .phtmlarchivo permite que el código PHP se mezcle con HTML. Sin embargo, el hecho de que pueda no debe verse como una licencia para volverse loco.

¿Por qué todavía vemos tantos archivos .phtml plagados de muchos PHP? ¿Y cuál es un buen enfoque para reducir la cantidad de PHP en un .phtmlarchivo?

Respuestas:


10

De hecho, cuanto menos PHP tenga .phtml, mejor, porque:

  1. La combinación de PHP y HTML es mucho más difícil de descifrar que cada uno de ellos individualmente, especialmente para aquellos que se sienten cómodos con solo uno de ellos (por ejemplo, diseñadores de front-end)
  2. tiene sentido lógico colocar la interacción con el código del servidor en el Bloque, lejos de lo que se presentará en el navegador: este es el viejo mantra de "separación de preocupaciones".

El archivo principal de Magento /app/design/frontend/base/default/template/catalog/product/price.phtml es un caso doloroso en este punto. Este código de "presentación" HTML muestra un precio. ¡Tiene 471 líneas de largo! Principalmente por la lógica PHP.

Para hacer tu .phtmlmás delgado y más limpio:

  1. evitar secuencias innecesarias de <?php … ?>, agruparlos en trozos con un solo<?php … ?>

  2. inserte tanto PHP como pueda en el Bloque, en lugar del .phtml

  3. para ayudar con lo anterior, en el Bloque utilice assign(‘myvar’, [expression])para crear $ variables a las que se pueda hacer referencia sin $this->...en el .phtml, para que pueda ser realmente conciso<?php echo $myvar; ?>

  4. desea que Magento adopte Twig en el futuro para una apariencia aún más limpia

Apliquemos lo anterior en un fragmento del código original del ejemplo dado anteriormente: /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. Primer paso: eliminar la repetición de <?php … ?>llegar a algo como esto:

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

Lo anterior pone todo PHP en un solo blob de código.

2 + 3. Evolucionando en algo mejor aún, mueve este código a su bloque:

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

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

Tenga en cuenta el uso de _prepareLayout()y las assign()funciones para esto.

Ahora esa sección enrevesada del .phtml se puede reducir a esta simple línea:

<?php echo $minPrice; ?>

¡Creo que todos podemos vivir con eso!


5

Buen artículo, @fris, estoy de acuerdo en casi todos los puntos.

La conclusión principal es mover toda la lógica a la clase de bloque y hacer que la plantilla sea lo más "estúpida" posible.

De hecho, prefiero las llamadas a métodos en la plantilla sobre las variables que han sido "asignadas" porque no quiero perder el código IDE y las funciones de navegación. "asignar" parece más conciso en la plantilla, pero es demasiado mágico para mi gusto, lo que lo hace aún peor que los captadores y setters mágicos.


Agradezco tu comentario @fschmengler. Sí, es un poco de magia, pero ese es el caso con todas las convenciones, al principio. Usar $ this dentro de un archivo .phtml ciertamente me pareció mágico la primera vez que lo vi. Ahora lo entiendo y está bien. Se trata de aprender los patrones y convenciones. La finalización del código es importante. Sin embargo, ¿es un llamado justo a colocar el pragmatismo derivado de herramientas que no son lo suficientemente sofisticadas sobre una decisión de programación arquitectónica?
fris

Usar la menor magia posible es una decisión arquitectónica. Si necesita herramientas adicionales para trabajar con una base de código que es una mala señal ... Para ser justos, Magento no tomó esta decisión, pero podemos esforzarnos por aprovecharla al máximo.
Fabian Schmengler

genial escritura fris. Estoy de acuerdo con cada punto, excepto asignar parte. la razón es porque se vuelve demasiado difícil encontrar esas variables mágicas para otro desarrollador que lo esté pasando. Creo que deberíamos evitar eso.
Rajeev K Tomy
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.