Grails 1.0英文操作手册：敏捷Web应用开发指南

需积分: 10 28 浏览量更新于2024-07-26 收藏 990KB PDF 举报

《Grails 1.0英文操作手册》是一份详尽的开发文档，由Graeme Rocher、Peter Ledbrook和Marc Palmer共同编写，版本为1.0.4。这份手册旨在提供一个快速且工业级的Web应用开发平台，强调了敏捷开发方法和基于约定优于配置的设计理念。以下是该手册的一些核心知识点： 1. **Introduction**（引言）： - Grails 1.0为开发者提供了一个高效工具，简化了企业级Web应用的开发过程。它结合了Groovy语言的强大功能和Spring框架的成熟特性。 2. **Getting Started**（入门指南）： - 学习者可以下载并安装Grails 1.0，文档指导如何创建新项目，包括一个简单的“Hello World”示例，帮助读者熟悉基本的开发流程。 - 通过IDE集成，如Eclipse或IntelliJ IDEA，用户可以更方便地进行开发和调试。 3. **Conventions over Configuration**（约定优于配置）： - Grails采用一种设计原则，即尽可能地自动化配置过程，减少繁琐的手动设置，让开发者专注于业务逻辑而非底层细节。 4. **Running and Testing an Application**（运行与测试应用）： - 介绍如何启动应用，并提供测试应用的方法，确保代码质量和性能。 5. **Deployment**（部署）： - 文档详细解释了如何将Grails应用部署到支持的Java EE容器中，如Tomcat或JBoss。 6. **Supported JavaEE Containers**（支持的Java EE容器）： - Grails 1.0兼容多种Java EE容器，允许开发者根据需求选择最合适的部署环境。 7. **Creating Artefacts**（创建 artefacts）： - 这部分介绍了如何构建和管理项目的各种组件，如控制器、视图、模型等。 8. **Generating an Application**（自动生成应用）： - Grails提供了生成器工具，用于快速创建常见的业务逻辑模板，节省编码时间。 9. **Configuration**（配置）： - 对基本配置选项进行了详细介绍，包括内置选项和日志设置。此外，还涉及环境管理（如开发、测试、生产环境）和数据源设置，以及自动数据库迁移功能。 10. **Externalized Configuration**（外部化配置）： - 用户可以选择将配置信息存储在外部文件中，提高维护性和可扩展性。《Grails 1.0英文操作手册》为开发者提供了丰富的指南，覆盖从基础安装到高级配置的所有阶段，是Grails初学者和经验丰富的开发者不可或缺的学习资料。通过理解和遵循手册中的原则和步骤，用户能够迅速掌握这个强大的动态Web应用框架，实现高效的开发和部署。

3.3.2 JNDI DataSources

Since many Java EE containers typically supply DataSource instances via the Java Naming and Directory Interface (JNDI).

Sometimes you are required to look-up a DataSource via JNDI.

Grails supports the definition of JNDI data sources as follows:

dataSource {

jndiName = "java:comp/env/myDataSource"

}

The format on the JNDI name may vary from container to container, but the way you define the DataSource remains the

same.

3.3.3 Automatic Database Migration

The dbCreate property of the DataSource definition is important as it dictates what Grails should do at runtime with

regards to automatically generating the database tables from GORM classes. The options are:

◦ create-drop - Drop and re-create the database when Grails is run

◦ create - Create the database if it doesn't exist, but don't modify it if it does. Deletes existing data.

◦ update - Create the database if it doesn't exist, and modify it if it does exist

Both create-drop and create will destroy all existing data hence use with caution!

In development mode dbCreate is by default set to "create-drop":

dataSource {

dbCreate = "create-drop" // one of 'create', 'create-drop','update'

}

What this does is automatically drop and re-create the database tables on each restart of the application. Obviously this may

not be what you want in production.

Although Grails does not currently support Rails-style Migrations out of the box, there are currently

two plug-ins that provide similar capabilities to Grails: The LiquiBase plug-in and the DbMigrate plug-

in both of which are available via the grails list-plugins command

3.4 Externalized Configuration

The default configuration file Config.groovy in grails-app/conf is fine in the majority of cases, but there may be

circumstances where you want to maintain the configuration in a file outside the main application structure. For example if

you are deploying to a WAR some administrators prefer the configuration of the application to be externalized to avoid having

to re-package the WAR due to a change of configuration.

In order to support deployment scenarios such as these the configuration can be externalized. To do so you need to point

Grails at the locations of the configuration files Grails should be using by adding a grails.config.locations setting in

Config.groovy:

grails.config.locations = [ "classpath:${appName}-config.properties",

"classpath:${appName}-config.groovy",

"file:${userHome}/.grails/${appName}-config.properties",

"file:${userHome}/.grails/${appName}-config.groovy"]

In the above example we're loading configuration files (both Java properties files and ConfigSlurper configurations) from

different places on the classpath and files located in USER_HOME.

The Grails Framework - Reference-Documentation 1.0.4

