grails/grails-core

Controllers with dynamic scaffolding ignore templates in Grails 3.3.x !

aadrian opened this issue ยท 18 comments

Task List

  • Steps to reproduce provided
  • Stacktrace (if present) provided
  • Example that reproduces the problem uploaded to Github
  • Full description of the issue provided (see below)

Steps to Reproduce

  1. Install the templates with install-templates like it was done in : aadrian/fieldbugs1@f397dd9
  2. Modify the installed templates, (to correspond to the requirements). In this example aadrian/fieldbugs1@e964d2a just make the default page size smaller to be able illustrate the issue.
  3. Run the application with grails run-app from https://github.com/aadrian/fieldbugs1/ and see http://localhost:8080/tableOne/index : the template is not applied since the page is still 10 in size (not 3) :( .
  4. Changes done to Views Templates work however: aadrian/fieldbugs1@cb5dd08 , so only the Controllers seem so far to be affected :( .

Expected Behaviour

Controllers with dynamic scaffolding in Grails 3.3.x should use their scaffold templates from /src/main/templates/scaffolding the same way they did in Grails 2.x, or how the the Views still do.

Nobody is expecting "hot reloading" (since even with Grails 2.x, when modifying the Controller templates it required an application restart.) , but templates should not be ignored.

Actual Behaviour

Controller with dynamic scaffolding seem to ignore the template /src/main/templates/scaffolding/Controller.groovy

This is a serious issue, since:

  • it was working with Grails 2.x very stable and without problems for years.
  • it's the main reason many of us adopted Grails in projects in first place: the possibility not to have to maintain 90% of the code, since it's all the same like in the tuned templates.
  • if later changes were required, implementing them (and also reliably testing them) was trivial even for newbies.
  • the workaround now requires making the code static: aadrian/fieldbugs1@7d6f313 , but this practically throws away the main selling point of Grails :(

Environment Information

  • Operating System: OSX, Linux, Win 7,8,10
  • Grails Version: 6.1.9
  • JDK Version: 3.3.3
  • Container Version (If Applicable): 1.8.0_162

Example Application

https://github.com/aadrian/fieldbugs1

Thank you.

@jeffbrown grails-scaffolding seems to contain only the generators and some templates, but not the dynamic loading part of controller that could cause such a bug - at least from a simple search, hence my submit to this part or the Grails platform.

Independent of "in what sub-part of Grails" this error happens, it's a serious bug for us.

Together with the other bugs I reported in https://github.com/aadrian/fieldbugs1/blob/master/README.md and others reported by other users affecting the 3.3.x versions, this wasted us a staggering amount of time and resources to make "kinda workarounds" for something that with Grails 2.5.x simply "just worked" :( .

Apologies. https://github.com/grails3-plugins/scaffolding is probably the correct place. That was my mistake. I am sorry.

Is this a duplicate of grails/scaffolding#17?

Is this a duplicate of grails/scaffolding#17?

I have no idea, since that Issue does not seem to provide much detail, nor does it have a reproducible example as required by the submit guidelines.

Thanks for the feedback.

https://github.com/grails3-plugins/scaffolding is probably the correct place.

I'll copy the issue there (if that's the correct ontology for it), since GitHub does not seem to have "move issue to another project" functionality.

The real question however independent on what "label" this bug is getting:

  • will it be fixed for the next release (and when is 3.3.4 planned to be released)?

Thank you.

will it be fixed for the next release

I do not yet know.

This bug is one that seems to break the most the backward compatibitliy, since it makes the the template code useless :( .

@aadrian This will not work exactly as it did in Grails 2.x. The view templates are being applied correctly(*.gsp), however the controller templates are only used when the create-x commands are executed. For example ./grailsw create-controller Foo will use the src/main/templates/scaffolding/Controller.groovy.

If you wish to have a standard set of functionality for controllers, you can simply extend the RestfulController class and have your controllers extend that class.

@aadrian For example:

class TableOneController extends DefaultController<TableOne> {
    
    TableOneController() {
        super(TableOne)
    }
}

@InheritConstructors
class DefaultController<T> extends RestfulController<T> {

    def index(Integer max) {
        params.max = Math.min(max ?: 3, 100)
        respond listAllResources(params), model: [("${resourceName}Count".toString()): countResources()]
    }
}

however the controller templates are only used when the create-x

This is a huge feature downgrade :( !

IMHO this should not be closed but fixed, and this is also definetely a bug since dynamic scaffolding is not working correctly - on this sole feture depend just too many applications :( .

Proclaming this as "not a bug" is simply astounishing :( .

@aadrian I provided you with a way to achieve the exact same thing, so I fail to see that any functionality is lost.

I provided you with a way to achieve the exact same thing so I fail to see that any functionality is lost.

I can just hope you are not serious on this matter :( .

I can just hope you are not serious on this matter

Yes, we are serious.

Of course input is welcomed and we need that but comments like "I can just hope you are not serious on this matter" and "Proclaming this as not a bug is simply astounishing" are not particularly helpful in terms of contributing to progress. A comment like "since it makes the the template code useless" is demonstrably false.

Thanks for your help!

In my opinion it's a bug and the workaround mentioned by @jameskleeh makes it harder to maintain a central custom controller:

As the controller template isn't plain groovy with IDE-support, but groovy-placeholders within groovy which then get some spring-parts injected, it's rather complicated to ensure that the controller-template is correct.

With the same template for static and dynamic scaffolding (grails v2) you can simply test the changes of the scaffolding-template by generating a static controller. So you are able to see the changes you made and understand the adaption more easily.

With the workaround-extended-controller, you would have 2 different code-bases for different controllers:

  • a complicated to understand and maintain abstract dynamic-scaffolding-controller, which you cannot generate and f.e. easily see typos
  • a simple-to-understand and maintain static-scaffolding-controller, but which results in lots of duplicated code for every controller

Another interesting part would be the interaction with plugins, which i suspect may behave different with the static-scaffolding-controller than with the custom abstract one...

I'm curious on the status of thus bug, as I came across it in 4.0.9. I thought it was exceedingly odd that the gsp templates are dynamically generated, but the controllers are not. If this is not considered a bug and/or nobody is going to fix it, then at the very least, please please document what is supposed to happen, because right now the situation seems pretty bizarre with this half-assed view but not controller setup, that you have to spend all day trying to figure out.

Hello, did someone tried to fork the scaffolding plugin to fix this issue ?

I think at least the documentation should tell that the dynamic scaffolding didn't produce the same output as the static one and relies only partially on installed templates (gsp only).

We are on a projet that is using multitenancy, and scaffolding just doesn't work out of the box.

We have to install the templates and adjust them to our need. As the controllers are not properly dynamically generated from templates, we have to generate static content for all our domains. It works, but the documentation is a bit imprecise here.