Grails如何解决控制器名称冲突? [英] How does Grails resolve Controller name conflicts?

查看:129
本文介绍了Grails如何解决控制器名称冲突?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述



我看过这些Grails JIRA:
< a href =http://jira.codehaus.org/browse/GRAILS-4240 =nofollow noreferrer> GRAILS-4240
GRAILS-1243



...和Burt Beckwith对这两条线索的回复意味着唯一的办法是重命名其中一个控制器(可能是应用程序控制器,因为黑客插件代码不可取)

如何使用包名来区分grails中的类?



如何扩展/覆盖插件的控制器操作?



然而,Burt自己的spring-security-ui插件提倡将应用程序Controller 命名为插件Controller的确切方法 - 请参阅 spring-security-ui docs

这种方法似乎在开发模式(grails run-app)和应用程序部署为WAR时都可以使用。那么这个功能可以依靠吗?如果是这样,控制器冲突解决规则是什么? Grails文档没有提及它。 Perhasps Burt可以分享他的见解吗?

拥有像grails这样的插件体系结构,甚至没有基本的命名空间设施来处理这种冲突似乎对我来说是相当破碎的...

解决方案

问题在于,尽管您可以将包用于任何工件,但控制器的约定是删除包和Controller 来创建网址,例如PersonController - > / appname / person / action_name。所以事实上一切都变平了。

在1.3版本中,更改了1.3版本,所以插件与应用程序代码分开编译(并且先编译),这会给你有机会用应用程序的版本替换插件工件。由于您不应编辑插件代码,因此您只需使用相同的名称即可灵活地扩展或替换插件工件。



我倾向于使用UrlMappings来获取当有两个类似命名的控制器时,这个东西就像这样。例如,假设您有一个管理员UserController,允许低级别的CRUD操作和用户使用的常规UserController。我将命名管理员控制器AdminUserController并将其映射到/ admin / user / *,然后按原样保留UserController。管理员的GSP将在views / adminUser中,其他人将在views / user中,因此在那里没有冲突。这有附加的好处,能够轻松保护 - 地图/管理员/ ** - > ROLE_ADMIN。这些约定很方便,但这是一个简单的配置步骤,为我解决了这个问题。



好消息是,GRAILS-1243肯定会在2.0中实现,在1.4中。金贝蒂在GRAILS-1243的评论中引用的插件看起来很有趣。


What is the recommended approach when an application Controller name conflicts with the name of a plugin's Controller?

I've seen these Grails JIRAs: GRAILS-4240 GRAILS-1243

...and Burt Beckwith's replies to these two threads imply that the only recourse is to rename one of the Controllers (presumably the application Controller since hacking plugin code is not desirable)

How to use the package name to differentiate between classes in grails?

How to extend/override controller actions of plugins?

However, Burt's own spring-security-ui plugin advocates the exact approach of naming an application Controller the same as a plugin Controller - see spring-security-ui docs.

This approach actually seems to work in both development mode (grails run-app) and when the app is deployed as a WAR. So can this functionality be depended on? If so, what is the Controller conflict resolution rule? The grails docs do not make any mention of it. Perhasps Burt can share his insight?

Having a "plugin" architecture like grails' without even a basic namespacing facility to handle conflicts like this seems pretty broken to me...

解决方案

The problem is that while you can use packages for any artifact, the convention for controllers is to remove the package and "Controller" to create URLs, e.g. PersonController -> /appname/person/action_name. So in effect everything gets flattened.

In 1.2 and more so in 1.3 things were changed so plugins are compiled separately from application code (and are compiled first) and this gives you the opportunity to replace a plugin artifact with the application's version. Since you shouldn't edit plugin code, this gives you the flexibility to extend or replace a plugin artifact just by using the same name.

I tend to use UrlMappings to get around stuff like this when there are two similarly named controllers. For example say you have an admin UserController that allows low-level CRUD actions and a regular UserController that users work with. I'd name the admin controller AdminUserController and map it to /admin/user/* and leave UserController as is. The admin GSPs will be in views/adminUser and the others will be in views/user so there's no conflict there. This has the added benefit of being able to easily secure - map /admin/** -> ROLE_ADMIN. The conventions are convenient, but this is a simple configuration step that solves this issue for me.

The good news is that GRAILS-1243 will definitely be implemented in 2.0 and possibly in 1.4. And the plugin that Kim Betti references in the comments of GRAILS-1243 looks interesting.

这篇关于Grails如何解决控制器名称冲突?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