如何在后退/前进或刷新后保留DataTables中的过滤器

Question

我们正在使用DataTables作为我们的表，我们遇到了一些问题/意见不一致保留之前应用于表的过滤器的历史记录，以便用户可以来回/刷新这些的

现在，提出的一个解决方案是将过滤器字符串保留在URL中，并将其作为GET请求传递，这可以很好地用于前后和刷新。但由于我有非常自定义的过滤选项（嵌套的过滤器组），因为长度限制，过滤器字符串变得非常长，实际上太长而无法通过GET请求传递它。

因为GET是不可能的，显而易见的解决方案是POST请求，这是我们无法达成的共识。

第一个解决方案是使用POST请求，每次我们尝试前后或刷新时都会收到“恼人的”弹出窗口。我们还打破了整个网站使用的POST / Redirect / GET模式，因为没有GET。

优点：

• 简单的解决方案
• 没有第二次请求服务器
• 无其他数据库请求
• 没有其他数据库数据
• 仅在您选择时将过滤器保存到数据库，以便您可以随时重新应用

缺点：

• 打破POST / Redirect / GET模式
• 必须使用pushState（history.js）推送POST数据
• 如何让刷新工作？

第二个解决方案是使用POST请求，服务器端将数据保存在数据库中，获取用于请求保存数据的ID，返回它，然后客户端使用此方法执行GET请求ID，服务器端匹配回数据，返回正确的过滤器，从而保留POST / Redirect / GET模式。此解决方案发出两个请求并保存用户使用的每个过滤器到数据库。每个用户在数据库中只保存有限数量的“历史”过滤器，旧应用程序在应用新过滤器时会被删除。基本上，服务器端会通过将长数据保存到数据库来缩短URL，就像URL缩短站点一样。

优点：

• 保持POST / Redirect / GET模式
• 由于再次发送帖子数据而来回转发和刷新页面时没有弹出消息

缺点：

• 复杂的解决方案
• 对服务器的附加请求
• 对数据库的附加请求
• 除非用户往返或刷新页面，否则数据库中的大量数据将不会被使用

第三种解决方案非常受欢迎，或者选择上述方法之一并理想地解释原因。

Answer 1

这是一个稍纵即逝的想法...我可以通过使用bStateSave来保存长度，过滤，分页和排序http://datatables.net/examples/basic_init/state_save.html

我的想法是，从理论上讲，您可以将datatables.js生成的cookie保存到数据库表中，就像您在第二个解决方案中提到的那样，但只有在每次要覆盖当前过滤器时才会发生请求，当前cookie与之前的“历史”cookie