example - Descripción general de la estructura del proyecto Grails

grails tutorial

Question

Estoy tratando de encontrar la descripción general sobre la estructura del proyecto Grails, de la manera más completa posible. Como veo, no todos los proyectos usaron la estructura predeterminada generada por "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

¿Hay alguna carpeta más por defecto de Grails? (Por ejemplo, vi grails-app / jobs)

Answer 1

La estructura de directorios es seguida en su mayor parte por todas las aplicaciones porque los artefactos se definen principalmente por su carpeta raíz. Los nombres de clase de controlador terminan en ''Controlador'', y los taglibs y servicios tienen convenciones de nomenclatura similares, pero las clases de dominio no tienen restricciones de nombre. Entonces, es la ubicación en grails-app / domain que define una clase groovy como una clase de dominio.

Sin embargo, Grails permite que las aplicaciones y los complementos definan tipos de artefactos adicionales, y eso es lo que está viendo con la carpeta ''trabajos''. Eso es creado por el plugin de Quartz. Hago algo similar en el plugin dynamic-controllers donde agrego una nueva carpeta controllerMixins en la aplicación grails-donde se guardan las clases de mixin controlador.

El beneficio de crear un artefacto nuevo en lugar de mantener el código bajo src / groovy es que es sencillo admitir la recarga en modo de desarrollo y agrupa el código lógicamente en lugar de volcar todo en una carpeta (src / groovy) y confiar en los paquetes para mantener las cosas separar. También tiene acceso rápido a todos los artefactos de cualquier tipo. application.getDomainClasses() devuelve todas las clases de dominio, pero el método se resuelve dinámicamente, de modo que si tiene Quartz instalado automáticamente obtendrá soporte para application.getJobClasses() sin tener que registrar o configurar nada más allá del registro de artefactos estándar.