You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The scaffolding system assumes you want a FooController to provide editing for the Foo domain class.
Sometimes you want another controller to edit the same domain class that provides a different view of the same domain. Maybe it's because the one domain has several possible views of the data, or maybe different classes of user want a different view of the data. This would be very easy to support with a few minor adjustments. Right now, the scaffolding system completely breaks down if you want to do that, but with only a very tiny set of patches could be made to work in this scenario. Basically the current setup is unnecessarily tied to going back to the [ClassName]Controller, when if everything defaulted to the current controller, whatever that may be, it would be far more flexible.
In other words have a:
class BarController {
static scaffold = Foo
BarService barService
}
The src/main/templates/scaffolding/Controller.groovy scaffolding template, in a few places has this code:
redirect ${propertyName}
If it was changed to say:
redirect action: 'show', id: ${propertyName}.id
This very minor change would make the system far more flexible, to create new controllers that are not named after the domain class, and yet can make full use of scaffolding.
Then the template forms would be far more generic. At the end of the day, the same HTML would come out for the common case, but you'd also get the correct HTML for these other scenarios.
The text was updated successfully, but these errors were encountered:
The scaffolding system assumes you want a FooController to provide editing for the Foo domain class.
Sometimes you want another controller to edit the same domain class that provides a different view of the same domain. Maybe it's because the one domain has several possible views of the data, or maybe different classes of user want a different view of the data. This would be very easy to support with a few minor adjustments. Right now, the scaffolding system completely breaks down if you want to do that, but with only a very tiny set of patches could be made to work in this scenario. Basically the current setup is unnecessarily tied to going back to the [ClassName]Controller, when if everything defaulted to the current controller, whatever that may be, it would be far more flexible.
In other words have a:
The src/main/templates/scaffolding/Controller.groovy scaffolding template, in a few places has this code:
redirect ${propertyName}
If it was changed to say:
redirect action: 'show', id: ${propertyName}.id
This very minor change would make the system far more flexible, to create new controllers that are not named after the domain class, and yet can make full use of scaffolding.
In a similar way, if the grails table plugin were changed..... https://github.com/grails-fields-plugin/grails-fields/blob/master/grails-app/views/templates/_fields/_table.gsp
<g:link method="GET" resource="${bean}">
were changed to:
<g:link method="GET" action="show" id="${bean.id}">
and if the generated src/main/templates/scaffolding/edit.gsp's template form definition were changed from:
<g:form resource="\${this.${propertyName}}" method="PUT">
to
<g:form action="save" id="\${propertyName}.id" method="PUT">
Then the template forms would be far more generic. At the end of the day, the same HTML would come out for the common case, but you'd also get the correct HTML for these other scenarios.
The text was updated successfully, but these errors were encountered: