Java Play框架：验证错误重定向的最佳实践

我正在实施一个带有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();
}

但根据play提供的样本，似乎使用了不同的方法：

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

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

对于这个小示例，代码差别很小，但在更复杂的示例中，代码差别就不那么简单了

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

• 为用户提供漂亮的URL

• 总是在发布后重定向，所以如果用户刷新页面，则不会出现确认问题

• 只有一个方法负责在调用之前填充渲染器 模板

• 编译时验证注册方法在重命名后是否存在

第二种方法：

• 更快，无需在浏览器中重定向/往返

---

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

这取决于具体情况。第一种方法将更加宁静。但是，由于重定向，错误和参数需要存储在cookie中才能检索

---

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

让我回顾一下您的论点：

第一:

为用户提供漂亮的URL

在Play1.x中，URL总是可以正常运行的。您可以使用以下选项：

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

所以第一个论点并不重要

第二：

总是在发布后重定向，所以如果用户刷新页面，则不会出现确认问题

我认为如果一个用户犯了一个错误，按F5或用其他技术刷新，如果他再次出现同样的错误，那就好了。如果用户可以得到一个干净的表单，我更喜欢有一个取消按钮

第三：

只有一个方法负责在调用模板之前填充渲染器

无法看到

render（“@signUp”）的问题

第四：

编译时验证注册方法在重命名后是否存在

好的，这是一个论点，但我认为它是软弱的。将在播放2.0时为假

因此，我认为这两种方法都是好的，这取决于具体情况。特别是如果你有一个大的表单，重定向将不起作用。默认情况下，我会推荐第二种解决方案。
但是，我不知道play 2.0的情况会如何。
对于我知道的关于播放路线的URL，最坏情况下，使用mod_rewrite的apache总是可用的。但现在，我们希望只使用方法和类名的约定来保留所有url配置。这样，对于新手来说，只需从url就可以轻松找到方法。对于render（@signUp），我在文档中没有看到任何关于它的内容，只有renderTemplate，我的理解是它只是从signUp中呈现模板，而不是调用signUp控制器方法？如果是这样的话，那么我们在注册控制器中填充渲染器所做的一切都需要再次完成。如果您想在配置上使用约定，您可以执行以下操作：get/{controller}/{action}{controller}.{action}post/{controller}/{action}{controller}。do{action}Ok最后一条注释被打断，我不能编辑它：
如果你想使用约定而不是配置，你可以做以下事情：
get/{controller}/{action}{controller}.{action}post/{controller}/{action}{controller}.do{action}
ok dosingup不像dosingup那么好。
据我所知，@signUp是一个简单的模板名，所以mycontroller/signup.html。
最后提示，通用方法无法用于Play2.0，谢谢，但这意味着如果我（例如）想为注册时的某些选择选项准备可能选项列表，而列表取决于用户IP（仅举一个例子）。我将有一些代码来计算这个列表，然后调用renderArgs.put（“options”，optionsFromIp）。然后我还必须在“post”处理程序中调用此逻辑，并在调用render（“@signup”）之前调用renderArgs.put（）。这里更大的问题是有人后来在signup（）中更改了这段代码，但在doSignup中没有，或者添加了新的渲染器，然后他需要知道如何在第二个方法中添加它。对吗？对，对。但是，您也必须正确处理表单数据。如果确实有要共享的代码，可以使用私有方法或禁止重定向