Question

我正在使用play 1.2.4实现一个项目，基于文档处理验证的正确方法是：

public static void signUp() {
    render();
}

public static void doSignUp(@Required @Valid User user) {
    if (validation.hasErrors()) {
        params.flash();
        validation.keep();
        signUp();
    }
    user.create();
    Application.index();
}

但基于播放提供的样本，似乎使用了不同的方法：

public static void signUp() {
    render();
}

public static void doSignUp(@Required @Valid User user) {
    if (validation.hasErrors()) {
        render("@signUp"); 
    }
    user.create();
    Application.index();
}

对于这个小例子，代码差异很小，但在更复杂的例子中，它并不那么简单。

我看到的优点和缺点是：第一种方法：

为用户提供了很好的网址
POST后总是重定向，因此如果用户刷新页面则无确认问题
在调用之前，只有一个方法负责填充renderArgs 模板
如果重命名signUp方法退出，则编译时间验证

第二种方法：

浏览器更快，无重定向/往返

那么最佳做法是什么？在应用程序中使用哪种方法？

Answer 1

让我回顾你的论点：

首先：

为用户提供了很好的网址

Play 1.x中的URL总是可以正常使用。您可以使用以下内容：

get  /signUp  myController.signUp
post /signUp  myController.doSignUp

所以第一个论点并不重要。

第二

POST后总是重定向，因此如果用户刷新页面，则不会出现确认问题。

我认为如果用户犯了错误并按F5或使用其他技术刷新，那么如果他再次遇到相同的错误就很好。如果用户应该有可能获得一个干净的表格，我更喜欢有一个取消按钮。

第三

在调用模板
之前，只有一种方法负责填充renderArgs

无法查看render("@signUp");

的问题

第四：

编译时间验证，如果重命名signUp方法退出。

好的，这是一个争论，但我认为它很弱。玩游戏2.0会有误。

所以我认为这两种方法都可以很好，具体取决于具体情况。特别是如果您有一个大表单，重定向将无法正常工作。默认情况下，我会推荐第二种解决方案。但是，我不知道play 2.0的情况如何。

Answer 2

这取决于。第一种方法将更加RESTful。但是由于重定向，错误和参数需要存储在要检索的cookie中。

由于存储在cookie中的数据存在4k限制，因此这可能不适合大型表单。

Play Framework：验证错误重定向的最佳实践

2 个答案: