PHP está bien para crear plantillas

Las plantillas PHP a menudo tienen mala reputación por código facilitar deficiente, pero ese no tiene por qué ser el caso. Veamos cómo los proyectos PHP pueden aplicar una estructura básica de Modelo, Vista y Controlador (MVC) sin depender de un motor de plantillas diseñadas específicamente.

Pero primero, una breve lección de historia de PHP.

La historia de PHP como herramienta para crear plantillas HTML está llena de giros y vueltas.

Uno de los primeros lenguajes de programación utilizados para las plantillas HTML fue C, pero rápidamente se descubrió que era tedioso de usar y, en general, inadecuado para la tarea.

Rasmus Lerdorf creó PHP con esto en mente. No se oponía a usar C para manejar la lógica empresarial de back-end, pero quería una mejor manera de generar HTML dinámico para el front-end. PHP se diseñó originalmente como un lenguaje de plantillas, pero adoptó más funciones con el tiempo y finalmente se convirtió en un lenguaje de programación completo por derecho propio.

Se descubrió que la capacidad única de PHP para cambiar entre el modo de programación y el modo HTML era bastante conveniente, pero también hacía tentador para los programadores escribir código que no se pudiera mantener, código que mezclaba lógica de negocios y lógica de plantillas. Un archivo PHP podría comenzar con algunas plantillas HTML y luego, de repente, sumergirse en una consulta SQL avanzada sin previo aviso. Esta estructura es confusa de leer y dificulta la reutilización de plantillas HTML.

A medida que pasó el tiempo, la comunidad de desarrollo web encontró cada vez más valor al imponer una estructura MVC estricta para proyectos PHP. Los motores de plantillas se crearon como una forma de separar eficazmente las vistas de sus controladores.

Para realizar esta tarea, los motores de plantillas suelen tener las siguientes características:

1. El motor tiene deliberadamente poca potencia para la lógica empresarial. Si un desarrollador quiere realizar una consulta a una base de datos, por ejemplo, debe realizar esa consulta en el controlador y luego pasar el resultado a la plantilla. Realizar una consulta en medio del HTML de la plantilla no es una opción.
2. El motor se ocupa de los riesgos de seguridad comunes entre bastidores. Incluso si un desarrollador no puede validar la entrada del usuario y la pasa directamente a la plantilla, la plantilla a menudo escapará automáticamente de cualquier HTML peligroso.

Los motores de plantillas son ahora una característica fundamental en muchas tecnologías web. Crea bases de código más seguras y fáciles de mantener, por lo que esto no es una sorpresa.

Sin embargo, también es posible manejar plantillas HTML con PHP simples . Es posible que desees hacer esto por varias razones. Tal vez esté trabajando en un proyecto heredado y no quiera incorporar dependencias adicionales, o tal vez esté trabajando en un proyecto muy pequeño y prefiera mantener las cosas lo más livianas posibles. O tal vez la decisión no depende en absoluto de usted.

Casos de uso de plantillas PHP

Un lugar donde a menudo implementamos plantillas PHP simples es WordPress, que no impone una estructura MVC rígida de forma predeterminada. Siento que incorporar un motor de plantillas completo es un poco complicado, pero todavía quiero separar mi lógica de negocios de mis plantillas y quiero que mis vistas sean reutilizables.

Cualquiera sea el motivo, utilizar PHP simple para definir sus plantillas HTML es a veces la opción preferida. Esta publicación explora cómo se puede hacer esto de una manera razonablemente profesional. El enfoque representa un punto medio práctico entre el estilo codificado en español por el que las plantillas PHP se han vuelto famosas y el enfoque sin lógica permitida disponible con los motores de plantillas formales.

Profundizamos en un ejemplo de cómo se puede poner en práctica un sistema de plantillas básico. Nuevamente, estamos usando WordPress como ejemplo, pero esto podría cambiarse a un entorno PHP simple oa muchos otros entornos. Y no es necesario estar familiarizado con WordPress para seguirlo.

El objetivo es dividir nuestras vistas en componentes y crear una separación clara entre la lógica empresarial y las plantillas HTML. Específicamente, vamos a crear una vista que muestre una cuadrícula de tarjetas. Cada tarjeta mostrará el título, el extracto y el autor de una publicación reciente.

Paso 1: Obteniendo datos para renderizar

El primer paso a seguir es recuperar los datos que queremos mostrar en nuestra vista. Esto podría implicar la ejecución de una consulta SQL o el uso del ORM o funciones auxiliares de su marco/CMS para acceder a su base de datos indirectamente. También podría implicar realizar una solicitud HTTP a una API externa o recopilar información del usuario desde un formulario o cadena de consulta.

En este ejemplo, usaremos la get_postsfunción auxiliar de WordPress para buscar algunas publicaciones y mostrarlas en nuestra página de inicio.

?php // index.php$wp_posts = get_posts([  'numberposts' = 3]);

