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

Posted 2023-04-14

【中文标题】Play Framework：验证错误重定向的最佳实践

【英文标题】：Play Framework: Best practice for validation errors redirect

【发布时间】：2012-02-17 16:07:39

【问题描述】：

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

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

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

编译时验证signUp方法在重命名后退出

第二种方法：

更快，浏览器中没有重定向/往返

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

【参考方案1】：

让我回顾一下你的论点：

第一：

为用户提供漂亮的 URL

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

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

所以第一个参数无关紧要。

第二：

POST 后总是重定向，所以如果用户刷新页面没有确认问题。

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

第三：

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

看不到render("@signUp");的问题

第四：

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

好的，这是一个论点，但我认为它很弱。在 play 2.0 中将是错误的。

所以我认为这两种方法都不错，具体取决于具体情况。特别是如果您的表单很大，重定向将不起作用。默认情况下，我会推荐第二种解决方案。 不过不知道play 2.0的情况如何。

【讨论】：

对于我知道的有关播放路线的 URL，最坏情况下带有 mod_rewrite 的 apache 始终可用。但是现在我们希望只使用方法和类名的约定来保留所有 url 配置。这样，新人就可以很容易地从 url 中找到方法。对于render（“@signUp”），我在文档中没有看到任何关于它的内容，只有renderTemplate，我的理解是它只是从signUp渲染模板，而不是调用signUp控制器方法？如果是这样，那么我们在 signUp 控制器中为填充 renderArgs 所做的一切都需要再次完成。

如果您想使用约定优于配置，您可以执行以下操作：get /controller/action controller.action post /controller/action controller .doaction

好吧，最后一条评论坏了，我不能编辑它：如果你想使用约定而不是配置，你可以执行以下操作： get /controller/ action controller.action post /controller/action controller.doaction ok dosingup 不如 doSignup 好。 @signUp 是我知道模板名称很简单，所以 mycontroller/signup.html。 最后提示通用方法不适用于 Play2.0

好的，谢谢，但这意味着如果我（例如）想在注册时为某些选择选项准备可能的选项列表，并且列表取决于用户 IP（只是一个示例）。我将有一些代码计算该列表，然后调用 renderArgs.put("options", optionsFromIp)。然后我还必须在“post”处理程序中调用这个逻辑，并在调用 render(“@signup”) 之前调用 renderArgs.put()。这里更大的问题是后来有人在 signup() 中更改了此代码，但在 doSignup 中没有更改，或者添加了新的 renderArgs，然后他需要知道在第二种方法中添加它。对吗？

是的，它是正确的。但是，您也必须正确处理表单数据。如果您确实有要共享的代码，可以使用私有方法或禁止重定向***.com/questions/3899670/…

【参考方案2】：

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

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