scaffolding/src/main/templates/scaffolding/show.gsp has:

           <f:display bean=...
            </ol>

There is correctly no opening <ol> since that is handled within f:display, so the ending </ol> should removed.

(Originally asked this on Staskoverflow here: http://stackoverflow.com/questions/35805725/grails-3-x-x-ignores-plugin-based-scaffolding-templates)

We have created a theme plugin for Grails since we have a requirement for all our applications to have a common look and feel. The theme has all kinds of TagLibs and also has custom scaffolding templates under src/main/templates/scaffolding.

We then install this plugin into our applications by adding a "compile" dependency in our build.gradle file.

This works in most cases but we are getting inconsistent behavior. Sometimes, the plugin's scaffolding templates are ignored with we do grails generate-all. Interestingly enough, if we do grails install-templates, it is always the plugin's scaffolding templates that are copied into the application. Once we have done this, sometimes generate-all uses the plugin scaffolding templates (now copied into the application), sometimes not.

We tried various versions of grails so see if there are some difference. So far, we found that:

• 3.0.10 seems to require an install-template before generate-all can use the templates
• 3.0.12 seems to use the plugin's scaffolding templates (without needing to run grails install-templates)
• 3.1.1 seems to ignore the plugin's scaffolding templates all the time (with or without install-templates)

We tried all kinds of run-app, clean before/after running generate-all under 3.1.1 and scaffolding templates are ignored.

What we want is for Grails to always use the plugin's scaffolding templates WITHOUT having to do a grails install-templates in the application that uses the plugin (this way, if we run into a situation where the application may have an older copy of the plugin's templates).

What is the magic trick to get a consistent behavior here?

Should we bundle our own generate command in our plugin (if so, any pointers as to how to do this)?

Could Grails version differences between the plugin the application explain the inconsistent behavior (plugin is currently developed in Grails 3.0.11)?

As GORM 6 has support for multi tenancy, scaffolded controllers for multi tenant domains should take into account the current tenant, which RestfulController (the super class for scaffolded controllers) don't.

ScaffoldingControllerInjector should detect that:

1. GORM 6 is being used
2. The scaffold property points to a domain class that implements MultiTenancy

If "1" and "2" are true, then the super class must be something that exposes the same actions as RestfulController but whose actions are tenant id aware, like:
def delete() { Tenants.withCurrent { resource.withTransaction { transactionStatus -> ... } } }

If "1" or "2" are false then should behave as today

Altering src/main/templates/scaffolding/Controller.groovy does not work. After moving this to web profile install-templates does not create dynamic scaffolding controller template, and even manually created file does not affect generated controller

With a simple Book / Author example it seems that the scaffolded 'create new author' view is not rendering a provision for adding a 'book' (created on the spot, or already existing in the system) to the 'hasMany books' association. I'm using Grails 3.1.2 with scaffolding plugin 3.2.1 . Here is my use case:

// Model
class Book {
String title
}

class Author {
String name
static hasMany = [books: Book]
}

// Controllers
class BookController {
static scaffold = Book
}

class AuthorController {
static scaffold = Author
}

I certainly might be missing something but with such a straightforward example I'm wondering if this might be a bug with either the scaffolding plugin, grails, or the interaction between the two...

Steps to Reproduce

1. create a domain (domain1) that is empty
2. create another domain (domain2) that has a field Domain1 domain1 as a one-to-one relationship
3. create controllers for the domains with static scaffold = Domain1 / Domain2
4. start the application
5. create an instance of domain1 (object1)
6. create an instance of domain2 that references object1
7. delete object1

Expected Behaviour

The application should give an error message that the object cannot be deleted due to the violated foreign key constraint.

Actual Behaviour

The application prints a whole stack trace, which would only be helpful for developers but not for normal users

How It Can Be Fixed

By surrounding the method call delete() with a try-catch block in the Controller-Template the problem would be fixed:

