Yesod与页面流程形成

dfl*_*str 6 forms rest haskell session-state yesod

某些表单太复杂,不适合一页.例如,如果表单涉及大量结构化数据,例如在地图上选择位置,在日历窗口小部件中安排事件,或者根据先前的输入更改表单的某些部分,则能够在多个页面上分解某种形式.

这对于动态网页和Javascript很容易,因为人们只需创建一个包含不同页面的选项卡小部件,实际提交的表单将包含整个选项卡小部件及其所有输入字段,从而产生POST对整个操作的单个请求.

但是,有时候生成某些输入字段需要很长时间; 即使在页面生成之后,它们甚至可能是计算密集型的,对低端计算机用户的浏览器造成负担.另外,基于先前的输入创建适应自己的形式变得困难或不可能.

因此,有必要在多个完整页面请求上拆分某种形式.

这可能被证明是困难的,特别是因为表单的第一页将POST发送/location/a,其将发出重定向并由客户端/location/b请求GET.将存储的表单数据传递POST /location/aGET /location/b难以处理的地方.

Spring Web Flow的创建者Erwin Vervaet(Spring框架的一个子项目,主要以其依赖注入功能而闻名)曾写过一篇博客文章,在所述框架中演示了这一功能,并将其与实现类似功能的Lift Web Framework进行了比较.然后,他向其他Web框架提出了挑战,这将在后面的文章中进一步描述.

Yesod将如何面对这个问题,特别是考虑到其基于REST的无状态特性?

Mic*_*man 3

首先,目前还没有预先构建的解决方案(至少我知道)。我不熟悉提到的其他框架如何解决问题。所以我在这里所说的几乎都是猜测。不过,我相当确定它会起作用。

这里问题的关键是将页面 A 的 POST 参数编码到页面 B 的 GET 请求中。最简单的方法是将页面 A 的 POST 参数粘贴到会话变量中。然而,这样做会彻底破坏导航:如所描述的那样,后退/前进根本不起作用。

所以我们回到 REST:我们需要将 POST 参数编码到请求本身中。这实际上意味着将信息放入请求的路径或查询字符串中。查询字符串可能是最有意义的。

我担心将原始 POST 参数放入查询字符串中,因为这将允许任何代理服务器轻松窥探内容。所以我想利用客户会话中现有的加密技术。换句话说,我们将在查询字符串参数中粘贴先前表单提交的签名、加密版本。

为了使其更具体一些:

  • 用户通过 GET 转到页面 A。
  • 用户通过 POST 提交页面 A。
  • 服务器验证表单提交、获取值、序列化它、加密/散列它。
  • 用户以 GET 方式重定向到页面 B,查询字符串参数包含页面 A 的加密/散列值。
  • 根据需要多次继续此过程。
  • 在最后一页上,您可以解密查询字符串参数并获得所有表单提交。

如果有人感兴趣的话,这看起来会是一个有趣的附加包。