En las secciones anteriores se ha personalizado la ruta de la acción show
del módulo job
, pero las URL del resto de métodos (index
, new
, edit
, create
, update
y delete
) siguen utilizando la ruta default
:
default:
url: /:module/:action/*
La ruta default
es muy útil para empezar a programar sin preocuparse de tener que definir muchas rutas. Pero como esta ruta es totalmente genérica y está preparada para aceptar cualquier cosa, no se puede configurar para nuestras necesidades específicas.
Como todas las acciones del módulo job
están relacionadas con la clase JobeetJob
del modelo, se puede definir una ruta de tipo sfPropelRoute
para cada una de la misma forma que hemos hecho en la acción show
. No obstante, como el módulo job
incluye las siete acciones típicas que se realizan sobre los datos del modelo, también podemos utilizar la clase sfPropelRouteCollection. Por tanto, modifica el archivo routing.yml
de forma que tenga el siguiente contenido:
# apps/frontend/config/routing.yml
job:
class: sfPropelRouteCollection
options: { model: JobeetJob }
job_show_user:
url: /job/:company_slug/:location_slug/:id/:position_slug
class: sfPropelRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: show }
requirements:
id: \d+
sf_method: [get]
# default rules
homepage:
url: /
param: { module: job, action: index }
default_index:
url: /:module
param: { action: index }
default:
url: /:module/:action/*
La ruta job
anterior en realidad es un atajo para que se generen automáticamente las siguientes siete rutas de tipo sfPropelRoute
:
job:
url: /job.:sf_format
class: sfPropelRoute
options: { model: JobeetJob, type: list }
param: { module: job, action: index, sf_format: html }
requirements: { sf_method: get }
job_new:
url: /job/new.:sf_format
class: sfPropelRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: new, sf_format: html }
requirements: { sf_method: get }
job_create:
url: /job.:sf_format
class: sfPropelRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: create, sf_format: html }
requirements: { sf_method: post }
job_edit:
url: /job/:id/edit.:sf_format
class: sfPropelRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: edit, sf_format: html }
requirements: { sf_method: get }
job_update:
url: /job/:id.:sf_format
class: sfPropelRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: update, sf_format: html }
requirements: { sf_method: put }
job_delete:
url: /job/:id.:sf_format
class: sfPropelRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: delete, sf_format: html }
requirements: { sf_method: delete }
job_show:
url: /job/:id.:sf_format
class: sfPropelRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: show, sf_format: html }
requirements: { sf_method: get }
Nota Algunas rutas generadas por sfPropelRouteCollection
tienen exactamente la misma URL. El sistema de enrutamiento es capaz de diferenciarlas porque todas tienen diferentes métodos en la opción requirements
.
Las rutas job_delete
y job_update
utilizan métodos de HTTP que todavía no están soportados en los navegadores (DELETE
y PUT
respectivamente). Por tanto, Symfony no tiene más remedio que simular estos métodos utilizando un truco. Si abres la plantilla _form.php
verás un ejemplo de cómo se hace:
// apps/frontend/modules/job/templates/_form.php
<form action="..." ...>
<?php if (!$form->getObject()->isNew()): ?>
<input type="hidden" name="sf_method" value="PUT" />
<?php endif; ?>
<?php echo link_to(
'Delete',
'job/delete?id='.$form->getObject()->getId(),
array('method' => 'delete', 'confirm' => 'Are you sure?')
) ?>
Los helpers de Symfony pueden simular cualquier método HTTP mediante un parámetro especial llamado sf_method
.
Nota Además de sf_method
, Symfony dispone de otros parámetros especiales cuyo nombre siempre empieza por sf_
. Las rutas generadas automáticamente en el código anterior tienen otro parámetro especial llamado sf_format
, que se explicará más adelante.