import org.springframework.dao.DataIntegrityViolationException

...

def delete(${className} ${propertyName}) {

...

    try {
        ${propertyName}.delete(flush: true)
        flash.message = message(code: 'default.deleted.message', args: [message(code: '${propertyName}.label', default: '${className}'), params.id])
        redirect(action: "index")
    }catch (DataIntegrityViolationException e) {
        flash.message = message(code: 'default.not.deleted.message', args: [message(code: '${propertyName}.label', default: '${className}'), params.id])
        redirect(action: "show", id: params.id) 
    }
}

Environment Information

• Operating System: Ubuntu
• Grails Version: 3.1.7
• JDK Version: 1.7

Example Application

See attachment

It's pretty annoying that groovy scaffolding template files in src/main/templates have the file extension .groovy because IDEs assume they are groovy files and annoy you forever that their syntax is invalid. In point of fact, they are not groovy files, they are a mish mash of groovy and some other stuff. Just like Microsoft Excel templates have different file extension (.xlsx) compared to regular Excel files (.xls), these non-groovy half-groovy templates deserve their own file extension, such as .groovyt or something. I could say the same thing about .gsp template files, should be .gspt.

Who knows... if you differentiate them thus, Jetbrains might even write a syntax checker for them.

In Grails 4.0.3 and Grails 3.3.11, if you have a domain class named A, e.g.

package mypackage

abstract class A {
  String name
  // ...
  // properties
  // ...
}

And you populate it in Bootstrap.groovy, e.g.

package mypackage

class BootStrap {

    def init = { servletContext ->
        A.withTransaction { status ->
            A.saveAll( 
                new A( name: "a1" ),
                new A( name: "a2" ),
                new A( name: "a3" )
            )
        }
    }
    def destroy = {
    }
}

If you use scaffolding (create-scaffold-controller A), everything works correctly.

But if you delete the scaffolding controller and generate-all for your class A, everything fails throwing a java.lang.NullPointerException because the AService aService object is null in AController.groovy, i.e. the service object is not properly injected in the controller.

Now, if you delete all the generated files except the domain class file (A.groovy), rename the file and the class as, let's say, A1, and generate-all again, everything works!

You can try with any one-letter named classes, e.g. A, B, X, etc., and the generated code always fails for the same reason. Add another character to the class name, regenerate, and everything works!

I suppose there must be some name clash somewhere when a class is named with a single character.

In the views directory _fields I have several widgets and wrappers. The one for a date picker has this line in it: <g:datePicker name="${property}" value="${value}" precision="${constraints?.attributes?.precision}" years="${constraints?.attributes?.years}"/> That way I can specify everything from the domain class - how the date is displayed, the precision of the date picker, etc.
This is the error when it tries to generate the GSP: Error executing tag <f:all>: Error evaluating expression [constraints.attributes.precision] on line [7]: No such property: attributes for class: org.grails.scaffolding.model.property.Constrained I looked at the code on GitHub and can't find attributes as a property. At the moment I've fallen back on the old _form.gsp template.

In Grails 4.0.3 and Grails 3.3.11, if you have an inheritance hierarchy with an abstract superclass, e.g.

package mypackage

abstract class A {
  String name
  // ...
  // properties
  // ...
}

package mypackage

class B extends A {
  String b
  // ...
  // properties
  // ...
}

package mypackage

class C extends A {
  String c
  // ...
  // properties
  // ...
}

And you populate the concrete classes in Bootstrap.groovy, e.g.

package mypackage

class BootStrap {

    def init = { servletContext ->
        A.withTransaction { status ->
            def listOfB = []
            (1..25).each { i ->
                listOfB << new B(name:"b${i}",b:"${i}st")
            }

            B.saveAll( listOfB )

            def listOfC = []
            (1..25).each { i ->
                listOfC << new C(name:"c${i}",c:"${i}nd")
            }

            C.saveAll( listOfC )
        }
    }
    def destroy = {
    }
}

