Formularios de Yesod con flujo de página

Question

Ciertos formularios son demasiado complicados para que quepan en una página. Si, por ejemplo, un formulario implica grandes cantidades de datos estructurados, como escoger ubicaciones en un mapa, programar eventos en un widget de calendario, o tener ciertas partes de un formulario que cambian dependiendo de la entrada anterior, es de valor para poder romper una cierta forma en varias páginas.

Esto es fácil de hacer con páginas web dinámicas y Javascript, ya que simplemente crearía un widget de pestañas con diferentes páginas, y el formulario real contendría el widget de pestañas completo y todos sus campos de entrada, produciendo un solo POST solicitar toda la operación

A veces, sin embargo, lleva mucho tiempo generar ciertos campos de entrada; incluso pueden ser computacionalmente intensivos incluso después de que se haya generado la página, lo que grava al navegador del usuario de la computadora de gama baja. Además, se hace difícil o imposible crear formularios que se adapten en función de entradas anteriores.

Por lo tanto, es necesario dividir un formulario determinado en varias solicitudes de página completa.

Esto puede llegar a ser difícil, sobre todo desde la primera página de un formulario se POST a /location/a, que emitirá una redirección a /location/b y pidió que GET por el cliente. Pasar los datos del formulario almacenado de POST /location/a a GET /location/b es donde yace la dificultad.

Erwin Vervaet, el creador de Spring Web Flow (Un subproyecto del framework Spring, conocido principalmente por sus capacidades de inyección de dependencia) una vez escribió a blog article demostrando esta funcionalidad en dicho framework, y también comparándolo con el Lift Web Framework que implementó similar functionality. A continuación, presenta un desafío a otros marcos web, que se describe con más detalle en a later article.

¿Cómo se enfrentaría Yesod a este problema, especialmente teniendo en cuenta su naturaleza basada en REST sin estado?

Answer 1

En primer lugar, todavía no existe una solución preconstruida para esto (de la que soy consciente al menos). Y no estoy familiarizado con cómo los otros marcos mencionados resuelven el problema. Entonces, lo que digo aquí es más o menos conjetura. Estoy bastante seguro de que funcionaría, sin embargo.

El quid de la cuestión aquí es la codificación de los parámetros POST de la página A en la solicitud GET para la página B. La forma más sencilla de hacerlo sería pegar los parámetros POST de la página A en una variable de sesión. Sin embargo, al hacerlo se rompería bastante la navegación: retroceder/avanzar no funcionaría en absoluto como se describe.

Volvemos a REST: tenemos que codificar los parámetros POST en la propia solicitud. Eso realmente significa poner la información en la ruta solicitada o en la cadena de consulta. Y la cadena de consulta probablemente tenga más sentido.

Me preocuparía poner los parámetros raw POST en la cadena de consulta, ya que eso permitiría a cualquier servidor proxy husmear fácilmente los contenidos. Así que me gustaría aprovechar la criptografía existente de la sesión de cliente. En otras palabras, incluiremos una versión encriptada y firmada del envío de formulario anterior en un parámetro de cadena de consulta.

para que sea un poco más concreto:

• usuario va a la página A a través de GET.
• El usuario envía la página A a través de POST.
• El servidor valida el envío de formularios, obtiene un valor, lo serializa, lo encripta/lo procesa.
• El usuario se redirige a la página B como GET, con un parámetro de cadena de consulta que contiene el valor cifrado/hash de la página A.
• Continúe este proceso cuantas veces lo desee.
• En la página final, puede descifrar el parámetro de cadena de consulta y tener todas las presentaciones de formulario.

Parece que sería un paquete complementario divertido para escribir si alguien está interesado.