The Grails® framework Scaffolding plugin replicates much of the functionality from Grails 2, but uses the fields plugin instead.
Please check the Grails Plugin Portal for the latest available version.
Scaffolding plugin for Grails® framework
License: Apache License 2.0
The Grails® framework Scaffolding plugin replicates much of the functionality from Grails 2, but uses the fields plugin instead.
Please check the Grails Plugin Portal for the latest available version.
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:
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:
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...
The application should give an error message that the object cannot be deleted due to the violated foreign key constraint.
The application prints a whole stack trace, which would only be helpful for developers but not for normal users
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)
}
}
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:
index.gsp
is relevant)index.gsp
in the following way:<!-- no create button -->
<!--
<li><g:link class="create" action="create"><g:message code="default.new.label" args="[entityName]" /></g:link></li>
-->
<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:
aList
variable originally passed to <f:table>
is null
.domainClass="mypackage.A"
, it generates a java.lang.InstantiationException
.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.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
.github/workflows/gradle.yml
actions/checkout v4
actions/setup-java v4
gradle/gradle-build-action v3
actions/checkout v4
actions/setup-java v4
gradle/gradle-build-action v3
.github/workflows/release-notes.yml
actions/checkout v4@3df4ab11eba7bda6032a0b82a6bb43b11571feac
release-drafter/release-drafter v6
ncipollo/release-action v1
.github/workflows/release.yml
actions/checkout v4@3df4ab11eba7bda6032a0b82a6bb43b11571feac
actions/setup-java v4
gradle/gradle-build-action v3
gradle/gradle-build-action v3
gradle.properties
org.grails:grails-bom 6.1.1
io.github.gpc:fields 5.0.3
settings.gradle
com.gradle.enterprise 3.17.1
com.gradle.common-custom-user-data-gradle-plugin 1.13
build.gradle
buildSrc/build.gradle
org.grails:grails-gradle-plugin 6.1.1
gradle/wrapper/gradle-wrapper.properties
gradle 7.6.3
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.
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.
Scaffolded view should respect display: and editable: constraints like the documentation says.
they don't.
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:
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
application.yml
to enable/disable 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
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 .
The application should give an error message that the string is unique and thus can't be renamed
The application responds that the update was successful while the update did not actually take place
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:
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.