If you use scaffolding, the index page for A shows an empty list instead of a paginated list of 50 objects (25 B objects and other 25 C objects).

Apart from that, it shows a new button that generates a java.lang.InstantiationException when clicked because it tries to instantiate an abstract class.

A quick and dirty workaround for this problem is the following:

1. Generate views for the abstract class (only index.gsp is relevant)
2. Edit the generated index.gsp in the following way:

• Comment the new button code

<!-- no create button -->
<!--
<li><g:link class="create" action="create"><g:message code="default.new.label" args="[entityName]" /></g:link></li>
-->

• Comment the <f:table> element and add the following code

<!-- new arguments for f:table -->
<g:set var="collection" value="${mypackage.A.list(params)}" />
<g:set var="domainClass" value="${grailsApplication.getDomainClass('mypackage.A')}" />
<g:set var="domainProperties" value="${domainClass.getConstrainedProperties().keySet()}" />
<!-- old f:table -->
<!-- <f:table collection="${aList}" /> -->
<!-- new f:table -->
<f:table collection="${collection}" properties="${domainProperties}" />            

With respect to <f:table> attributes:

• The aList variable originally passed to <f:table> is null.
• Do not include domainClass="mypackage.A", it generates a java.lang.InstantiationException.
• The properties attribute must be present and contain the list of properties of the abstract class only. If it is not present, and objects of classes A and B appear in the same pagination, a org.springframework.beans.NotReadablePropertyException is thrown because <f:table> tries to read properties of class B on objects of class C and viceversa.

Apart from that, the create and edit pages are still available for A. I have generated-all for A and tried to delete those methods from the generated controller, but my knowledge of Grails is limited and I am having lots of errors with that, so I went back to scaffolding (which is my main reason for using Grails).

I think that Grails should not show empty lists for abstract classes in scaffolding, but I do not know if that behaviour is inside the scaffolding controller, the <f:table> tag, or harcoded in _table.gsp.

I also think that Grails should not generate create and update methods in the scaffolding controllers for abstract classes.

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.

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.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/checkout digest to 692973e
• Update dependency gradle to v7.6.4
• Update plugin com.gradle.enterprise to v3.17.6
• Update dependency org.grails:grails-bom to v6.2.0
• Update dependency org.grails:grails-gradle-plugin to v6.2.0
• Update dependency gradle to v8
• Update plugin com.gradle.common-custom-user-data-gradle-plugin to v2
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

In my grails 5.0.1 instalation, the command generate-all is generating only the artifacts to the first domain. The command: grails generate-all business/ * --force

See below the domains list. Only the Area domais is considered for the command. Thanks.

Thanks

Hi,

When I create a fresh project with just a barebones domain class and generated scaffolding, running the tests results in two failures. I am not sure if this is working as intended since there is not an awful lot of thorough documentation for the 3.x plugins out there yet. Since there are no constraints on newly created domain classes, I would expect the generated tests to pass, though.

Given the folowing setup:

~ $ grails -version
| Grails Version: 3.0.1
| Groovy Version: 2.4.3
| JVM Version: 1.8.0_45

~ $ grails create-app com.myapp.backend.images.image-services
| Application created at ~/image-services

~ $ cd image-services
~/image-services $ grails
[...]

grails> create-domain-class image
| Created grails-app/domain/com/myapp/backend/images/Image.groovy
| Created src/test/groovy/com/myapp/backend/images/ImageSpec.groovy

grails> generate-all com.myapp.backend.images.Image
| Rendered template Controller.groovy to destination grails-app\controllers\com\myapp\backend\images\ImageController.groovy
| Rendered template Spec.groovy to destination src\test\groovy\com\myapp\backend\images\ImageControllerSpec.groovy
| Rendered template edit.gsp to destination grails-app\views\image\edit.gsp
| Rendered template create.gsp to destination grails-app\views\image\create.gsp
| Rendered template index.gsp to destination grails-app\views\image\index.gsp
| Rendered template show.gsp to destination grails-app\views\image\show.gsp
| Scaffolding completed for grails-app\domain\com\myapp\backend\images\Image.groovy

