Обзор структуры проекта Grails

Я пытаюсь найти как можно более полный обзор структуры проекта Grails. Как я вижу, не все проекты использовали структуру по умолчанию, сгенерированную "grails create-app"

%PROJECT_HOME%
    + grails-app
       + conf                 ---> location of configuration artifacts 
           + hibernate        ---> optional hibernate config
           + spring           ---> optional spring config
       + controllers          ---> location of controller artifacts
       + domain               ---> location of domain classes
       + i18n                 ---> location of message bundles for i18n
       + services             ---> location of services
       + taglib               ---> location of tag libraries
       + util                 ---> location of special utility classes 
       + views                ---> location of views
           + layouts          ---> location of layouts
   + lib
   + scripts                  ---> scripts
   + src
       + groovy               ---> optional; location for Groovy source files
                                   (of types other than those in grails-app/*)
       + java                 ---> optional; location for Java source files
   + test                     ---> generated test classes
   + web-app
       + WEB-INF

Есть ли еще какие-нибудь папки по умолчанию для Grails? (Например, я видел grails-app/jobs)


grails
person Hoàng Long    schedule 01.12.2010    source источник
comment
Там есть src/templates, если вы устанавливаете плагин скаффолдинга. grails-app/jobs предназначен для заданий Quartz (предлагает функциональность, подобную cron).   -  person Gregor Petrin    schedule 01.12.2010
comment
Существуют ли какие-либо правила относительно папки плагинов?   -  person Hoàng Long    schedule 02.12.2010

Ответы (1)


arrow_upward
9
arrow_downward

Структура каталогов соблюдается по большей части всеми приложениями, потому что артефакты определяются в первую очередь их корневой папкой. Имена классов контроллеров заканчиваются на «Контроллер», а библиотеки тегов и сервисы имеют схожие соглашения об именах, но классы предметной области не имеют ограничений на имена. Таким образом, именно расположение в grails-app/domain определяет класс groovy как класс предметной области.

Однако Grails позволяет приложениям и подключаемым модулям определять дополнительные типы артефактов, и это то, что вы видите в папке «jobs». Это создано плагином Quartz. Я делаю что-то подобное в плагине динамических контроллеров, где добавляю новую папку controllerMixins в приложение grails, где хранятся классы миксинов контроллера.

Преимущество создания нового артефакта вместо сохранения кода в src/groovy заключается в том, что легко поддерживать перезагрузку в режиме разработки и логически группировать код, а не сбрасывать все в одну папку (src/groovy) и полагаться на пакеты для сохранения вещей. отдельный. У вас также есть быстрый доступ ко всем артефактам любого типа. application.getDomainClasses() возвращает все классы предметной области, но этот метод разрешается динамически, поэтому, если у вас установлен Quartz, вы автоматически получаете поддержку application.getJobClasses() без необходимости регистрировать или настраивать что-либо помимо стандартной регистрации артефакта.

person Burt Beckwith    schedule 02.12.2010