@org.gradle.api.tasks.CacheableTask @CompileStatic abstract class GenerateScaffoldedViewsTask extends DefaultTask
Expands the scaffolding templates at build time, so the pages a scaffolded controller renders are compiled with the rest of the application instead of on the request that first asks for them.
Scaffolding expands a template into GSP source and compiles the result. At runtime that costs the first request on the JVM, and a native image cannot do it at all: defining a class at runtime is exactly what an ahead-of-time image gives up. The pages written here are compiled by the ordinary GSP compiler instead.
They are written under grails-scaffolded/<domain class>/, a directory no controller's
views resolve from, and each is named for its template and a digest of the template and the model
it was expanded with. The runtime resolver decides which page a request gets exactly as it would
without them - a view the application or a plugin declares, a namespace-specific template, a
template override - and only where it would expand a template does it look for the page expanded
from the same template and model. So a page cannot shadow a declared view, and a template this
task did not expand finds nothing and is expanded at runtime as before.
For each scaffolded controller - the application's own, and those plugins on the runtime classpath provide whose domain classes the pages can be compiled against - this expands for its domain class every copy of each template the resolver could choose for it:
src/main/templates/scaffolding or its resources, and each on the runtime classpath -
and whichever the resolver chooses has its page.admin/show.gsp can only be chosen for a
controller with a namespace, so it is expanded only for the domain classes such controllers
scaffold.No application class is loaded: the controllers are read with ASM, and the pages are expanded
and named by org.apache.grails.scaffolding.ScaffoldedPagesGenerator, run in a JVM on the
application's runtime classpath, from the same code and the same Groovy as the resolver's.
| Modifiers | Name | Description |
|---|---|---|
static int |
GENERATOR_PROTOCOL |
The version of the exchange with the generator this task speaks - the command line, and the
files handed over and back - as the generator declares its own in a PROTOCOL
constant. |
| Type | Name and description |
|---|---|
static java.lang.String |
GENERATORThe class that expands and names the pages, from the application's scaffolding library. |
| Constructor and description |
|---|
GenerateScaffoldedViewsTask() |
| Type Params | Return Type | Name and description |
|---|---|---|
|
void |
generate() |
|
abstract ConfigurableFileCollection |
getClassesDirs()Compiled application classes, searched for scaffolded controllers. |
|
abstract ExecOperations |
getExecOperations() |
|
java.lang.String |
getFileSeparator()The separator the pages were expanded under. |
|
abstract Property<JavaLauncher> |
getJavaLauncher()The Java the pages are expanded with; the build's own when not set. |
|
abstract RegularFileProperty |
getOptionalPages()Lists, a line apiece, the pages expanded from templates a dependency supplies, as paths under getOutputDirectory(), for the page compilation to leave out any that do not compile. |
|
abstract DirectoryProperty |
getOutputDirectory()Where the pages are written, as a tree to be compiled with the application's views. |
|
abstract ConfigurableFileCollection |
getPackagedTemplates()The application's templates as it packages them, each at META-INF/templates/scaffolding/<template path> in its tree: normally the output of
processResources, filtered to them. |
|
abstract ConfigurableFileCollection |
getPageClasspath()The classpath the pages are compiled against: normally compileGroovyPages'. |
|
abstract Property<java.lang.String> |
getPageEncoding()The encoding the pages are written in, which must be the one they are compiled with, so that a page reads back as it was expanded. |
|
abstract ConfigurableFileCollection |
getRuntimeClasspath()The application's runtime classpath. |
|
abstract ConfigurableFileCollection |
getTemplateOverrides()The application's own templates, as trees rooted at the template directory: normally src/main/templates/scaffolding. |
The version of the exchange with the generator this task speaks - the command line, and the
files handed over and back - as the generator declares its own in a PROTOCOL
constant. The two ship apart, the generator in grails-scaffolding and this in the Gradle plugin,
so a build can pair one version with another; this reads the generator's before running it.
The class that expands and names the pages, from the application's scaffolding library.
Compiled application classes, searched for scaffolded controllers.
The separator the pages were expanded under. A template that mentions packagePath
expands differently on Windows, so pages built on one platform are not taken from the build
cache for another.
The Java the pages are expanded with; the build's own when not set.
Lists, a line apiece, the pages expanded from templates a dependency supplies, as paths under getOutputDirectory(), for the page compilation to leave out any that do not compile. A page expanded from a template of the application's own is not listed, so it has to compile, as a view does.
Where the pages are written, as a tree to be compiled with the application's views.
The application's templates as it packages them, each at
META-INF/templates/scaffolding/<template path> in its tree: normally the output of
processResources, filtered to them. That is where the resolver finds them beside the
application's controllers, however the build put them there - from
src/main/templates, from the resources, or from a task that feeds them.
The classpath the pages are compiled against: normally compileGroovyPages'. A page
names the type of its model, so a plugin's controller has its pages expanded only where the
domain class it scaffolds is on it. Left empty, no plugin's domain class is checked.
The encoding the pages are written in, which must be the one they are compiled with, so that
a page reads back as it was expanded. Normally compileGroovyPages' encoding.
The application's runtime classpath. The templates and the plugins' controllers are read from it, as the running application reads them, and the pages are expanded on it, by the scaffolding library and the Groovy the application runs with.
The application's own templates, as trees rooted at the template directory: normally
src/main/templates/scaffolding. A template's path within its tree is its path as the
resolver asks for it, so admin/show.gsp is the show template of the
admin namespace.