grails> test-app

I took the liberty to format the output somewhat more nicely:

com.myapp.backend.images.ImageControllerSpec
    Test the save action correctly persists an instance
        Condition not satisfied:

        model.image!= null
        |     |    |
        [:]   null false

    at com.myapp.backend.images.ImageControllerSpec.Test the save action correctly persists an instance(ImageControllerSpec.groovy:44)

    Test the update action performs an update on a valid domain instance
        Condition not satisfied:

        view == 'edit'
        |    |
        null false

    at com.myapp.backend.images.ImageControllerSpec.Test the update action performs an update on a valid domain instance(ImageControllerSpec.groovy:109)

Cheers,
Michael

After working on upgrading to Grails 5, the scaffold setup doesn't seem to be working with the error Could not resolve view with name 'list' in servlet with name 'grailsDispatcherServlet'

GSP file

            <g:link action="list" controller="AuthorisedUser">
                <g:message code="authorised.users.label" default="Maintain Authorised Users for 'Reinsurer Inquiry Status' section" />
            </g:link>

Controller

class AuthorisedUserController {

    static allowedMethods = [save: "POST", update: "POST", delete: "POST"]

    def scaffold = AuthorisedUser
    
    /**
     * Method to display list of Authorized users.
     * @param max
     * @return
     */
    def list(Integer max) {
        params.max = Math.min(max ?: 10, 100)
        [authorisedUserInstanceList: AuthorisedUser.findAllByInactive(false,params), authorisedUserInstanceTotal: AuthorisedUser.count()]
    }
}

Domain

class AuthorisedUser {

    String name 
    Boolean inactive = Boolean.FALSE
    
    static constraints = {
        
        name (blank:false , nullable: false)
        inactive(blank:true, nullable: true)
    }
}

I have tried changing the version of scaffold, changing from list to show, and researching Scaffolding in Grails to see if there is some syntax missing or if any similar issues. I don't see the errors on the screen like I was expecting until I edited the error.gsp to change how it would get the message, otherwise it was a blank page. Expecting to see the list of authorized users.

Hi,
Auto-reloading in Grails is not working in Grails. I tried this on version 1.3.8 (Latest version).
It works for me on MAC, and on stackoverflow, some reports that auto-reloading works on Linux but not on Windows/

Once the fields plugin is upgraded to Grails 4, update it here: https://github.com/grails3-plugins/scaffolding/blob/c0612dbbe4156c549459059de5fbd998c9cf6d5e/build.gradle#L42

Hi,

Default views generated from scaffolding, does client side validation on fields based on the constraints defined in the domain class.

It could be a common practice, that on the update page, if a user left any of the fields empty, the behaviour should be to update all fields except those left empty.

Why these field names are not passed as parameters to the generate-all script?. This seems logical requirement and could be included in the framework and would save development time. Giving that is is applied only to modify page, (Not to create page for example).

Regards,

I've built a small grails (3.1.4) application. I have the following domain model and am using dynamic scaffolding:

class Player {

    String name
    String identifier
    int points

    static constraints = {
      identifier(display: false)
    }

    static mapping = {
      version false 
   }
}

I want to hide the identifier as shown in the code. However, the column is not hidden. Instead it is shown as the first column in the table.

According to the documentation:

http://docs.grails.org/latest/ref/Constraints/Usage.html

a display: constraint should control whether a property is displayed in scaffolding views.
a editable: constraint should control whether a property can be edited in scaffolding views

When using the default show.gsp scaffolded view,
FormFieldsTagLib line 552 calls domainModelService.getInputProperties(Impl)

This doesn't seem right it calls getINPUTproperties for a show.gsp. Surely a show.gsp should be getOutputProperties?

