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

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

Я видел эти JIRA Grails: GRAILS-4240 GRAILS-1243

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

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

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

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

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

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


grails
person Eric    schedule 09.03.2011    source источник

Ответы (1)


arrow_upward
6
arrow_downward

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

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

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

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

person Burt Beckwith    schedule 09.03.2011
comment
Спасибо, Берт! Я не уверен, что полностью понимаю, как порядок компиляции вступает в игру. Поскольку мой FooController и FooController плагина находятся в разных пакетах, ни один из них не перезаписывает другой файл .class. Оба файла FooController.class находятся в WAR. Похоже, что у Grails есть некоторая логика поиска, которая предпочитает приложение плагину ... - person Eric; 09.03.2011
comment
Верно, они скомпилированы в разные папки, поэтому конфликтов файлов .class нет. При запуске процесс, который находит артефакты, сначала находит артефакт плагина, но затем артефакт приложения заменяет его, потому что он имеет то же имя «артефакт». - person Burt Beckwith; 09.03.2011