Diego,

No se si esto es una buena práctica y no tengo mucha experiencia en
Rails pero pero el "ayudante" form_remote_tag expande una marca que usa
Ajax para ese tipo de tareas. Yo promulgo la escritura de código
explícito, sencillo y universal. Ésto se entiende como "seguir adelante
si todo esta bien" en lugar de "volver hacia atrás si algo está mal". De
esta forma sólo se redirecciona cuando es estrictamente necesario. No
veo el motivo de embrollarse en tantos controladores, si se puede
mantener mucho más simple. Un ejemplo:

El formulario (la vista):


<html>
<head>
<script>
function mostrar_div(id) {
  var element = document.getElementById(id);
  element.innerHTML = 'Cargando, por favor, aguarde un instante. Muchas
gracias.'
  element.style.display = '';
}
</script>
</head>
<body>

<div id="output" style="display:none;"></div>

<% form_remote_tag :update => 'output', :url => { :action => 'validar' }
%>

foo <input type="text" name="foo" value="<%...@foo%>"><br>
bar <input type="text" name="foo" value="<%...@bar%>"><br>
baz <input type="text" name="foo" value="<%...@baz%>"><br>

<input type="submit" value="Enviar"
onclick="javascript:mostrar_div('output')">

<% end %>

</body></html>



La clase que controla el formulario:


class NotifierController < ApplicationController
  def index
    # No necesito procesar nada.
  end

  def validar
    # Obtengo la solicitud del usuario.
    @foo = params[:foo]
    @bar = params[:bar]
    @bazl = params[:baz]          

    # Acá valido, el captcha, el comentario, el nombre, la edad, si vive
en la tierra, etc.  

    if @foo !~ /^[a-z0-9][a-z0-9\._...@[a-z0-9][a-z0-9
\._-]{2,}\.[a-z]{3}(\.[a-z]{2})?$/i
      render :text => 'foo tiene que ser una dirección de correo
electrónico'
      # No seguir, me mantengo en la vista que invocó este método
      return
    end

    # Acá está todo bien, escribo en db, redirecciono, lo felicito o le
doy un premio.

    # insert into foz values (foo. bar. baz)

    # Seguir adelante, por omisión se muestra la vista "mail"
  end
end

-----Mensaje original-----
De: Diego Algorta <[email protected]>
Responder a: Grupo Ruby Argentina <[email protected]>
Para: Ruby Uruguay <[email protected]>, Grupo Ruby Argentina
<[email protected]>
Asunto: [RubyArg] En Rails: render de un action en otro controller
Fecha: Mon, 23 Feb 2009 19:58:37 -0200


Hola gente,

Estoy intentando mejorar el código de un (viejo) proyecto Rails heredado...

Suponiendo que tenemos algo como:

https://gist.github.com/f4921b74f10d45f04c38

Dado un view para el action PostsController#show donde
se muestran los datos del post, su lista de comentarios y un
formulario para que el usuario escriba un nuevo comentario,
buscar la mejor manera de que si el usuario escribe mal el
captcha se le pueda informar de esto sin que el mismo pierda el
contenido del comentario que elaboró. De esta forma el usuario
tendrá una segunda oportunidad para ingresar el comentario sin
tener que reescribirlo.

La "dificultad" está en que no se puede hacer un redirect porque se 
perdería el contenido del comentario que escribió. Habría que hacer un 
render pero del action `show` de otro controller (el de Posts) para que 
se carguen todas las variables necesarias, etc.

Alternativas (espero que se entienda):

1. guardar el contenido del comentario en la sesión y redireccionar. No 
me gusta. Chancho y además al usar la CookieStore, tengo poco espacio 
que no quiero desperdiciar.

2. guardar el contenido del comentario en la base con un flag de "draft" 
o algo así, y redireccionar. El tema es que si realmente tengo un bot 
intentando meter comentarios y fallando en el captcha... voy a tener 
cientos (miles) de inserts en la base que no quiero. Feo.

3. mover el 99% del código de `PostsController#show` a algo como 
`ApplicationController#load_post_show_data` para llamarlo desde el 
`check_captcha` y directamente hacer un render del template 
`posts_controller/show` en vez del redirect. No me convence.

Tonces? alternativas?

Sí... ya sé... los estoy haciendo pensar too much. :)

Diego
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar

Responder a