我有以下控制器结构:
abstract class AbstractController {
// ...
}
abstract class AbstractDiagramController extends AbstractController {
// ...
}
class PopulationController extends AbstractDiagramController {
// ...
}
大多数控制器动作调用抽象基类的各种方法。如果现在其中一个基本方法需要向客户端发送重定向(或转发),Grails将不会阻止应用程序处理控制器动作的剩余动作代码。
从我的角度来看,这是一种不受欢迎的行为,因为基本方法会进行某种验证(如验证参数,用户,会话等),并且控制器假定验证成功(因此产生后续错误)。
如何防止这种行为不足?
亲切的问候, 克里斯托弗
PS:我发现已经this question,但答案并不能满足我的需求,因为它们都没有处理基本控制器:
PPS:我在1.3.7版本中使用Grails
修改
这是Victor Sergienko的评论的反应。 在这里,我给出了一个更详细的代码 - 我的问题的例子。
// The very base controller
abstract class AbstractController {
// The interceptor gets called before any action of inheritors get processed
def beforeInterceptor = [action:this.&initialize]
// Method validates various stuff
protected initialize() {
if( someThingIsWrong() ) {
// This redirect should stop any other code of inheritors
redirect( controller: "foo", action: "bar" )
return false
}
}
}
// The second base controller
abstract class AbstractDiagramController extends AbstractController {
// This object must get initialized. If not (eg any errors or exceptions occured)
// all inheritors actions are not allowed to do anything
MyObject myGreatObject = null
// Overriden, because of additional individual diagram validation
@Override
protected initialize() {
// Do parents stuff first
super.auth()
// If parent failed, this code should not get executed anymore.
// Yes, here I could check if parent returned false and return false as well before
// continuing the next validation. Anyway I have to do this because grails, comprehendibly,
// will throw an exception if two redirects were executed in a row.
// (With this I just want to visualize the behaviour I'd expect)
if( someThingElseIsWrong() ) {
redirect( controller: "hello", action: "world")
return false
}
// After validation I can initialize the object
myGreatObject = new MyObject()
}
}
// A controller implementation
class MyDiagramController extends AbstractDiagramController {
// Overriden because of inidividual validation
@Override
protected initialize() {
// First do parent stuff
boolean succeeded = super.auth()
// Again, annoying double check
if( !succeeded ) {
return false
}
}
def myAction = {
myGreatObject.SpinAroundAndBeHappy()
}
}
看起来将用例减少到最小代码行是一个好主意。现在看起来Victor的建议(canContinue
或hasErrors
)可以某种方式解决这种不愉快的情况,即使这是某种解决方法。
但不知怎的,我不喜欢那些双重检查。我仍在努力反对这一事实,即抽象基本控制器上方的所有层必须对之前发生的无效验证作出反应(并且还应由基本控制器自己管理)。从我的角度来看,这些检查不应该是控制器实现的业务。
PS:我希望代码中没有严重的错误。
答案 0 :(得分:4)
作为一种变通方法,您可以从祖先操作返回boolean canContinue
或抛出异常,或在您的情况下检查instance.hasErrors()
。
编辑:事件initialize()
在之前被称为操作看起来像访问控制或操作语义的另一个完全覆盖(在执行任何操作部分之前) )。请告诉我的假设是否错误。
当我们对不同的操作进行自定义安全访问时,我们使用自己的标记@SecuredDoodah
注释了操作(请参阅@Secured),并添加了完全覆盖操作的Filter
(对我们来说,Filter
以403响应,但没有必要。)
Filter
可能比beforeInterceptor
更好。如果您需要从Filter
传递某个状态,例如示例中的myGreatObject
,则可以inject a Service into Filter并将状态保存在服务中。
我确信我的想法有更好的方法,但这应该对控制器透明地工作。
答案 1 :(得分:2)
你受限于这是Java / Groovy的事实,并且方法调用无法立即触发从方法(或Closure)退出。我看到另一个框架作弊,当你调用render,redirect等时,它会抛出一个异常,它将它捕获到框架基类。这就像一个Goto,它并不存在。
这是一种昂贵的方法 - 不必要地填充所有堆栈帧是浪费的,因为它不是例外情况,并且堆栈将始终被忽略。
不幸的是,您需要像Victor那样使用布尔返回值的方法。