2008-09-24 19 views
6

Usando Rails v2.1, digamos que tiene una acción para un controlador al que se puede acceder desde más de una ubicación. Por ejemplo, dentro de la aplicación Rails, tiene un enlace para editar un usuario desde dos vistas diferentes, una en la vista de índice de los usuarios y otra desde otra vista (digamos desde la barra de navegación en cada página).¿La mejor manera de redireccionar condicional?

Me pregunto cuál es la mejor manera de redirigir al usuario al lugar correcto dependiendo del enlace en el que hicieron clic. Por ejemplo:

Ejemplo 1:

  1. Lista de todos los usuarios
  2. Haga clic en "Editar" en un usuario en la lista
  3. usuario hace clic en "Guardar" en la forma, el controlador vuelve a dirigir de nuevo a 1 .

Ejemplo 2:

  1. EL CO usuario ld estar en cualquier página dentro de la aplicación, la barra de navegación muestra un enlace para editar el usuario actual
  2. El usuario hace clic en el enlace para editar
  3. El usuario hace clic en "guardar" en el formulario, el controlador redirige a la página estaban encendidos cuando el usuario hizo clic en el enlace "editar" en la barra de navegación.

que he visto hacer en el pasado por:

  1. La colocación de un parámetro en el enlace Editar original con el original controlador/acción en la que apareció el enlace. Para hacer esto más SECO, podría usar @ controller.controller_name y @ controller.action_name en un helper.
  2. El controlador guarda los parámetros en una variable de sesión.
  3. Una vez que el controlador ha guardado el registro, lo redirige a la variable de sesión.

Lo que no me gusta particularmente acerca de esta solución es la necesidad de agregar el parámetro a cada enlace aplicable en las vistas. Me pregunto si hay una manera de construir todo esto en el controlador.

Una mejor manera de que estaba pensando era:

  1. Coloque un before_filter en la acción "editar" para salvar la de referencia (es esto lo suficientemente fiable?) En la sesión.
  2. Cuando se golpea "update", el controlador redirigirá a la variable de sesión y luego elimina la variable de sesión.

¿Alguna idea sobre la mejor manera de hacerlo?

Respuesta

1

Creo que el uso de before_filter en la acción de edición es lo menos molesto.

El referente debería ser lo suficientemente confiable ... simplemente tener un valor predeterminado en el caso de que no haya disponible referencia (digamos: alguien haya marcado la página de edición) y debería estar bien.

2

Flash: Los datos que utilizará solo para la siguiente solicitud se pueden almacenar en el flash. Entonces no tienes que ir a limpiarlo automáticamente. Funciona bien para partes limitadas del contexto de la aplicación que seguramente solo necesitará una vez, ¡no solo para mensajes de error!

Sé lo que hiciste al último acceso HTTP: Si solo necesitas redirigir a las personas a la última URL en la que estaban, entonces hazlo. request.referer, para la mayoría de los navegadores que no bloquean la información, le proporciona la última URL en la que se encontraba la persona.

#in edit controller 
... 
flash[:page_to_redirect_to] = request.referer || "/my/default/path" 
... 

#in save controller 
redirect_to flash[:page_to_redirect_to] || "/my/default/path" 

No recomendaría la codificación rígida de esos, por cierto.

before_filter: Veo a muchos desarrolladores de Rails usar esto como su martillo favorito y convertir todo lo demás en clavos. Los filtros son útiles cuando desea exponer la funcionalidad a todos o sustancialmente todos los métodos en un controlador. No sé si ese es necesariamente el caso aquí, pero su millaje puede variar. Puede combinar el filtro con los dos trucos anteriores si está justificado.

+0

Buenas ideas, me ayudaste a pensar en un problema diferente que estaba viendo. ¡Gracias! –

+0

Te entiendo, pero la variable de sesión aún puede ser necesaria ya que necesita persistir en los errores de validación de formulario. ¿Cómo responde tu respuesta a esto? El before_filter proporciona una mejor DRY-ness ya que este comportamiento debería estar en una serie de acciones en el controlador. –

+0

Si necesita conservar algo guardado en el flash para otra solicitud (por ejemplo, para pasar el paso de corrección de error), puede optar por persistir explícitamente ('flash [: foo] = flash [: foo]') o, si le causa menos dolor en general, use la sesión y explíquelo explícitamente cuando termine. –

0

Otro enfoque es cargar el formulario en una superposición, como http://flowplayer.org/tools/overlay/index.html, y luego en el submit de ajax puede cerrar la superposición. Lo hago en combinación con un autocompletar para ofrecer una opción de "agregar nuevo". Una vez que se envía el formulario de superposición, devuelvo algunos datos en json, que actúan para completar el autocompletado. (Hice mi propio plugin para ayudar con todo eso)

Se necesita un poco más de trabajo, pero realmente funciona bien para el usuario final.