14.3. Configuración del generador

El archivo de configuración del generador es muy poderoso, ya que permite modificar la administración generada automáticamente de muchas formas. Lo único malo de que tenga tantas posibilidades es que la descripción completa de su sintaxis es muy larga de leer y cuesta aprenderla, por lo que este capítulo es uno de los más largos del libro.

Los ejemplos de esta sección modifican el módulo de administración articulo y también el módulo comentario basado en la definición de la clase BlogComentario. Antes de modificar el módulo comentario, es necesario crear su ruta y después crear el módulo mediante la tarea propel:generate-admin:

$ php symfony propel:generate-admin backend BlogComentario --module=comentario

Figura 14.4 Chuleta del generador de administraciones

14.3.1. Campos

Por defecto, las columnas de la vista list son las columnas definidas en el archivo schema.yml. Los campos de las vistas new y edit son los que define el formulario asociado con el modelo (BlogArticuloForm). El archivo generator.yml permite seleccionar los campos que se muestran y los que se ocultan. También permite añadir campos propios, incluso aunque no existan en el modelo de objetos.

14.3.2. Opciones de los campos

El generador de la administración crea un field para cada columna del archivo schema.yml. Bajo la clave fields se puede definir la forma en la que se muestra cada campo, su formato, etc. El ejemplo que se muestra en el listado 14-5 define el título y atributo class del campo titulo y el título y mensaje de ayuda del campo contenido. Las siguientes secciones describen en detalle cómo funciona cada opción.

Listado 14-5 - Establecer parámetros a las columnas

config:
  fields:
    titulo:
      label: Título del artículo
      attributes: { class: mi_clase_css }
    contenido: { label: Cuerpo del artículo, help: Rellena el cuerpo del artículo }

Además de las opciones globales para todas las vistas, se pueden redefinir las opciones de la clave fields para cada una de las vistas (list, filter, form, new y edit) tal y como muestra el listado 14-6.

Listado 14-6 - Redefiniendo las opciones globales en cada vista

config:
  fields:
    titulo:    { label: Título del artículo }
    contenido: { label: Cuerpo }

  list:
    fields:
      titulo:  { label: Título }

  form:
    fields:
      contenido: { label: Cuerpo del artículo }

Este ejemplo se puede tomar como una regla general: cualquier opción establecida para todo el módulo mediante la clave fields, se puede redefinir en la configuración de cualquier vista. A continuación se indican las normas que se siguen al redefinir las opciones:

• new y edit heredan de form, que a su vez hereda de fields
• list hereda de fields
• filter hereda de fields

14.3.2.1. Mostrando nuevos campos

La sección fields permite definir para cada vista los campos que se muestran, los que se ocultan, la forma en la que se agrupan y las opciones para ordenarlos. Para ello se emplea la clave display. El código del listado 14-7 reordena los campos del módulo comentario:

Listado 14-7 - Seleccionando los campos que se muestran, en modules/comentario/config/generator.yml

config:
  fields:
    articulo_id: { label: Artículo }
    created_at:  { label: Fecha de publicación }
    contenido:   { label: Cuerpo }

  list:
    display:     [id, blog_articulo_id, contenido]

  form:
    display:
      NONE:      [blog_articulo_id]
      Editable:  [autor, contenido, created_at]

Con esta configuración, la vista list muestra tres columnas, como se ve en la figura 14-5 y el formulario de las vistas new y edit muestran cuatro campos agrupados en dos secciones, como se ve en la figura 14-6.

Figura 14.5 Columnas seleccionadas para la vista "list" del módulo "comentario"

Figura 14.6 Agrupando campos en la vista "edit" del módulo "comentario"

De esta forma, la opción display tiene dos propósitos:

• En la vista list: crea un array simple con el nombre de los campos para seleccionar las columnas que se muestran y el orden en el que lo hacen.
• En las vistas form, new y edit: crea un array asociativo cuya clave es el nombre del grupo o NONE para definir un grupo sin nombre. Las columnas también se indican mediante un array simple con los nombres de los campos en el mismo orden en el que se van a mostrar. Si no se incluyen todos los campos obligatorios referenciados en la clase del formulario, se producen errores de validación (ver Capítulo 10).

14.3.2.2. Campos propios

Los campos que se configuran en el archivo generator.yml no tienen que corresponderse obligatoriamente con alguna de las columnas del esquema de datos. Si la clase relacionada incluye un método getter para el campo propio, este se puede utilizar como un campo más de la vista list; si además del getter existe un método setter, el campo también se puede utilizar en la vista edit. En el listado 14-8 se muestra un ejemplo que extiende el modelo de BlogArticulo para añadir el método getNumeroComentarios() que obtiene el número de comentarios de un artículo.

