DSL for Grails

Table of Contents

Coding Style Guide for Grails Application Development

Here are some guidelines that should ease application maintenance:

Method Modifiers:
- Use protected, private and final modifiers for methods in a controller that are not actions.
Coding Style:
- Prioritize concise code, while maintaining clarity.
- Employ @GrailsCompileStatic or @CompileStatic annotations throughout the codebase.
Stateless Actions:
- Always design actions to be stateless and avoid using sessions.
Controller Traits:
- Refrain from using services to implement Controller traits.
@Transactional Annotation:
- Reserve the @Transactional annotation solely for controller actions.
General Rules:
- Use the final modifier when appropriate.
- Adhere to the DRY (Don’t Repeat Yourself) principle.
- Keep the scope of symbols the shortest to enhance code readability.
- Opt for concise and meaningful local variable names.
- Clearly specify public method parameters and member names.

By following these guidelines, you can maintain a clean and expressive codebase for your Grails application.

class Book {
    String title
}

class name localisation "book.label = Libro"
class field name localisation "book.title.label = Título del libro"
To be efficient
- do not translate too early
- when you have a global overview, start translating
- keep the most important label short, use the default namespace for them, specialized label can be long
Use convention for your i18n:
- prefix with "default." everything that could be reused
- do not prefix class name translated
- In crew app, we use actions and domains specific property files (See Crew i18n folder)

Common i18n should be localized into Crew app module or Server, properties are not private to an app module.

Use enum, in code, for configuration
- Static is king
- Groovy Enums are readable (more than XML, Json, Yaml … whatever)

Security-related code should be located near the point of influence
- We do want to avoid centralization for all concerns
  - Create a new domain per needs, avoid cluttering User class
  - Abstract concepts should be minimized for security purposes; static checks are crucial
Avoid complex rules that can’t be verified statically during compilation
Administrative rules must not rely on permission strings, a boolean value in an object is more explicit when testing in code.

Avoid cyclic dependencies in domain (User ⇒ Cart AND Cart ⇒ User) if domain classes belong to different app modules
Domain classes should be barely minimal
No helper with external dependencies in domain