在 Play 中调用静态方法!框架控制器不起作用
我有一个游戏!具有两个包含冗余代码的操作的框架。因此,我将此代码分解为一个 private static
方法,但它不再起作用了。
public static void show(long itemId, String listId) {
render(getItem(itemId, listId));
}
private static Item getItem(long itemId, String listId) {
// otherwise duplicate code ...
return item;
}
如果我将 getItem
中包含的代码内联到 show
操作中,一切都很好:
// this works
public static void show(long itemId, String listId) {
Item item = // duplicate code ...
render(item);
}
为什么我不能在 Play! 中调用其他静态方法?控制器?
解决方案
感谢“Codemwnci”,我实现了以下解决方案:
public static void show(long itemId, String listId) {
renderArgs.put("item", getItem(itemId, listId));
render();
}
我更喜欢renderArgs
,因为它比局部变量使意图更清晰。
I have a Play! framework with two actions which contain redundant code. So I factored this code into a private static
method, but It doesn't work anymore then.
public static void show(long itemId, String listId) {
render(getItem(itemId, listId));
}
private static Item getItem(long itemId, String listId) {
// otherwise duplicate code ...
return item;
}
If I inline the code contained in getItem
into the show
action everything is fine:
// this works
public static void show(long itemId, String listId) {
Item item = // duplicate code ...
render(item);
}
Why can I not call other static methods within a Play! controller?
Solution
Thanks to 'Codemwnci' I've implemented the following solution:
public static void show(long itemId, String listId) {
renderArgs.put("item", getItem(itemId, listId));
render();
}
I prefer renderArgs
because it makes the intention more clear than a local variable.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当您将局部变量传递到 render 方法时,传递到 Groovy 视图时将使用局部变量的名称。在您的示例中,您没有传递局部变量,因此 Play 不知道为您指定的项目指定什么名称。
你有几个选择。您可以将
选项 1 可能是最明智的。
When you pass a local variable into the render method, the name of the local variable is used when passed through to the Groovy view. In your example, you are not passing a local variable, therefore Play does not know what name to give the item you have specified.
You have a couple of options. You can do either
Option 1 is probably the most sensible.