Will create a script called scripts/CompileSources.groovy. A Gant script itself is similar to a regular Groovy script

except that it supports the concept of "targets" and dependencies between them:

target(default:"The default target is the one that gets executed by Grails") {

depends(clean, compile)

}

target(clean:"Clean out things") {

Ant.delete(dir:"output")

}

target(compile:"Compile some sources") {

Ant.mkdir(dir:"mkdir")

Ant.javac(srcdir:"src/java", destdir:"output")

}

As demonstrated in the script above, there is an implicit Ant variable that allows access to the Apache Ant API.

You can also "depend" on other targets using the depends method demonstrated in the default target above.

4.2 Re-using Grails scripts

Grails ships with a lot of command line functionality out of the box which is useful to re-use (See the command line reference

in the reference guide for info on all the commands). Some of the most useful are the compile, package and bootstrap

scripts.

The bootstrap script for example allows you to bootstrap a Spring ApplicationContext instance to get access to the data

source and so on:

Ant.property(environment:"env")

grailsHome = Ant.antProject.properties."env.GRAILS_HOME"

includeTargets << new File ( "${grailsHome}/scripts/Bootstrap.groovy" )

target ('default': "Load the Grails interactive shell") {

depends( configureProxy, packageApp, classpath, loadApp, configureApp )

Connection c

try {

// do something with connection

c = appCtx.getBean('dataSource').getConnection()

}

finally {

c?.close()

}

4.3 Hooking into Events

Grails provides the ability to hook into scripting events. These are events triggered during execution of Grails target and

plugin scripts.

The mechanism is deliberately simple and loosely specified. The list of possible events is not fixed in any way, so it is possible

to hook into events triggered by plugin scripts, for which there is no equivalent event in the core target scripts.

Defining event handlers

Event handlers are defined in scripts called Events.groovy. Grails searches for these scripts in the following locations:

◦ USER_HOME/.grails/scripts - user-specific event handlers

◦ PROJECT_HOME/scripts - applicaton-specific event handlers

◦ PROJECT_HOME/plugins/*/scripts - plugin-specific event handlers

Whenever an event is fired, all the registered handlers for that event are executed. Note that the registration of handlers is

performed automatically by Grails, so you just need to declare them in the relevant Events.groovy file.

4. The Command Line

Event handlers are blocks defined in Events.groovy, with a name beginning with "event". The following example can be

put in your /scripts directory to demonstrate the feature:

eventCreatedArtefact = { type, name ->

println "Created $type $name"

}

eventStatusUpdate = { msg ->

println msg

}

eventStatusFinal = { msg ->

println msg

}

You can see here the three handlers eventCreatedArtefact, eventStatusUpdate, eventStatusFinal. Grails

provides some standard events, which are documented in the command line reference guide. For example the compile

command fires the following events:

◦ CompileStart - Called when compilation starts, passing the kind of compile - source or tests

◦ CompileEnd - Called when compilation is finished, passing the kind of compile - source or tests

Triggering events

To trigger an event simply include the Init.groovy script and call the event() closure:

Ant.property(environment:"env")

grailsHome = Ant.antProject.properties."env.GRAILS_HOME"

includeTargets << new File ( "${grailsHome}/scripts/Init.groovy" )

event("StatusFinal", ["Super duper plugin action complete!"])

Common Events

Below is a table of some of the common events that can be leveraged:

Event Parameters Description

StatusUpdate message Passed a string indicating current script status/progress

StatusError message Passed a string indicating an error message from the current script

StatusFinal message

Passed a string indicating the final script status message, i.e. when completing

a target, even if the target does not exit the scripting environment

CreatedArtefact artefactType,artefactName Called when a create-xxxx script has completed and created an artefact

CreatedFile fileName

Called whenever a project source filed is created, not including files constantly

managed by Grails

Exiting returnCode Called when the scripting environment is about to exit cleanly

PluginInstalled pluginName Called after a plugin has been installed

CompileStart kind Called when compilation starts, passing the kind of compile - source or tests

CompileEnd kind

Called when compilation is finished, passing the kind of compile - source or

tests

DocStart kind

Called when documentation generation is about to start - javadoc or

groovydoc

DocEnd kind Called when documentation generation has ended - javadoc or groovydoc

SetClasspath rootLoader

Called during classpath initialization so plugins can augment the classpath with

rootLoader.addURL(...). Note that this augments the classpath after event

scripts are loaded so you cannot use this to load a class that your event script

needs to import, although you can do this if you load the class by name.

The Grails Framework - Reference-Documentation 1.0.4

剩余152页未读，继续阅读

jonccy

粉丝: 0
资源: 4

Grails 1.0英文操作手册：敏捷Web应用开发指南

Grails1.0_final_doc_and_API

Grails超全操作手册（中文版）

grails-docs-1.0

grails-docs-1.0-RC1.pdf

grails-用户手册

Grails 中文参考手册

grails中文参考手册

grails中文使用手册

Grails1.3.7参考手册

Grails中文参考手册

最新资源