Un buen ejemplo de lo comentado anteriormente es el framework de formularios. Se trata de uno de los componentes más poderosos de Symfony y te proporciona un gran control sobre los formularios gracias al uso de objetos PHP tanto para mostrarlos como para validarlos. Lo mejor de los formularios de Symfony es que el programador puede encapsular una gran cantidad de lógica compleja dentro de una clase de formulario para reutilizarla y extenderla después en muchos otros proyectos.
No obstante, desde el punto de vista del diseñador de las plantillas de la aplicación puede resultar muy complicado tratar de entender esta abstracción encargada de mostrar los formularios. Si se considera el siguiente formulario:
Figura 14.1 Formulario en su estado inicial
A continuación se muestra el código de la clase que crea ese formulario:
// lib/form/CommentForm.class.php
class CommentForm extends BaseForm
{
public function configure()
{
$this->setWidget('body', new sfWidgetFormTextarea());
$this->setValidator('body', new sfValidatorString(array(
'min_length' => 12,
)));
}
}El formulario se muestra en la plantilla PHP de la siguiente forma:
<!-- apps/frontend/modules/main/templates/indexSuccess.php -->
<form action="#" method="post">
<ul>
<li>
<?php echo $form['body']->renderLabel() ?>
<?php echo $form['body'] ?>
<?php echo $form['body']->renderError() ?>
</li>
</ul>
<p><button type="submit">Post your comment now</button></p>
</form>El diseñador de las plantillas tiene bastante control sobre cómo se muestra el formulario. Puede modificar por ejemplo los títulos por defecto para que sean un poco más apropiados:
<?php echo $form['body']->renderLabel('Please enter your comment') ?>También puede añadir una clase CSS en los campos del formulario:
<?php echo $form['body']->render(array('class' => 'comment')) ?>Estas modificaciones son sencillas y bastante intuitivas. Sin embargo, ¿qué sucede si el diseñador quiere modificar un mensaje de error?
Figura 14.2 Formulario con errores
El método ->renderError() no admite ningún argumento, así que el diseñador
debería acceder a la clase del formulario, buscar el código asociado al validador
correspondiente y modificar su constructor para asociar los nuevos mensajes de
error con los códigos de error adecuados.
En este ejemplo, el diseñador de las plantillas debería hacer el siguiente cambio:
// antes
$this->setValidator('body', new sfValidatorString(array(
'min_length' => 12,
)));
// después
$this->setValidator('body', new sfValidatorString(array(
'min_length' => 12,
), array(
'min_length' => 'You haven\'t written enough',
)));¿Has visto el error? Hemos escrito una comilla simple dentro de una cadena de texto delimitada por esas mismas comillas. Evidentemente un programador como tu nunca cometería ese error, pero es muy posible que un diseñador de plantillas cometa este tipo de errores.
De hecho, ¿crees que un diseñador de plantillas es capaz de encontrar el lugar exacto en el que se definen los mensajes de error? ¿Es realista pensar que un diseñador va a saber los parámetros que se deben pasar al constructor de un validador?
Obviamente la respuesta a todas las preguntas anteriores es negativa. Los diseñadores hacen un trabajo muy valioso pero no es razonable esperar que alguien que no es programador aprenda el funcionamiento interno del framework de formularios de Symfony.