getInputProperties hard codes the exclusion of dateCreated, lastUpdated and version. Because it is hard coded it doesn't respect your decision to set display: true on those properties. Thus they are not displayed even when display: true is set.

when using the edit.gsp, it also calls the same method, getInputProperties. If I have a field that I do NOT want editable there, I should be able to set editable: false constraint.

However if we look at DomainModelServiceImpl.getInputProperies, it calls getProperties and there it never checks the editable: constraint. It does appear to to check constrained.display... but surely that is the OUTPUT constraint, not the input constraint. It doesn't seem like anywhere in the code it checks the editable constraint.

Task List

Steps to Reproduce

Create a domain object with a few fields, the standard lastUpdated field.
add "display: true" constraint to lastUpdated.
add "editable: false" to some other field.
Generate the standard scaffolding with edit.gsp, show.jsp

Observe that it doesn't respect display: true for lastUpdated
Observe that it doesn't respect editable: false for some other field.

Expected Behaviour

Scaffolded view should respect display: and editable: constraints like the documentation says.

Actual Behaviour

they don't.

Environment Information

• Grails Version: 4.0.11
• JDK Version: 1.8

As the title says the custom controller template is not taken into account when using dynamic scaffolding. I have created a simple project that reproduces this issue. The code works fine when using static scaffolding (the controller logs a message in the index action). In dynamic scaffolding however the code seems to be ignored and no message is logged in the index action.
Here is what i did:

1. created new project with grails create-app
2. grails install-templates
3. created a domain class book
4. Modified /templates/scaffolding/Controller.groovy to log something in the index action (and activated logging)
5. grails create-scaffold-controller then run-app and navigate to book/index (using dynamic scaffolding no message is logged. It is interesting to note that the template .gsp files are taken into account for dynamic scaffolding, while that does not seem to be the case for the Controller)
6. grails generate-controller then run-app and navigate to book/index (using static scaffolding the message is now logged)

I am using Grails 3.1.12, java version "1.8.0_45"
Link to example project

Hi,

Based on my experience using Grails since 1.3.x, I've requirements to have multiple scaffolding folders. e.g:
src/templates/scaffolding
src/templates/another-scaffolding-set
....
So, I want to propose an improvement to generate-all script by adding option to select which set of scaffolding to use (default is still src/templates/scaffolding).
How do you think about this?

In 3.1.9, I added new template pages like ( Search.gsp and _search.gsp).

After executed command generate-view au.com.bglcorp.sso.auth.SsoUser -force

It only created standard pages.
| Rendered template edit.gsp to destination grails-app/views/ssoUser/edit.gsp
| Rendered template create.gsp to destination grails-app/views/ssoUser/create.gsp
| Rendered template index.gsp to destination grails-app/views/ssoUser/index.gsp
| Rendered template show.gsp to destination grails-app/views/ssoUser/show.gsp
| Views generated for grails-app/domain/au/com/bglcorp/sso/auth/SsoUser.groovy

In grails 2.5.4, all customized pages will be copied into domain's view folder.

I'm using version 3.4.1 of the scaffolding plugin and I noticed that there is no way to disable the generatedViewCache of grails.plugin.scaffolding.ScaffoldingViewResolver.

What is the use case?

I installed the scaffolding templates to my project in order to modify them according the project needs. Since there is no way around that caching feature I have to restart the Grails application to see modifications made in the scaffolding template. This is a very time consuming job.

Possible solutions

• Introduce a toggle switch that I can address in my application.yml to enable/disable the cache.
• (In development environment only): Create a hash of the view and compare it with the hash that is currently in the cache

What do you guys think about it? Any comments?

Even though there aren't currently any tests, this project has a dependency on org.grails:grails-plugin-testing.
This library is no longer available.

~\Projects\grails\scaffolding git:[5.0.x]
./gradlew dI --dependency org.grails:grails-plugin-testing --configuration testCompileClasspath

