Zobacz komendę create-script.
create-script quick ref...
create-script User Guide
który pozwoli Ci stworzyć własny skrypt do generowania kodu zrobić, ale nie wierzę, że pozwala uzyskać dostęp do właściwości domeny Gorm w Grails 3. (1) . Właściwie opublikowałem to pytanie tutaj: How can I access GORM object properties in a GroovyScriptCommand?
Najpierw uruchomiłem polecenie install-templates, a następnie polecenie create-script, nie wiem, czy było to potrzebne, ale dało mi to kilka przykładowych szablonów do obejrzenia.
Oto przykład tego, który stworzyłem. Umieściłem instrukcje println w taki sposób, że mogłem zobaczyć, z jakimi różnymi właściwościami modelu muszę pracować. Czują się trochę ograniczeni, ponieważ wszystkie opierają się na argumentach wiersza poleceń, które wprowadzasz, a nie instancji faktycznego artefaktu Grails.
src/main/scripts/Geta-create-screen-Groovy:
import grails.build.logging.ConsoleLogger
description("Creates a GETA scaffolded controller, views, and integration test artifacts") {
usage 'geta-create-screen [domain name]'
completer org.grails.cli.interactive.completers.DomainClassCompleter
argument name:'Controller Name', description:"The name of controller", required:true
flag name:'force', description:"Whether to overwrite existing files"
}
def model = model(args[0])
def overwrite = flag('force') ? true : false
println "DAC: model.className:..... ${model.className}"
println "DAC: model.fullName:...... ${model.fullName}"
println "DAC: model.propertyName:.. ${model.propertyName}"
println "DAC: model.packageName:... ${model.packageName}"
println "DAC: model.simpleName:.... ${model.simpleName}"
println "DAC: model.lowerCaseName:. ${model.lowerCaseName}"
println "DAC: model.packagePath:... ${model.packagePath}"
render template: template('scaffolding/EtaController.groovy'),
destination: file("grails-app/controllers/${model.packagePath}/${model.convention("Controller")}.groovy"),
model: model,
overwrite: overwrite
render template: template('scaffolding/EtaDomainObject.groovy'),
destination: file("grails-app/domain/${model.packagePath}/${model.convention("Domain")}.groovy"),
model: model,
overwrite: overwrite
render template: template('scaffolding/EtaService.groovy'),
destination: file("grails-app/services/${model.packagePath}/${model.convention("Service")}.groovy"),
model: model,
overwrite: overwrite
render template: template('scaffolding/EtaGsp.gsp'),
destination: file("grails-app/views/${model.packagePath}/${model.propertyName}/${model.propertyName}.gsp"),
model: model,
overwrite: overwrite
render template: template('scaffolding/EtaGspTabHeader.gsp'),
destination: file("grails-app/views/${model.packagePath}/${model.propertyName}/_tabHeader.gsp"),
model: model,
overwrite: overwrite
return true
Szablon: src/main/szablony/rusztowanie/EtaController.groovy
<%=packageName ? "package ${packageName}" : ''%>
class ${className}Controller {
static scaffold = ${className}
def index(){
render view: "${packageName.replaceAll('\\\\', '/')}/${propertyName}/${propertyName}.gsp"
}
}
aby wykonać command: grails geta-create-screen my.package.MyClass --force --stacktrace --verbose
Nie. "generator-kontroler" tworzy rzeczywisty plik/klasę dla rusztowania kontrolera g określonej klasy domeny. Spójrz na sytuację, w której masz dziesiątki takich plików i chciałbyś zmienić zachowanie dla całej aplikacji, na przykład "każda akcja zapisu powinna przekierować z powrotem do poprzedniego kontrolera wywołującego akcję edycji" - dziesiątki plików do zmiany. I 'templates/Controller.groovy' był plikiem, który szablonował każde dynamiczne rusztowanie utworzone w locie przez' static scaffold = domain.class' wewnątrz kontrolera. – mkr