Ahora tenemos acceso a los datos que queremos mostrar en la cuadrícula de tarjetas, pero necesitamos hacer algo de trabajo adicional antes de poder pasarlos a nuestra vista.

Paso 2: Preparar datos para crear plantillas

La get_postsfunción devuelve una matriz de WP_Postobjetos. Cada objeto contiene el título de la publicación, el extracto y la información del autor que necesitamos, pero no queremos acoplar nuestra vista al WP_Posttipo de objeto porque es posible que queramos mostrar otros tipos de datos en nuestras tarjetas en algún otro lugar del proyecto.

En cambio, tiene sentido convertir proactivamente cada objeto de publicación a un tipo de datos neutral, como una matriz asociativa:

?php // index.php$wp_posts = get_posts([  'numberposts' = 3]);$cards = array_map(function ($wp_post) {  return [    'heading' = $wp_post-post_title,    'body' = $wp_post-post_excerpt,    'footing' = get_author_name($wp_post-post_author)  ];}, $wp_posts);

En este caso, cada WP_Postobjeto se convierte en una matriz asociativa mediante la array_mapfunción. Observe que las claves para cada valor no son title, excerpty , authorsino que reciben nombres más generales: heading, bodyy footing. Hacemos esto porque el componente de cuadrícula de tarjetas está diseñado para admitir cualquier tipo de datos, no solo publicaciones. Podría usarse con la misma facilidad para mostrar una cuadrícula de testimonios que tengan una cotización y el nombre de un cliente, por ejemplo.

Con los datos preparados adecuadamente, ahora se pueden pasar a nuestra render_viewfunción:

?php // index.php// Data fetching and formatting same as beforerender_view('cards_grid', [  'cards' = $cards]);

Por supuesto, la render_viewfunción aún no existe. Definámoslo.

Paso 3: crear una función de renderizado

// Defined in functions.php, or somewhere else that will make it globally available.// If you are worried about possible collisions within the global namespace,// you can define this function as a static method of a namespaced classfunction render_view($view, $data){  extract($data);  require('views/' . $view . '.php');}

Esta función acepta el nombre de la vista renderizada y una matriz asociativa que representa los datos que se mostrarán. La función de extracción toma cada elemento de la matriz asociativa y crea una variable para él. En este ejemplo, ahora tenemos una llamada variable $cardsque contiene los elementos que preparamos en index.php.

Dado que la vista se ejecuta en su propia función, obtiene su propio alcance. Esto es bueno porque nos permite usar nombres de variables simples sin temor a colisiones.

La segunda línea de nuestra función imprime la vista que coincide con el nombre pasado. En este caso busca la vista en views/cards_grid.php. Sigamos adelante y creemos ese archivo.

Paso 4: crear plantillas

?php /* views/cards_grid.php */ ?section  ul    ?php foreach ($cards as $card) : ?    li      ?php render_view('card', $card) ?    /li    ?php endforeach; ?      /ul/section

Esta plantilla utiliza la $cardsvariable que se acaba de extraer y la representa como una lista desordenada. Para cada tarjeta de la matriz, la plantilla representa una subvista: la vista de tarjeta singular.

Tener una plantilla para una sola tarjeta es útil porque nos brinda la flexibilidad de renderizar una sola tarjeta directamente o usarla en otra vista en otra parte del proyecto.

Definimos la vista de tarjeta básica:

?php /* views/card.php */ ?div  ?php if (!empty($heading)) : ?    h4?= htmlspecialchars($heading) ?/h4        ?php endif;  if (!empty($body)) : ?    p?= htmlspecialchars($body) ?/p        ?php endif;  if (!empty($footing)) : ?          span?= htmlspecialchars($footing) ?/span  ?php endif; ?/div

Dado que lo $cardque se pasó a la función de renderizado contenía claves para a heading, bodyy footing, las variables de esos mismos nombres ahora están disponibles en la plantilla.

En este ejemplo, podemos estar razonablemente seguros de que nuestros datos están libres de riesgos XSS , pero es posible que esta vista pueda usarse con la entrada del usuario en algún momento posterior, por lo que htmlspecialcharses prudente pasar cada valor. Si existe una etiqueta de secuencia de comandos en nuestros datos, se escapará de forma segura.

También suele ser útil comprobar que cada variable contiene un valor que no esté vacío antes de representarla. Esto permite omitir variables sin dejar etiquetas HTML vacías en nuestro marcado.

Los motores de plantillas PHP son excelentes, pero a veces es apropiado usar PHP para lo que fue diseñado originalmente: generar HTML dinámico.

Crear plantillas en PHP no tiene por qué dar como resultado un código espagueti que no se puede mantener. Con un poco de previsión podemos lograr un sistema MVC básico que mantenga las vistas y los controladores separados entre sí, y esto se puede hacer con sorprendentemente poco código.