Grails v3.3.9: как отделить каркасные представления от API остальных

Question

grails v3.3.9

Я бы мог использовать каркасные представления / контроллеры, но держу эти отдельно от моих остальных представлений API и контроллеров.

IЯ запустил приложение моего проекта для генерации jsonApi, поэтому я настроил свои UrlMappings примерно так:

   ...
   "/api/sites"(resources:'site') {
        "/devices" (resources:'device')
    } ...

Затем я создал свой RestfulController в grails-app / controllers, и соглашение по умолчанию предполагает, что вашим контроллером будет SiteController, а затемвы редактируете grails-app / views / site с вашими шаблонами gson для рендеринга остальных.пока все хорошо.

Теперь вы можете попробовать представления в скаффолдах - и настройки платформы по умолчанию начинают разрушаться.

Я создал новую запись в UrlMappings, подобную этой, чтобы направить пользовательский интерфейс в свой собственныйконтроллер

    "/ui/sites/$action?/$id?" (controller:"siteUI") {
        constraints {
            // apply constraints here
        }
    }

затем вы можете создать новый контроллер, подобный этому

   class SiteUIController {
       static scaffold = x.y.z.Site
   }

, запустить приложение и получить доступ в браузере как / ui / sites - и он отобразит список сайтов,

однако две насущные проблемы

1) у моего сайта есть ссылка на домен Org (единственная ссылка) (с toString ()), и если я посмотрю на созданную ссылку, ссылка выглядит так, (где каким-то образом внутреннее устройство сгенерировало ссылку на контроллер остальных API, а не на контроллер HTML.) Ссылка Org

  http://localhost:8080/api/orgs/1

2) у моего сайта также есть местоположения (сайт имеет множество расположений) (пока еще не определено toString в этом домене).Когда вы смотрите на сгенерированную ссылку, это выглядит так.ссылка на местоположение

http://localhost:8080/location/show/2 

, которая не является ни контроллером rest /, ни html!

Я попытался немного обмануть и сохранил свою конечную точку отдыха, а также создал сайт generate-controller, и generate-viewsСайт и не удалось поместить их в правильные каталоги (views / siteUI, controller / siteUI и т. Д.) И снова восстановить мои сохраненные конечные точки отдыха.

Это помогло немного, поскольку теперь я могу перейти к правильному представлениюнабрав URL в браузере, произнесите «/ ui / sites / show / 1» - и все будет хорошо.но ссылки, которые он отображает, не будут работать, так как все настройки по умолчанию неверны.

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

Сначала я просто сделаю все строительные леса.заставить это работать, а затем добавить остальные контроллеры / представления позже?

Я не хочу смешивать пользовательский интерфейс с контроллерами отдыха, чтобы они могли работать отдельно и независимо, и любая игра с пользовательским интерфейсом не работаетиспортить / разбить остальные точки и наоборот

, прежде чем я исчезну в правильном старом беспорядке - я хотел бы получить некоторые рекомендации по лучшему подходу, чтобы отделить эти вещи, не нарушая все стандарты / логику платформы BAU в рамках- это слишком сложно для меня, чтобы справиться.

Советы по наилучшему подходу к этому сценарию были бы с благодарностью приняты.Я надеюсь, что кто-то был здесь и придумал лучший способ продолжить.

Answer 1

Я думаю, что я нашел ответ в Grails in Action - второе издание, стр. 332.

Иногда соглашение о соглашении может сбить с толку.По сути, когда вы объявляете что-то подобное в UrlMappings:

    "/api/sites"(resources:'site') {
        "/devices" (resources:'device')

Вы можете подумать, что имя ресурса относится к классу домена, на самом деле это имя класса контроллера:

Так что если вы назоветеотображение, подобное этому

    "/api/sites"(resources:'siteRest') {
        "/devices" (resources:'deviceRest')

, направляет запросы в контроллер siteRest.

Кроме того, вместо того, чтобы многие контроллеры все лежали на одном уровне в grails-app / controllers, в этом нет необходимости.

По существу, если вы создаете что-то вроде двух подкаталогов, скажем / rest и / ui, и помещаете соответствующие контроллеры в каждый (например, /rest/siteRestController.groovy и /ui/siteController.groovy), тогдаМеханизм разрешения URL-адресов ищет совпадения имен <stem> в каталоге grails-app / controllers.Поэтому основное требование заключается в том, чтобы имена контроллеров были уникальными.

Отображение по умолчанию, а затем сбор и обработка любых контроллеров -generate-all / controller scaffolded.

    "/$controller/$action?/$id?(.$format)?" {
        constraints {
            // apply constraints here
        }
    }

Это позволяет вам выполнятьвы отделяете исследования от своих HTML, и вам не нужно бороться с фреймворком.

Существуют и другие трудности, если вы хотите поиграть с плагином fields - но, к сожалению, его придется сохранить для другого поста.

Представления, которые, как я подозреваю, сопоставляются одинаково - я не уверен - но на данный момент я оставил все представления на одном уровне в grails-app / views (например, папки site и siteRest расположены сбокубок о бок в grails-app / views).

Теперь вы можете использовать, скажем, generate-all xyxDomainClass, и переместить сгенерированные файлы в требуемую структуру вашего контроллера.

PS Я использую intellij, и у меня возникли проблемы с кэшированием в IDE, и я жалуюсь, что он может / не может что-то найти при выполнении приложения "run".В основном, если вы используете представление Grails и «boot-run», и оно работает, но ваша IDE жалуется, тогда у вас есть проблема.

Если вы выбираете область пакета (службы, домены и т. Д.) И правонажмите и найдите опцию «перестроить» на полпути вниз - похоже, это сбрасывает кэш в этой области, и действие запуска действия для приложения в Application в IDE снова начинает работать.Это кажется особенно чувствительным к изменениям в ваших моделях доменов и возможным службам данных Grails, генерируемым генерацией всех.Выполнение действия rebuild, кажется, очищает кеши и возвращает вас к работе.

Если вы хотите увидеть некоторые из этой структуры, вы можете посмотреть на этот проект на GitHub, который показывает работу на сегодняшний день

Пример .