grails & MVC 表单架构 - 每个表单使用两个操作..通用行业模式？
我对 Grails 和 Web MVC 都有点陌生。查看脚手架 grails 架构，并将其扩展到为最终用户 Web 应用程序构建表单，该模式似乎是为收集表单数据的页面投入两个操作：第一个操作显示页面，包括之前的任何错误提交，第二个在提交时对数据进行操作，产生错误，并且 a) 根据需要返回第一个操作，或 b) 如果没有错误，则继续执行后续操作/控制器。
我的问题是，这是一种“行业标准”类型的模式吗……应该是吗？
或者在某些情况下可以通过一个操作来完成这项工作……或者在其他情况下可能使用 3 个操作，例如可能一个用于显示错误？
PS请忽略我下面的评论；我对这个问题进行了相当多的更新
--------- 出于讨论的目的，并且对于那些具有 Web MVC 背景但不是 grails 背景的读者，这里是 grails 生成的代码（版本 1.3.7）
def create = {
def personInstance = new Person()
personInstance.properties = params
return [personInstance: personInstance]
}
def save = {
def personInstance = new Person(params)
if (personInstance.save(flush: true)) { // my additon: save causes validation to be performed against user specified constraints, returning true or false
flash.message = "${message(code: 'default.created.message', args: [message(code: 'person.label', default: 'Person'), personInstance.id])}"
redirect(action: "show", id: personInstance.id)
}
else {
render(view: "create", model: [personInstance: personInstance])
}
}
I'm a bit new to Grails and also Web MVC in general. Looking at the scaffolded grails architecture, and extending that to building forms for an end-user web app, the pattern seems to be to devote two actions to a page that collects form data: the first to display the page, including any errors from previous submits, and the second to act on the data on submission, producing errors and a) returning to the first action as need be, or b) going on to a successor action/controller if no errors.
My question is, is this an "industry standard" type of pattern ... should it be?
Or might one alternatively make this work via one action in some cases ... or perhaps use 3 actions in other cases, e.g. perhaps one for the display of errors?
P.S. Please ignore my comment below; I updated this question quite a bit
--------- for purposes of discussion and for those reading with a Web MVC background but not a grails background, here's the grails generated code (version 1.3.7)
def create = {
def personInstance = new Person()
personInstance.properties = params
return [personInstance: personInstance]
}
def save = {
def personInstance = new Person(params)
if (personInstance.save(flush: true)) { // my additon: save causes validation to be performed against user specified constraints, returning true or false
flash.message = "${message(code: 'default.created.message', args: [message(code: 'person.label', default: 'Person'), personInstance.id])}"
redirect(action: "show", id: personInstance.id)
}
else {
render(view: "create", model: [personInstance: personInstance])
}
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想说在这一点上它是行业标准。大多数 Java Web 框架都实现了转发到视图的想法，而不是通过让用户导航到 .jsp/.gsp/.html 页面来公开视图技术。我相信，当 scriptlet（视图中的 java 代码）开始成为一种巨大的反模式时，这变得更像是一种标准。此时，将数据获取到视图的唯一方法是获取服务器上的数据，然后将该数据转发到视图。
即使我们重定向，我们也会重定向到服务器上转发到视图的操作。因此，就您的观点而言，您的想法是准确的，您通常会至少采取 2 个行动。不过，根据应用程序的复杂程度，您最终会得到更多。例如，您的脚手架 CRUD 将包含 4 个（索引、保存、更新、删除）
I would say at this point it is industry standard. Most of the Java web frameworks implement the idea of forwarding to the view rather than exposing the view technology by having a user navigate to a .jsp/.gsp/.html page. I believe this became more of a standard when scriptlets (java code in the view) started to become a huge anti-pattern. At that point, the only way to get data into the view was to get the data on the server, then forward that data to the view.
Even when we redirect, we redirect to an action on the server which forwards to the view. So to your point, you thoughts are accurate that you'll generally have at least 2 actions. Although, depending on the complexity of your application, you'll end up with a handful more. For example, your scaffolded CRUD will contain 4 (index, save, update, delete)