Listado 14-8 - Añadiendo un getter propio en el modelo, en lib/model/BlogArticulo.php

public function getNumeroComentarios()
{
  return $this->countBlogComentarios();
}

Una vez definido este getter, el campo numero_comentarios está disponible como campo del módulo generado (el getter utiliza como nombre la habitual transformación camelCase del nombre del campo) como se muestra en el listado 14-9.

Listado 14-9 - Los getters propios permiten añadir más columnas a los módulos de administración, en backend/modules/articulo/config/generator.yml

config:
  list:
    display: [titulo, blog_autor, blog_categoria, numero_comentarios]

La vista list resultante se muestra en la figura 14-7

Figura 14.7 Campo propio en la vista "list" del módulo "articulo"

14.3.2.3. Campos parciales

El código del modelo debe ser independiente de su presentación. De hecho, si el método de un campo propio genera código HTML, este código se muestra pero no se interpreta, ya que Symfony le aplica por defecto el mecanismo de escape. Una buena práctica consiste en generar el código HTML del campo propio mediante un elemento parcial. Afortunadamente, el generador de la administración permite utilizar elementos parciales si la declaración del nombre del campo contiene un guión bajo como primer carácter. De esta forma, el archivo generator.yml del listado 14-9 debería modificarse para ser como el del listado 14-12.

Listado 14-12 - Se pueden utilizar elementos parciales como campos, mediante el uso del prefijo _

config:
  list:
    display: [titulo, blog_autor, blog_categoria, _numero_comentarios]

Para que funcione la configuración anterior, es necesario crear un elemento parcial llamado _numero_comentarios.php en el directorio modules/comentario/templates/, tal y como muestra el listado 14-13.

Listado 14-3 - Elemento parcial para la vista list del ejemplo, en modules/comentario/templates/_numero_comentarios.php

<strong><?php echo $BlogArticle->getNumeroComentarios() ?></strong>

La plantilla de un elemento parcial tiene acceso al objeto actual mediante una variable que se llama igual que la clase ($BlogArticle en este ejemplo).

Figura 14.8 Elemento parcial en la vista "list" del módulo "articulo"

Si quieres definir los parámetros de un elemento parcial, utiliza la misma sintaxis que para los campos normales. Indica los parámetros bajo la clave field y no incluyas el guión bajo (_) delante del nombre del campo. El listado 14-14 muestra un ejemplo.

Listado 14-14 - Las propiedades de un elemento parcial se pueden definir bajo la clave fields

config:
  fields:
    numero_comentarios: { label: Número de comentarios }

Si el código del elemento parcial crece demasiado, es recomendable sustituirlo por un componente. Para definir un campo basado en un componente, solamente es necesario reemplazar el prefijo _ por el prefijo ~, como muestra el listado 14-17.

Listado 14-17 - Se pueden utilizar componentes en los campos, mediante el prefijo ~

config:
  list:
    display: [titulo, blog_autor, blog_categoria, ~numero_comentarios]

En la plantilla que se genera, la configuración anterior resulta en una llamada al componente numeroComentarios del módulo actual.

14.3.3. Modificando la vista

Si se quiere modificar el aspecto visual de las vistas new, edit y list, no se deben modificar las plantillas. Como se generan automáticamente, no es una buena idea modificarlas. En su lugar, se debe utilizar el archivo de configuración generator.yml, porque puede hacer prácticamente cualquier cosa que se necesite sin tener que sacrificar la modularidad de la aplicación.

14.3.3.1. Modificando el título de la vista

Además de una serie de campos propios, las páginas list, new y edit pueden mostrar un título específico. El listado 14-16 muestra cómo modificar el título de las vistas del módulo articulo. La vista edit resultante se ilustra en la figura 14-9.

Listado 14-16 - Estableciendo el título de cada vista, en backend/modules/articulo/config/generator.yml

config:
  list:
    title: Lista de artículos

  new:
    title: Nuevo artículo

  edit:
    title: Editar artículo %%titulo%% (%%id%%)

Figura 14.9 Título propio en la vista "edit" del módulo "articulo"

Como los títulos por defecto utilizan el nombre de cada clase, normalmente no es necesario modificarlos (siempre que el modelo utilice nombres de clase explícitos).

14.3.3.2. Añadiendo mensajes de ayuda

