2

我们使用 DataTables 作为我们的表，并且我们在以某种方式保留之前应用于表的过滤器的历史记录时遇到问题/分歧，以便用户可以来回和刷新这些。

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

因此，由于 GET 是不可能的，显而易见的解决方案是 POST 请求，这是我们无法达成一致的。

第一个解决方案是使用 POST 请求，并在每次我们尝试返回/返回或刷新时获取“烦人”的弹出窗口。我们还打破了我们在整个站点中使用的 POST/Redirect/GET 模式，因为不会有 GET。

优点：

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

缺点：

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

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

优点：

  • 保持 POST/Redirect/GET 模式
  • 回退刷新页面时没有弹出消息，因为帖子数据再次发送

缺点：

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

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

4

1 回答 1

0

这是我刚刚想到的一个转瞬即逝的想法……您可以使用 bStateSave http://datatables.net/examples/basic_init/state_save.html保存长度状态、过滤、分页和排序

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

于 2013-11-06T18:30:15.147 回答