Como extra he actualizado un poquillo el artículo para Rails 2 y he incluido un truquito nuevo que he aprendido desde que escribí el artículo.

Gracias por destacar el error y si encuentras algo más mal… pues yo te recomendaría ponerme a caldo en tu blog, en plan Galli vs. Microsiervos.

Voy a modificar el código del artículo para corregirlo. Sorry por las molestias. Prometo probar mi código antes de escribirlo la próxima vez.

product_path(product),
:method => :delete },
:href => delete_project_path(project) %>


En caso de no tener JS activado, ¿el :href no haría que el enlace actuase como un enlace normal y corriente? Es decir, un enlace que haría un GET y no funcionaría ya que en el controlador estás discriminando para que esa acción sea de tipo POST, o DELETE en el caso del borrado… puede que tenga que ver con que en el controlador tú uses cosas de prototype (creo) y yo lo haga de la otra forma (lo de if request.post?) y demás… el caso es que lo he probado con la acción subscribe que debería se de tipo POST, y al desactivar JS, el enlace no funciona.

Lo que quería comentar ahora es que una acción tipo POST no debería hacer un render, generalmente, debería hacer redirect_to, ya que un usuario podría refrescar la página provocando que crees otro usuario nuevo (creo).

Si, esto que dices tiene sentido. Se ve fácilmente si no usas AJAX porque en la URL queda …/subscribe/4 (o delete, lo que sea) a pesar de que el render es el de …/show/4. Lo que no tengo claro es si actualizar la página hace un GET de esa URL o repite la ultima acción del usuario… Supongo que será esto último, por el mensaje que aparece a veces de tipo “… esta petición contiene POSTDATA …”. En mi caso, al desactivar JS para probar que sin AJAX todo va bien, no ocurre nada malo al actualizar, pero es porque estoy usando lo de :href de antes que genera un enlace de tipo GET, como comentaba en mi duda anterior.

submit_tag envía el formulario a la acción definida en el form_tag o form_for, y es en el código de esa acción (ya en el controlador correspondiente) donde puedes hacer un render o un redirect_to de la nueva página que tú deseas.

Cualquier ejemplo básico de Rails (incluso el scaffold auto-generado) realiza esos pasos tan básicos.

Lo que quería comentar ahora es que una acción tipo POST no debería hacer un render, generalmente, debería hacer redirect_to, ya que un usuario podría refrescar la página provocando que crees otro usuario nuevo (creo).

He refactorizado tu pastie porque así el código es menos enrevesado y tiene el mismo significado.

He llegado hasta ese código porque he tenido problemas ya que decidí sacar la condición
render :layout => false if request.xhr?
y ponerla al principio del método, pues era válida también para POST.

Pero resulta (supongo que tú lo sabes pero quizá algún lector no ) que después de un render las variables de instancia no llegan a la vista (es lógico ya que render es un método, pero con esa sintaxis tan rara que tiene ruby no lo tenía tan claro hasta ahora, cuando hacía render :layout => false pensaba que simplemente estaba dejando anotada esa condición, pero me acabo de dar cuenta que no, que estaba llamando explícitamente a un método que se llama implícitamente cuando termina un método del controlador).

Esto hacía que algunas cosas que se hacen en la vista no funcionasen como deberían. Así que me dije, ¿para qué hacer if get return pudiendo hacer simplemente if post haz cosas? y así finalmente llamo al método render sin layout siempre que sea AJAX.