En las vistas list, new y edit, se pueden añadir "tooltips" o mensajes de ayuda para describir los campos que se muestran en los formularios. El listado 14-17 muestra como añadir un mensaje de ayuda para el campo blog_articulo_id en la vista edit del módulo comentario. Para ello, se utiliza la propiedad help bajo la clave fields. El resultado se muestra en la figura 14-10.

Listado 14-17 - Añadiendo un mensaje de ayuda en la vista edit, en modules/comentario/config/generator.yml

config:
  edit:
    fields:
      blog_articulo_id: { help: Este comentario pertenece a este artículo }

Figura 14.10 Mensaje de ayuda en la vista "edit" del módulo "comentario"

En la vista list, los mensajes de ayuda se muestran en la cabecera de la columna; en las vistas new, edit y filter, los mensajes se muestran debajo de cada cuadro de texto.

14.3.3.3. Modificando el formato de la fecha

Las fechas se pueden mostrar siguiendo un formato propio si se utiliza la opción date_format, tal y como se muestra en el listado 14-18.

Listado 14-18 - Dando formato a la fecha en la vista list

config:
  list:
    fields:
      created_at: { label: Fecha de publicación, date_format: dd/MM }

La sintaxis que se utiliza es la misma que la del helper format_date() descrito en el capítulo anterior.

generator:
  class: sfPropelGenerator
  param:
    i18n_catalogue: admin

14.3.4. Opciones específicas para la vista list

La vista list' puede mostrar la información de cada fila en varias columnas o de forma conjunta en una sola línea. También puede mostrar opciones para filtrar los resultados, paginación de resultados y opciones para ordenar los datos. Todas estas opciones se pueden modificar mediante los archivos de configuración, como se muestra en las siguientes secciones.

14.3.4.1. Modificando el layout

Por defecto, la unión entre la vista list y la vista edit se realiza mediante la columna que muestra la clave primaria. Si se observa de nuevo la figura 14-8, se ve que la columna id de la lista de comentarios no solo muestra la clave primaria de cada comentario, sino que incluye un enlace que permite a los usuarios acceder de forma directa a la vista edit.

Si se quiere mostrar en otra columna el enlace a los datos detallados, se añade el prefijo = al nombre de la columna que se utiliza en la clave display. El listado 14-19 elimina la columna id de la vista list de los comentarios y establece el enlace en el campo contenido. La figura 14-11 muestra el resultado de este cambio.

Listado 14-19 - Cambiando el enlace a la vista edit en la vista list, en modules/comentario/config/generator.yml

config:
  list:
    display:    [id, =contenido]

Figura 14.11 Estableciendo el enlace a la vista edit en otra columna, en la vista list del módulo comentario

La vista list muestra por defecto todos sus datos en varias columnas. También es posible mostrar de forma seguida todos los datos en una sola cadena de texto que ocupe toda la anchura de la tabla. El aspecto con el que se muestran los datos se denomina "layout" y la forma en la que se muestran todos seguidos se denomina stacked. Si se utiliza el layout stacked, la clave params debe contener el patrón que define el orden en el que se muestran los datos. El listado 14-20 muestra por ejemplo el layout deseado para la vista list del módulo comentario. La figura 14-12 ilustra el resultado final.

Listado 14-20 - Uso del layout stacked en la vista list, en modules/comentario/config/generator.yml

config:
  list:
    layout:  stacked
    params:  |
      %%=contenido%%<br />
      (escrito por %%autor%% el %%created_at%% y relacionado con %%_article_link%%)
    display:  [created_at, autor, contenido]

Figura 14.12 Layout "stacked" en la vista "list" del módulo "comentario"

El layout normal en varias columnas requiere un array con el nombre de los campos en la clave display; sin embargo, el layout stacked requiere que la clave params incluya el código HTML que se utilizará para mostrar cada fila de datos. No obstante, el array de la clave display también se utiliza en el layout stacked para determinar las cabeceras de columnas disponibles para reordenar los datos mostrados.

14.3.4.2. Filtrando los resultados

En la vista de tipo list, se pueden añadir fácilmente una serie de filtros. Con estos filtros, los usuarios pueden mostrar menos resultados y pueden obtener más rápidamente los que están buscando. Los filtros se configuran mediante un array con los nombres de los campos en la clave filter. El listado 14-21 muestra como incluir un filtro según los campos blog_articulo_id, autor y created_at en la vista list del módulo comentario, y la figura 14-13 ilustra el resultado.

Listado 14-21 - Incluyendo filtros en la vista list, en modules/comentario/config/generator.yml

