Как Grails разрешает конфликты имен контроллеров?

Question

Каков рекомендуемый подход, когда имя Контроллера приложения конфликтует с именем Контроллера плагина?

Я видел эти Граалы JIRA: Grails-4240 Grails-1243

... и ответы Берта Беквита на эти два потока означают, что единственным выходом является переименование одного из контроллеров (предположительно, контроллера приложения, поскольку взлом кода плагина нежелателен)

Как использовать имя пакета для различения классов в Grails?

Как расширить / переопределить действия контроллера над плагинами?

Однако собственный плагин Burt для spring-security-ui поддерживает точный подход к присвоению имени контроллеру приложения так же, как плагин Controller - см. spring-security-ui docs .

Этот подход действительно работает как в режиме разработки (grails run-app), так и когда приложение развернуто как WAR. Так может ли эта функциональность зависеть? Если да, то каково правило разрешения конфликтов в контроллере? Документы Grails не упоминают об этом. Может, Берт может поделиться своим пониманием?

Наличие такой "плагиновой" архитектуры, как у grails, даже без базового средства для обработки имен, для обработки подобных конфликтов, кажется мне довольно сломанным ...

Answer 1

Проблема в том, что, хотя вы можете использовать пакеты для любого артефакта, для контроллеров принято удалять пакет и «Контроллер» для создания URL-адресов, например, PersonController -> / appname / person / action_name. Таким образом, в действительности все становится плоским.

В 1.2 и более, в 1.3 все изменилось, поэтому плагины компилируются отдельно от кода приложения (и сначала компилируются), и это дает вам возможность заменить артефакт плагина версией приложения. Поскольку вы не должны редактировать код плагина, это дает вам возможность расширять или заменять артефакт плагина, просто используя то же имя.

Я склонен использовать UrlMappings для обхода подобных вещей, когда есть два одинаково названных контроллера. Например, скажем, у вас есть UserController администратора, который позволяет выполнять низкоуровневые действия CRUD, и обычный UserController, с которым работают пользователи. Я бы назвал административный контроллер AdminUserController и сопоставил его с / admin / user / *, а UserController оставил как есть. Административные GSP будут в views / adminUser, а остальные - в views / user, поэтому здесь нет конфликта. Это дает дополнительное преимущество - возможность легко защищать - map / admin / ** -> ROLE_ADMIN. Соглашения удобны, но это простой шаг настройки, который решает эту проблему для меня.

Хорошей новостью является то, что GRAILS-1243 определенно будет реализован в 2.0 и, возможно, в 1.4. И плагин, на который ссылается Ким Бетти в комментариях к GRAILS-1243, выглядит интересно.