> Task :dependencyInsight
org.grails:grails-plugin-testing: FAILED
   Failures:
      - Could not find org.grails:grails-plugin-testing:.

org.grails:grails-plugin-testing FAILED
\--- testCompileClasspath

A web-based, searchable dependency report is available by adding the --scan option.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

Grails 3.1.1. Only the three files here are installed. In the bintray branch at the same url one finds the gsp and a few other files.

In addition to the above, when I download the gsp files and put them in the right place (src/main/templates/scaffolding), make a small change (change the class="nav" to class="grails-nav") and do a grails generate-all or a grails generate-views, the change I made to the templates is ignored - they are most likely not used at all.

In Grails 3.x or even before, the generated gsp-s contain very concise code.
All of the form fields and input are dynamically generated by a tag "<f:all bean="your_domain_object"/>

However, I remember, in earlier versions of Grails, the generated gsps would allow more control and more verbose. What I mean, is that, there is no call to "<f:all bean="your_domain_object"/> and each control is rendered on the generated gsp file.
For example

<gsp:input property="#{user.name}" /> ... etc

Is this feature still supported by the latest Grails version ? Can it be brought back as it enables much more flexibility.

Hi,

It looks like the scaffolding plugin renders a "white screen of death" when the underlying domain class has embedded properties. You can find an SSCCE here.

When you comment the static embedded block in the User class out, the view will be back to normal.

Cheers,
Michael

It seems that this is done because scaffolded controllers need to have RestfulController as super class, but error is thrown even if controller extends RestfulController or a subclass of RestfulController

hi,i want to know GenerateViews.groovy
render template: template('scaffolding/edit.gsp'),
destination : file("grails-app/views/${model.propertyName}/edit.gsp"),
model: model,
overwrite: overwrite
where to render,on grails3.1.2 there is not found AbstractGrailsTemplateGenerator class. sorry about my poor english ,i from china :-D

originally filed here: grails/grails-core#9854

@donald-jackson

This is a feature request, essentially to try and get the scaffolding back to where it was in Grails 2.

Two missing features are:

Scripting is no longer supported in scaffolding templates (eg: iterating through a domain class to produce a view, conditions, etc)
Scaffolding can only use domain classes from the current project, in Grails 2 you could use any hibernate class. This is useful for some people (like me) who logically separate their GUI from their domain classes.
Thanks

I used to program in Oracle ADF long time ago. Oracle ADF has so many nice feature that I see could be migrated into grails.

Suppose I am create an Employee that belongs to a department. Instead of display the departement field as a dropdown list, I want to able to tell the script, that for this property generate an LOV window.

LOV Window: A link or a button that will open a pop-up window, to allow user to search for the department for example. Once he select the department, that will update parent page.

If you are not going to adopt this idea, can anyone please guide how to start implementing these in the Grails framework.

Is there any architectural documentation on the source code of Grails. I have so many ideas and want to contribute to the Grails open source project.

It looks like this issue is still present in the coordination between Grails 3.1.4 and the Scaffolding plugin 3.2.1. After running install-templates and subsequently modifying src/main/templates/scaffolding/index.gsp, such changes do not show up in the generated index.gsp file after running generate-views .

Steps to Reproduce

1. create an exampleDomain with a string that is unique
2. create a controller for that domain with static scaffold = exampleDomain
3. start the application
4. create two objects ("1" & "2")
5. edit the string in object "1" to "2"

Expected Behaviour

The application should give an error message that the string is unique and thus can't be renamed

Actual Behaviour

The application responds that the update was successful while the update did not actually take place

Environment Information

• Operating System: Ubuntu
• Grails Version: 3.1.6
• JDK Version: 1.7

Example Application

See attachment

I'm using Grails 3.0.1 installed via GVM

I'm not sure if this should be filed here, in the fields plugin or in grails-core.

There are a number of oddities.

Help and actuality don't seem to match