config:
  list:
    layout:  stacked
    params:  |
      %%=contenido%% <br />
      (escrito por %%autor%% el %%created_at%% y relacionado con %%_article_link%%)
    display:  [created_at, autor, contenido]

  filter:
    display: [blog_articulo_id, autor, created_at]

Figura 14.13 Filtros en la vista "list" del módulo "comentario"

Los filtros que muestra Symfony dependen del tipo de columna definido en el esquema de datos y se pueden modificar en la clase de los filtros del formulario:

• Para las columnas de texto (como el campo autor en el módulo comentario), el filtro es un cuadro de texto que permite realizar búsquedas textuales (los comodines se añaden automáticamente).
• Para las claves externas (como el campo blog_articulo_id en el módulo comentario), el filtro es una lista desplegable con los datos de la columna correspondiente en la tabla asociada. Por defecto, las opciones de la lista desplegable son las que devuelve el método __toString() de la clase relacionada.
• Para las fechas (como el campo created_at en el módulo comentario), el filtro está formado por un par de elementos para seleccionar fechas, de forma que se pueda indicar un intervalo temporal.
• Para las columnas booleanas, el filtro muestra una lista desplegable con los valores true, false y true or false (la última opción es para reinicializar el filtro).

Al igual que las vistas new y edit están relacionadas con la clase de un formulario, los filtros utilizan la clase del formulario de filtros asociado por defecto con el modelo (como por ejemplo BlogArticuloFormFilter para el modelo BlogArticulo). Si defines tu propia clase para el formulario de filtros, puedes personalizar los campos de los filtros aprovechando todas las opciones del framework de formularios y utilizando todos los widgets disponibles. Como muestra el listado 14-22, utilizar un filtro propio es tan sencillo como indicar la opción class dentro de la sección filter.

Listado 14-22 - Personalizando la clase del formulario utilizado para los filtros

config:
  filter:
    class: BackendArticuloFormFilter

También puedes hacer uso de elementos parciales para añadir tu propia lógica en los filtros. Cada elemento parcial recibe como argumentos form y attributes que se utilizan para mostrar el elemento del formulario. El listado 14-23 muestra un ejemplo que utiliza elementos parciales para obtener el mismo comportamiento que el de por defecto.

Listado 14-23 - Utilizando un elemento parcial como filtro

// El elemento parcial se define en templates/_estado.php
<?php echo $form[$nombre]->render($attributes->getRawValue()) ?>

// Se añade el filtro parcial en la lista de filtros de config/generator.yml
config:
  filter: [created_at, _estado]

14.3.4.3. Ordenando el listado

Como muestra la figura 14-18, en la vista list las columnas que forman la cabecera de la tabla son enlaces que se pueden utilizar para reordenar los datos del listado. Las cabeceras se muestran tanto en el layout normal como en el layout stacked. Al pinchar en cualquiera de estos enlaces, se recarga la página añadiendo un parámetro sort que permite reordenar los datos de forma adecuada.

Figura 14.14 Las cabeceras de la tabla de la vista "list" permiten reordenar los datos

Se puede utilizar la misma sintaxis que emplea Symfony para incluir un enlace que apunte directamente a los datos ordenados de una forma determinada:

<?php echo link_to('Listado de comentarios ordenados por fecha', '@blog_comentario?sort=created_at&sort_type=desc' ) ?>

También es posible indicar en el archivo generator.yml el orden por defecto para la vista list mediante el parámetro sort. El listado 14-24 muestra un ejemplo de la sintaxis que debe utilizarse.

Listado 14-24 - Estableciendo un orden por defecto en la vista list

config:
  list:
    sort:   created_at
    # Sintaxis alternativa para indicar la forma de ordenar
    sort:   [created_at, desc]

14.3.4.4. Modificando la paginación

La administración generada automáticamente tiene en cuenta la posibilidad de que las tablas contengan muchos datos, por lo que la vista list incluye por defecto una paginación de datos. Si el número total de filas de la tabla es mayor que el número máximo de filas por página, entonces aparece la paginación al final del listado. La figura 14-15 muestra el ejemplo de un listado con 6 comentarios de prueba para el que el número máximo de comentarios por página es de 5. La paginación de datos asegura un buen rendimiento a la aplicación, porque solamente se obtienen los datos de las filas que se muestran, y permite una buena usabilidad, ya que hasta las filas que contienen millones de filas se pueden manejar con el módulo de administración.

Figura 14.15 La paginación se muestra cuando el listado es muy largo

