plantillas - smarty php tutorial
¿Por qué debería usar el sistema de plantillas en PHP? (24)
¿Por qué debería usar el sistema de plantillas en PHP?
El razonamiento detrás de mi pregunta es: PHP en sí es un sistema de plantillas rico en características, ¿por qué debería instalar otro motor de plantillas?
Los únicos dos profesionales que encontré hasta ahora son:
- Una sintaxis un poco más limpia (a veces)
- El motor de plantillas no suele ser lo suficientemente potente como para implementar la lógica comercial, por lo que te obliga a separar las preocupaciones. Las plantillas con PHP pueden atraerlo a recorrer los principios de creación de plantillas y comenzar a escribir sopa de código nuevamente.
... y ambos son bastante insignificantes en comparación con los contras.
Pequeño ejemplo:
PHP
<h1><?=$title?></h1>
<ul>
<? foreach ($items as $item) {?>
<li><?=$item?></li>
<? } ?>
</ul>
Sabelotodo
<h1>{$title}</h1>
<ul>
{foreach item=item from=$items}
<li>{$item}</li>
{/foreach}
</ul>
Realmente no veo ninguna diferencia en absoluto.
Algunos podrían argumentar que Smarty hace lo que PHP ya puede hacer: separar la presentación de la lógica comercial. El lenguaje de programación PHP es ideal para el desarrollo de código, pero cuando se mezcla con HTML, la sintaxis de las declaraciones PHP puede ser un desastre para administrar. Smarty compensa esto al aislar PHP de la presentación con una sintaxis basada en etiquetas mucho más simple. Las etiquetas revelan contenido de la aplicación, imponiendo una separación limpia del código PHP (aplicación). No se requiere conocimiento de PHP para administrar plantillas de Smarty.
La importancia de esta separación es situacional. Por lo general, es más importante para los diseñadores web que para los desarrolladores de PHP. Por lo tanto, Smarty suele ser una buena opción cuando los roles de los desarrolladores y diseñadores están separados. No hay una respuesta correcta o incorrecta: cada equipo de desarrollo tiene sus propias preferencias para administrar el código y las plantillas. Además de una sintaxis limpia basada en etiquetas, Smarty también ofrece una amplia variedad de herramientas para administrar la presentación: almacenamiento en caché de datos granular, herencia de plantillas y sandboxing funcional, por nombrar algunos. Los requisitos empresariales y el código PHP con el que Smarty se está utilizando jugarán un papel importante para determinar si Smarty es una buena opción.
Apostaría a que si un lenguaje de plantilla PHP fuera tan coercitivo como para obligarlo a usarlo, no lo usaría en absoluto. La capacidad de ''saltar'' y hacer las cosas a su manera cuando tiene problemas es uno de los atractivos de PHP.
No digo que sea bueno, ni que el código pueda mantenerse, solo que en las consideraciones iniciales, no elegiría un lenguaje de plantilla que me bloqueara por completo.
De lo contrario, estoy de acuerdo en que los sistemas de creación de plantillas lo ayudan a dividir el trabajo entre la codificación y el diseño, y posiblemente a permitir que los diseñadores nos diseñen y codifiquen.
Creo que una sintaxis más limpia es una gran victoria. Aunque puede parecer solo unos pocos caracteres, pero cuando lo haces todos los días, cada personaje comienza a contar.
Y {$myvar|escape} es en mi humilde opinión un poco más corto que <?php echo htmlspecialchars($myvar); ?> <?php echo htmlspecialchars($myvar); ?> . (Teniendo en cuenta que la sintaxis <?=$foo?> Solo está disponible cuando está especialmente habilitada en PHP conf.)
Cuando estás escribiendo código para otra persona. Por ejemplo, una vez estuve involucrado en la creación de un marco rígido de aplicaciones web que debería ser personalizable para nuestros clientes. Una solicitud importante fue que el cliente pudiera contratar a un diseñador para modificar las plantillas sin tener que poder programar. Aún más importante, es posible que no esté autorizado a cambiar el código.
Smarty, por ejemplo, permite implementar restricciones bastante rígidas sobre lo que puede hacer la plantilla. Básicamente, nuestra aplicación deshabilitó todas las construcciones de código excepto las más básicas y un conjunto seleccionado de funciones modificadoras. Así que teníamos dos objetivos bien atendidos por un motor de plantillas: simplicidad y seguridad .
Estoy feliz de usar un framework MVC como encendedor de código. Encuentro que en las "vistas" tiendo a apegarme al código php que se refiere solo a cómo se muestran los valores. Tengo una biblioteca de funciones de formato que puedo usar en las vistas a tal efecto. Una de las premisas del encendedor de código es evitar un lenguaje de plantillas debido a la forma en que puede restringirlo y la ralentización que se produce.
Me parece que es mejor para los diseñadores aprender algo de PHP, para que puedan lograr lo que necesitan hacer, por ejemplo. nombres alternativos de clase. También los hará más útiles a largo plazo y no supone un gran salto de una sintaxis a otra.
La razón principal por la que las personas usan sistemas de plantillas es separar la lógica de la presentación. Hay varios beneficios que provienen de eso.
En primer lugar, puede entregar una plantilla a un diseñador web que puede mover las cosas como mejor le parezca, sin tener que preocuparse por mantener el flujo del código. No necesitan comprender PHP, solo para saber dejar las etiquetas especiales solo. Puede que tengan que aprender algunas semánticas simples para algunas etiquetas, pero eso es mucho más simple que aprender todo el lenguaje.
Además, al dividir la página en archivos separados, tanto el programador como el diseñador pueden trabajar en la misma ''página'' a la vez, ingresando al control de fuente cuando lo necesiten, sin conflictos. Los diseñadores pueden probar sus visuales de plantilla contra una versión estable del código mientras el programador está haciendo otros cambios, potencialmente rompiendo, contra su propia copia. Pero si estas personas estaban editando el mismo archivo y debieron fusionarse en diferentes cambios, puede encontrar problemas.
También impone buenas prácticas de programación para mantener la lógica empresarial lejos de la lógica de presentación. Si combina la lógica de su negocio con la presentación, le será más difícil extraerla si necesita presentarla de manera diferente más adelante. Los diferentes modos de presentación en las aplicaciones web son cada vez más populares en estos días: feeds RSS / ATOM, respuestas JSON o AJAX, WML para dispositivos de mano, etc. Con un sistema de plantillas, a menudo se puede hacer con una plantilla y nada o casi nada. más.
Sin embargo, no todos necesitarán ni apreciarán estos beneficios. La ventaja de PHP sobre Java / Python / Ruby / etc es que puede piratear rápidamente las páginas web con algo de lógica, y eso está muy bien.
Los desarrolladores que utilizarán los conceptos de OOP en gran medida, como las personas JAVA / Spring / Oracle PL-SQL, dicen que el lenguaje PHP en sí se utiliza para la presentación / visualización / visualización de lógica en los proyectos de nivel Enterprise. En estos proyectos GRANDES, el backend es Oracle, la base de datos se obtiene usando pl-slq / java y la presentación es php. El mejor ejemplo es Facebook. http://en.wikipedia.org/wiki/Facebook Facebook Facebook utiliza php para presentaciones, java / c ++ como interfaz de back-end.
La única razón por la cual php se usa como presentación porque trabaja estrechamente con HTML, pero java / c ++ tiene más OOPs y no se puede ajustar directamente con HTML. Dime un CMS (joomla / drupal / wordpress) o framework (zend / symfony / Yii) que hace uso de Smarty? Entonces, ¿por qué inteligente es necesario?
Me gusta la capacidad de mostrar trivialmente cualquier plantilla de cualquier archivo PHP (e incluir fragmentos de plantillas dentro de cada uno, para elementos comunes como barras de navegación). Por ejemplo, supongamos que tiene una página que normalmente imprime cierta información si está conectado o un error si no es así. Con PHP, escribirías algo como:
if (loggedIn)
{
// print lots of HTML here
}
else
{
// print error message
}
En Smarty, podría ser algo como esto (perdona mi sintaxis probablemente incorrecta, ha pasado un tiempo):
if (loggedIn)
{
$smarty->bind("info", someObject);
$smarty->display("info.template");
}
else
$smarty->display("error.template");
Si fueras realmente inteligente, incluso podrías mostrar la plantilla de la página de inicio de sesión en lugar de la plantilla de error, opcionalmente con un mensaje explicando por qué el usuario terminó allí. Y si aplicaste la técnica tal como la escribí y luego decidiste que querías cambiar a la pantalla de inicio de sesión, ¡es solo un cambio de línea! Para mí, no se trata solo de mantener la separación de la vista y la lógica, sino también de la capacidad de reutilizar elementos comunes de la vista desde muchos lugares.
Me gusta usar plantillas por un par de razones:
1) Limpia la legibilidad del código PHP. Mis archivos PHP se vuelven hinchados y desvergonzados cuando hay instrucciones de impresión ("") con fragmentos de HTML en todas partes. Además, surgen problemas como ¿cómo se transfieren variables al texto HTML? ¿Usas etiquetas en todas partes? ¿Utiliza print ("") y escapa de sus citas HTML y concatena sus variables? ¿Usas print ("") y usas comillas simples en HTML, yendo en contra del estándar, e insertas tus variables directamente?
2) Limpia la presentación del código HTML. Puede ser difícil mantener su HTML generado en buen estado si se corta y piratea en varios archivos. Por ejemplo, su sangría puede obtener distancia.
3) Le permite crear múltiples plantillas, y luego un usuario conectado puede seleccionar qué plantilla / máscara desea mostrar cuando navega por su sitio web, y también puede cambiar rápidamente y sin esfuerzo la plantilla predeterminada a otra cosa si es así inclinado.
En general, es solo una mejor manera de organizar todo. Hay un poco de compromiso en tener que aprender y escribir comandos de clase de plantilla, abrir múltiples archivos, etc. Pero en mi opinión, creo que vale la pena porque la legibilidad y organización del código aumenta.
No creo que debas usar un motor de plantillas. En su lugar, debería usar algo como Zend_View que lo alienta a hacer una lógica separada de la presentación, pero le permite construir su capa de presentación en PHP.
Olvidó htmlspecialchars() dos veces. Es por eso que necesitas un sistema de plantillas.
Smarty es pobre. No juzgues los sistemas de plantillas basados en eso.
PHP es más o menos un sistema de plantillas. La clave es forzarse a separar la lógica de la presentación por su cuenta. Usar Smarty o algo así solo hace que sea un poco más inconveniente mezclar lógica y presentación. Si no puedes hacerte separar por tu cuenta, usar un sistema de plantillas no va a ayudar. Todo lo que va a hacer es consumir más potencia de procesamiento.
La clave es no alterar ningún valor en su código de presentación. Para hacer esto, creo que PHP es tan efectivo como Smarty si usas la sintaxis if / endif:
<?php if($some_test): ?>
<em>Some text!</em>
<?php endif; ?>
Personalmente siempre uso motores de plantillas en php, python o lo que sea.
La primera razón obvia ya mencionada por otros:
Te obliga a no usar ninguna lógica comercial en tus plantillas.
Sí, claro, la disciplina funcionaría bien, cuando la tengas.
Pero esto es solo un pequeño aspecto de por qué usarías un motor de plantillas . La mayoría de ellos son más que solo un motor y podrían considerarse marcos de plantillas, te guste o no.
Por ejemplo, Smarty también tiene funciones avanzadas de almacenamiento en caché, como el almacenamiento en caché parcial. Cosas realmente útiles, cosas que tendrías que hacer todo por ti mismo al usar solo php como lenguaje de plantillas.
Y por favor no olvides todas esas funciones de ayuda realmente útiles a solo una búsqueda rápida en los documentos. La mayoría de ellos también proporcionan una manera fácil de agregar sus propias funciones y / o conjunto de herramientas.
Entonces sí, es una cuestión de elección. Cuando necesite plantillas realmente simples, considere mostrar cierta disciplina para mantener su lógica fuera de sus plantillas. Pero cuando espera que su aplicación crezca, finalmente necesitará las características de la plantilla. Y para entonces, es de esperar que no reinventes la rueda codificándote todo tuyo.
Y por último, pero no por ello menos importante, para mí hay una función de asesino disponible en algunos frameworks de plantillas.
Herencia de plantilla
Lo llegué a conocer de Django y ahora lo estoy usando en el último Smarty 3 . Los chicos del framework Symphony también tienen Twig , que puedes considerar como un puerto con la sintaxis de Django.
Parece un poco extraño al principio, pero es extremadamente poderoso. Usted construye su esqueleto y define varios bloques. Puede extender dicho esqueleto y completar (anular) los bloques con su contenido.
Para mí, eso es un guardián!
Sí, como dijiste, si no te obligas a utilizar un motor de plantillas dentro de PHP (el motor de plantillas) es fácil deslizar y dejar de separar las preocupaciones.
Sin embargo , las mismas personas que tienen problemas para separar las preocupaciones terminan generando HTML y alimentándolo a smarty, o ejecutando código PHP en Smarty, por lo que Smarty difícilmente resuelve su problema de separación de preocupaciones.
Ver también:
Sobre todo, creo que para evitar cualquier lógica backend "inseguro" para ser aplicado en las plantillas. Dado que la mayoría de las veces las plantillas se entregan a los diseñadores, solo queremos darles un conjunto cerrado de cosas que pueden hacer.
Todavía hay una buena razón para utilizar un sistema de plantilla, aunque no Smarty, sino PHPTAL . Las plantillas PHPTAL son archivos XML (y por lo tanto XHTML) válidos. Puede seguir usando el contenido ficticio en PHPTAL y así obtener un archivo XHTML válido con la apariencia final, que puede ser procesado y probado con herramientas estándar. Aquí hay un pequeño ejemplo:
<table>
<thead>
<tr>
<th>First Name</th>
<th>Last Name</th>
<th>Age</th>
</tr>
</thead>
<tbody>
<tr tal:repeat="users user">
<td tal:content="user/first_name">Max</td>
<td tal:content="user/last_name">Mustermann</td>
<td tal:content="user/age">29</td>
</tr>
</tbody>
</table>
El motor de plantillas PHPTAL insertará automáticamente todos los valores de la matriz de usuarios y reemplazará nuestros valores ficticios. Sin embargo, la tabla ya es válida XHTML que se puede mostrar en un navegador de su elección.
Tu análisis es razonable. Supongo:
- Los diseñadores de plantillas y programadores de back-end pueden no ser uno en el mismo, por lo que promueve la separación.
- Te protege de ti de alguna manera porque no puedes hacer PHP "demasiado" en tus plantillas.
- ¿Puede ser más fácil optimizar / precompilar plantillas en algunos escenarios? (Esto es especulación)
Personalmente, creo que son más complicados de lo que valen. Particularmente no funcionan si quiere entregar las plantillas a los "diseñadores" ya que las herramientas WYSIWYG no saben qué hacer con ellas.
Una ventaja del motor de plantilla que no vi fue la posibilidad de elementos html dinámicos, algo así como los controles de asp.net. Por ejemplo, con HTML Template Flexy de PEAR, puede tener elementos de formulario dinámicos que automáticamente mantienen el estado. Un elemento de selección html regular puede completarse y tener el elemento seleccionado configurado en el código detrás sin bucles o condicionales en la plantilla.
Usar plantillas que no sean PHP con la excusa de separar la lógica es una tontería. Si el desarrollador no comprende qué es la separación lógica de la vista empresarial y cómo se debe hacer, entonces el problema debe abordarse de manera adecuada. De lo contrario, terminas con HTML en lógica comercial o lógica de negocios en plantillas: ningún motor de plantillas te va a salvar. Tienes que enseñarle al desarrollador los conceptos básicos.
Y si el desarrollador lo comprende, el sistema de plantillas es solo una limitación. No agrega ningún valor al proceso de desarrollo, solo la sobrecarga de aprender una nueva sintaxis, mantener otra biblioteca actualizada y una ejecución más lenta. Mientras que el último se puede resolver con caché y otras cosas, esto solo soluciona un problema que de otro modo no existiría. Entonces, los sistemas de plantillas no ofrecen ningún valor, ninguna ventaja en absoluto.
Sin embargo, hay una excepción en la que creo que usar un sistema de plantillas que no sea de PHP es razonable: cuando los programadores de view-logic deben tener acceso limitado a las plantillas. Por ejemplo, si usted es proveedor de un sistema de alojamiento de blogs y desea permitir que sus usuarios personalicen y codifiquen sus plantillas, sin permitirles ejecutar código arbitrario. Este argumento, sin embargo, no se aplica a los casos en que un diseñador está dispuesto a aprender un pequeño código para ayudar a programar la interfaz de usuario. Si puede aprender Smarty, seguramente puede aprender PHP.
Varias veces usé tinybutstrong , que tiene una sintaxis bastante clara y simple. No hay bucles o pseudocódigo en la plantilla html.
Desde su página de inicio:
TinyButStrong es una biblioteca que le permite crear dinámicamente páginas XML / HTML y cualquier otro archivo basado en fuente de texto. Es un motor de plantillas para el lenguaje PHP. Le permite visualizar fácilmente la información de su base de datos, pero también armonizar y simplificar seriamente su programación PHP.
TinyButStrong está orientado a HTML pero no está especializado en Html. Esto significa que puede funcionar también con archivos de texto, XML, RSS, RTF, WML, Excel (xml), ... El plug-in de OpenTBS le permite combinar documentos de OpenOffice y Ms Office.
Y no olvidemos el futuro. Los sitios web son viejos casi en el momento en que se publican. Deberá actualizar la apariencia en algún momento. Si mantiene la separación muchas veces, un diseñador solo puede completar un sitio web completamente nuevo con la misma programación en el back-end. Esto permite rediseños más rápidos y económicos, lo que le permite involucrar solo al programador si se requiere una nueva funcionalidad.
para mí, una de las principales características de los motores de plantillas es que la capa de caché es transparente para usted. He estado usando smarty hace mucho tiempo, y las cosas de caché hacen la vida más fácil. también el diseño inteligente le permite usar su propia función de caché. En mi caso elijo si para alguna página debería usar memcache o disco para almacenar la salida de la plantilla.
Por otro lado, si su sitio tiene un gran tráfico y usted no sabe cómo administrar smarty y sintonizarlo bien, cualquier motor de plantillas podría ser un asesino del sitio. pero incluso si no usa smarty, su sitio puede morir también.
flickr está usando actualmente smarty. no debería ser tan malo, ¿no?
sistema de gestión de plantillas, podemos gestionar los archivos de plantilla por separado. el tiempo de ejecución del sistema será más rápido que el proyecto PHP normal. así que aquí los archivos PHP y los archivos de plantilla se mantienen por separado.
una vez ejecutados los archivos, el código se guardará como template_c. entonces no se compila muchas veces.
- ¿Desea usar un archivo con código PHP como plantilla? Multa.
- ¿Quieres usar tus variables en dicha plantilla? Multa.
Solo recuerda separar la lógica y el resultado final (presentación). Esto se logra mejor con un marco de plantillas. Pero no tienes que aprender algo como Smarty.
- Si usa Zend_View o similar, puede usar el código PHP hasta el final.
Mucha gente aquí tiene la respuesta correcta. Smarty no está creando plantillas en PHP. Lejos de ahi. Smarty está allí principalmente para aquellos que tienen que usar diseñadores (es decir, no programadores) para editar y configurar la visualización de páginas. Si todos los que van a cambiar el diseño de sus páginas pueden programar, puede ir con un sistema de plantillas más orientado al código PHP. Pero realmente debería tener listos todos sus datos de salida y enviarlos a la plantilla. Si deja que cada página busque, procese y muestre el contenido, tendrá que refactorizarlo más pronto que tarde.