grails> help install-templates
| Command: install-templates
| Description:
Installs scaffolding templates that use f:all to render properties

| Usage:
grails install-form-fields-templates

When you try to use install-form-fields-templates the command is not found

grails> install-form-fields-templates
| Error Command not found install-form-fields-templates
Did you mean: install-templates or create-functional-test or install?

When you try to use install-templates, you get this output

grails> install-templates 
| Copying fields templates
| Error Caught exception <project path>/src/templates/scaffolding (No such file or directory) (Use --stacktrace to see the full trace)

If you then manually create the missing templates/scaffolding directory and try again...

grails> install-templates 
| Copied create.gsp to location <project path>/src/templates/scaffolding
| Copied edit.gsp to location<project path>/src/templates/scaffolding
| Template installation complete

But, that's not what actually happened

 % tree src/templates
src/templates
└── scaffolding

0 directories, 1 file

The un-suffixed file scaffolding contains what appears to be the contents of what would be the edit.gsp file.

Copied from grails/grails-core#10023 - apparently github doesn't support moving issues.

TL;DR
In Grails 3, grails.scaffolding.templates.domainSuffix is ignored by scaffolding views, both static and dynamic. This breaks apps upgrading from 2.x.

Environment:
Windows 8.1
jdk1.8.0_92
Grails 3.1.7

I have upgraded an app from 2.4 to 3.1.7 and notice issues with scaffolding. In my 2.4 app, I had in Config.groovy:

grails.scaffolding.templates.domainSuffix = 'Instance'

And I'm pretty sure that was added by default, which means this will affect a lot of people.

In my controller's index method (rendered by default with the list scaffolding view), this line worked:

List<Company> companies = Company.findAll()
respond companies, model: [companyInstanceCount: Company.count()]

In the dynamic view, companies corresponded with companyInstanceList, and the view rendered perfectly.

After upgrading to 3.1.7, both the main body (list) and pagination were empty. After testing, I discovered the following:

1. domainSuffix appears to change the model name, but not the corresponding variables in the view. Instead of expecting companyInstanceList and companyInstanceCount, it wants companyList and companyCount
2. adding domainSuffix to application.yml as such did not change this.

grails:
    codegen:
        defaultPackage: com.madeupname.web
    scaffolding:
        templates:
            domainSuffix: Instance

I tested by explicitly setting model variable names::

[companyInstanceList: companies, companyInstanceCount: Company.count()]

domainSuffix is also ignored in static scaffolding, as views generated with

grails generate-views com.madeupname.web.Company

look for companyList, not companyInstanceList, etc.

Right now, the workaround is to:

1. remove domainSuffix from config
2. Update all your controllers to remove the word Instance from model variable names

If this was intentional, the Upgrading and Scaffolding sections of the documentation should be updated to prevent confusion. But this is a breaking change, so I assume it's a bug.

Would you be so kind and release a new version of the scaffolding plugin?

I'm currently using a Jitpack dependency to get "Allow scaffold controllers to extend RestfulController" change included in my project. But an official release would of course be preferred.

Thanks a lot

Hi,
I have vanilla Grails 3.0.2 project. After execution of grails install-template there are 2 templates created, but they are put into directory /src/templates/scaffolding. After I do some changes in those templates and run generate-all, the generated files do not contain my changes.

I checked sources of the plugin and found out that the plugin reads templates from location /src/main/templates/scaffolding.
After I copied templates to that location and rerun generate-all, generated files contains all the changes I have done in templates.

Unlike rest of application and regular gsp pages dynamic scaffolding (default templates, installed or not) generates html response with HTTP header:

Content-Type:text/html;charset=ISO-8859-1

As far as I can tell this command is not present. Also mentioned the same in grails/grails-core#681

In the scaffolding controller the domain validate() method is not called before the hasErrors() check in the save and update methods of the scaffolded controller. Therefore error messages are not displayed in the create and update views after a form submit.