El número máximo de filas que se muestran en cada página se controla mediante la opción max_per_page:

config:
  list:
    max_per_page:   5

14.3.4.5. Mejorando el rendimiento mediante una Join

El generador de la administración utiliza por defecto el método doSelect() para obtener las filas de datos. Sin embargo, si se utilizan objetos relacionados en el listado, el número de consultas a la base de datos puede aumentar demasiado. Si se quiere mostrar por ejemplo el nombre del artículo en el listado de comentarios, se debe hacer una consulta adicional por cada comentario para obtener el objeto BlogArticulo relacionado. Afortunadamente, se puede indicar al paginador que utilice un método específico tipo doSelectJoinXXX() para optimizar el número de consultas necesario. La opción peer_method es la encargada de indicar el método a utilizar.

config:
  list:
    peer_method: doSelectJoinBlogArticulo

En el Capítulo 18 se explica más detalladamente el concepto de Join.

14.3.5. Opciones específicas para las vistas new y edit

Las vistas new y edit permiten al usuario modificar el valor de cualquier columna de un registro nuevo o existente de la base de datos. Por defecto, el formulario utilizado por el generador de la parte de administración es el formulario asociado con el modelo: BlogArticuloForm para el modelo BlogArticulo. Si quieres utilizar una clase propia, puedes indicarlo en la opción class de la sección form, tal y como muestra el listado 14-25.

Listado 14-25 - Utilizando una clase de formulario propia en las vistas new y edit

config:
  form:
    class: BackendBlogArticuloForm

Si se emplea una clase de formulario propia, es posible modificar todos los widgets y validadores utilizados por el generador de la parte de administración. Además, en este caso la clase de formulario por defecto se puede utilizar y modificar para su uso específico en la aplicación frontend.

El listado 14-26 muestra cómo personalizar los títulos, mensajes de ayuda y layout del formulario directamente desde el archivo de configuración generator.yml.

Listado 14-26 - Modificando el aspecto del formulario

config:
  form:
    display:
      NONE:     [articulo_id]
      Editable: [autor, contenido, created_at]
    fields:
      contenido:  { label: cuerpo, help: "El contenido del artículo se puede escribir con el formato Markdown" }

14.3.5.1. Manejando los campos parciales

Las vistas new y edit pueden utilizar los mismos elementos parciales que se emplean en las vistas de tipo list.

14.3.6. Trabajando con claves externas

Si el esquema de la aplicación define relaciones entre tablas, los módulos generados para la administración pueden aprovechar esas relaciones para automatizar aun más los campos, simplificando enormemente la gestión de las relaciones entre tablas.

14.3.6.1. Relaciones uno-a-muchos

El generador de la administración se ocupa automáticamente de las relaciones de tipo 1-n entre tablas. Como se muestra en la figura 14-1, la tabla blog_comentario se relaciona con la tabla blog_articulo mediante el campo blog_articulo_id. Si se utiliza el generador de administraciones para iniciar el módulo de la clase BlogComentario, la acción edit muestra automáticamente el campo blog_articulo_id como una lista desplegable con los valores de los id de todas las filas de datos de la tabla blog_articulo (observa de nuevo la figura 14-9).

La explicación anterior también es aplicable si quieres mostrar la lista de comentarios relacionados con un artículo en el módulo articulo (relación n-1).

14.3.6.2. Relaciones muchos-a-muchos

Symfony también se encarga de las relaciones n-n, como se muestra en la figura 14-16.

Figura 14.16 Relaciones muchos a muchos

Personalizando el widget utilizado para mostrar este tipo de relación, se puede modificar la forma en la que se muestra el campo (ver figura 14-17):

Figura 14.17 Tipos de campos especiales disponibles para la gestión de las relaciones muchos-a-muchos

14.3.7. Añadiendo nuevas interacciones

Los módulos de administración permiten a los usuarios realizar las operaciones CRUD habituales, aunque también es posible añadir otras interacciones diferentes o restringir las interacciones disponibles en una vista. La configuración que se muestra en el listado 14-27 habilita todas las operaciones CRUD habituales para el módulo articulo.

Listado 14-27 - Definiendo las interacciones de cada vista, en backend/modules/articulo/config/generator.yml

config:
  list:
    title:          Listado de Artículos
    object_actions:
      _edit:         ~
      _delete:       ~
    batch_actions:
      _delete:       ~
    actions:
      _new:          ~

  edit:
    title:          Cuerpo del artículo %%titulo%%
    actions:
      _delete:       ~
      _list:         ~
      _save:         ~
      _save_and_add: ~

