Grails 4 SOC - ScaffoldingController with a Service
- Dominant language
- Groovy
- Stars
- 2.9k
- Forks
- 975
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 92
Description
**Separation of Concerns**
I constantly find myself in situations wishing I could scaffold a Controller using a Service instead of a Domain Object. Why? Because there is so much boiler plate code in a Controller that I hate seeing it over and over again when I need to introduce a little more advanced business logic that has nothing to do with the Controller. Upgrading large Controllers with the same boilerplate code also starts to become a nightmare.
Solution? Allow the scaffold property to take either a Domain object OR a Domain Service.
Everything can work the same as defined by
https://docs.grails.org/latest/guide/scaffolding.html
it just uses
```
class BookController {
static scaffold = bookService
}
```
and works according to how the Scaffolding plugin ALREADY creates a Controller.
https://github.com/grails3-plugins/scaffolding/blob/master/src/main/templates/scaffolding/Controller.groovy
which would depend on the service having the following methods:
```
${propertyName}Service.list(params)
${propertyName}Service.count()
${propertyName}Service.save(${propertyName})
${propertyName}Service.get(id)
${propertyName}Service.delete(id)
```
Contributor guide
Research direction
Start with the scaffolding guide and the referenced scaffolding/Controller.groovy template to understand the existing domain-object flow. Define how static scaffold should accept a service and confirm the listed list, count, save, get, and delete methods are sufficient; done means a controller can be generated from a service without the domain-object requirement.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- groovy
- Domain
- backend, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100