En la vista de tipo list, existen tres opciones relacionadas con las acciones: la lista de las acciones disponibles para todos los objetos (object_actions), la lista de opciones disponibles para una selección de objetos (batch_actions) y la lista de acciones disponibles para la página entera (actions). La lista de interacciones definidas en el listado 14-27 producen el resultado de la figura 14-18. Cada fila de datos muestra un botón para modificar la información y un botón para eliminar ese registro, además de un checkbox en cada fila para poder borrar varios elementos seleccionados. Al final de la lista se muestra un botón para crear nuevos elementos.

Figura 14.18 Interacciones de la vista "list"

En las vistas new y edit, como sólo se modifica un registro de datos cada vez, solamente se define un conjunto de acciones (en actions). Las interacciones definidas en el listado 14-27 se muestran con el aspecto de la figura 14-23. Tanto la acción save (guardar) como la acción save_and_add (guardar_y_añadir) guardan los cambios realizados en los datos. La única diferencia es que la acción save vuelve a mostrar la vista edit con los nuevos datos y la acción save_and_add muestra la vista new para añadir otro elemento. Por tanto, la acción save_and_add es un atajo muy útil cuando se están añadiendo varios elementos de forma consecutiva. El botón de la acción delete (borrar) se encuentra lo suficientemente alejado de los otros dos botones como para que no sea pulsado por accidente.

Los nombres de las interacciones que empiezan con un guión bajo (_) son reconocidos por Symfony y por tanto, utilizan el mismo icono y realizan la misma acción que las interacciones por defecto. El generador de la administración es capaz de reconocer las acciones _edit, _delete, _new, _list, _save, _save_and_add y _create.

Figura 14.19 Interacciones de la vista "edit"

También es posible definir interacciones propias, para lo que se debe especificar un nombre que no empiece por guión bajo y una acción del módulo actual, tal y como se muestra en el listado 14-28.

Listado 14-28 - Definiendo una interacción propia

list:
  title:          Listado de Artículos
  object_actions:
    _edit:        -
    _delete:      -
    comentar:     { label: Añade un comentario, action: comentar }

Ahora, cada artículo que aparece en el listado muestra un enlace con el texto Añade un comentario, tal y como se muestra en la figura 14-20. Al pinchar sobre ese enlace, se ejecuta la acción comentar() del módulo actual. La clave primaria del objeto relacionado se pasa automáticamente a los parámetros de la petición que se produce.

Figura 14.20 Interacciones propias en la vista "list"

La acción comentar puede ser tan sencilla como la que muestra el listado 14-29.

Listado 14-29 - Acción para una interacción propia, en actions/actions.class.php

public function executeComentar($request)
{
  $comentario = new BlogComentario();
  $comentario->setArticuloId($request->getParameter('id'));
  $comentario->save();

  $this->redirect('blog_comentario_edit', $comentario);
}

Las acciones de tipo batch reciben un array con todas las claves primarias de las filas seleccionadas a través de un parámetro de petición llamado id.

Por último, si se quieren eliminar todas las acciones para una determinada vista, se utiliza una lista vacía como la del listado 14-30.

Listado 14-30 - Eliminando todas las acciones en la vista list

config:
  list:
    title:   Listado de Artículos
    actions: {}

14.3.8. Validación de formularios

La validación de datos se realiza de forma automática en el formulario utilizado en las vistas new y edit. Si se quiere personalizar la validación, se deben modificar las clases correspondientes de cada formulario.

14.3.9. Restringiendo las acciones del usuario mediante credenciales

Los campos y las interacciones disponibles en un módulo de administración pueden variar en función de las credenciales del usuario conectado (el Capítulo 6 describe las opciones de seguridad de Symfony).

Los campos definidos en el generador pueden incluir una opción credentials para restringir su acceso solamente a los usuarios con la credencial adecuada. Esta característica se puede utilizar en la vista list. Además, el generador puede ocultar algunas interacciones en función de la credenciales del usuario. El listado 14-31 muestra estas opciones.

Listado 14-31 - Utilizando credenciales en generator.yml

config:
  # La columna id solamente se muestra para los usuarios con la credencial "admin"
  list:
    title:          Listado de Artículos
    display:        [id, =titulo, contenido, numero_comentarios]
    fields:
      id:           { credentials: [admin] }

  # La acción "comentar" se restringe a los usuarios con la credencial "admin"
  actions:
    comentar: { credentials: [admin] }