Grails: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(27 intermediate revisions by the same user not shown) | |||
Line 7: | Line 7: | ||
* Grails use currently as of 0.5.0 a custom build of a Spring-modules snapshot. You must thus use the .jar provided in Grails distribution. | * Grails use currently as of 0.5.0 a custom build of a Spring-modules snapshot. You must thus use the .jar provided in Grails distribution. | ||
* Grails use version 2.1 of commons-lang. | * Grails use version 2.1 of commons-lang (in Portage). | ||
* Grails use Sitemesh 2.3 | |||
* Grails use Quartz 1.6.0 | |||
* Grails use ehcache 1.2.4 (in Portage). | |||
* Grails use dom4j 1.6.1 (in Portage). | |||
* Grails use cglib 2.1.3 (in Portage). | |||
* Grails use commons-beanutils 1.7 (in Portage) '''with the additional Bean Collections API''' (currently not built in Portage!!!). | |||
* Grails use Hibernate 3.2 (not in Portage). Version 3.1 is NOT good enough. In addition, using the vanilla Hibernate jar as per upstream caused strange errors, better to use the one packaged with Grails for now. This may be due to differences between 3.2 and 3.2.4. | |||
* Grails use the JSTL (specification 1.1). In Portage, the Jakarta implementation is available. | |||
* Grails 0.5.0 uses Prototype version 1.5.0-rc0. Update Prototype to version 1.5.1. | |||
== Deployment and build system == | == Deployment and build system == | ||
Line 17: | Line 35: | ||
* Note that when running the embedded Jetty server (or when running any Grails script for that matter), the additional JAR dependencies are loaded in the classpath. | * Note that when running the embedded Jetty server (or when running any Grails script for that matter), the additional JAR dependencies are loaded in the classpath. | ||
== | * It seems that all the jar dependencies must be present in common/lib. Tomcat has problems when some are in shared/lib. | ||
* By default you cannot deploy into a servlet container using the "development" environment. The views would not be copied into the resulting WAR. In addition, even if you correct the Gant script to copy the views, when using the development envrionment, internally Grails does not work the same way. So deploying using development environment is currently NOT possible. | |||
== The web-app directory == | |||
Part of this directory is recreated by the Grails build script, there seem to be such files that are needed there: | |||
* WEB-INF/web.template.xml | |||
* WEB-INF/applicationContext.xml | |||
* WEB-INF/sitemesh.xml | |||
* WEB-INF/tld directory (Tag Library Definitions) [Not sure if they are really needed] | |||
Without these files the web application won't start or will behave strangely !! | |||
In addition, the css, js, and images folders there are not populated by the default build scripts. They are only copied when running the create-app script. | |||
== Data Sources == | |||
* Creating a new data source file in grails-app/conf is not enough. Remember you must change the name of the class inside this file too ! | |||
== Grails and Ajax == | |||
* If you use a remote link in Prototype, be sure to write the params attribute with quotes: | |||
params="'parent=${subcat.name}'" | |||
If you forget the single quotes nothing will work. | |||
== Scaffolding == | |||
* Be careful when using dynamic scaffolding. Apparently scaffolding does not support auto-reloading very well. Overriding scaffolded actions while the embedded server is running is risky. | |||
* It is better to use static scaffolding for any serious work. | |||
== Views == | |||
* GSP tags can also be used as function calls. | |||
== HTTP Methods == | |||
* By default scaffolded actions like update only accept an HTTP POST method. I don't know if it is possible to redirect using a POST method. | |||
== Documentation == | |||
* | * Apart from books (The Definitive Guide to Grails and Groovy in Action are two excellent books for learning Grails and Groovy), most of the Grails documentation is hosted on the Grails site wiki. This documentation is good but far from complete, as code evolves faster than the wiki. | ||
* | * An excellent source is the API documentation (Javadoc). Note that strangely, some classes are not present in the documentation provided with the official Grails package (for example the grails.util package). |
Latest revision as of 13:00, 24 August 2008
Grails is a next-generation web development framework powered by Groovy and Java technologies.
Dependencies
- Grails use the embeddable Groovy jar. You will run into problems if you use the standalone Groovy jar.
- Grails use currently as of 0.5.0 a custom build of a Spring-modules snapshot. You must thus use the .jar provided in Grails distribution.
- Grails use version 2.1 of commons-lang (in Portage).
- Grails use Sitemesh 2.3
- Grails use Quartz 1.6.0
- Grails use ehcache 1.2.4 (in Portage).
- Grails use dom4j 1.6.1 (in Portage).
- Grails use cglib 2.1.3 (in Portage).
- Grails use commons-beanutils 1.7 (in Portage) with the additional Bean Collections API (currently not built in Portage!!!).
- Grails use Hibernate 3.2 (not in Portage). Version 3.1 is NOT good enough. In addition, using the vanilla Hibernate jar as per upstream caused strange errors, better to use the one packaged with Grails for now. This may be due to differences between 3.2 and 3.2.4.
- Grails use the JSTL (specification 1.1). In Portage, the Jakarta implementation is available.
- Grails 0.5.0 uses Prototype version 1.5.0-rc0. Update Prototype to version 1.5.1.
Deployment and build system
- Under the hood, Grails uses Gant as its build system. Gant is based on Ant but allows you to write build files with Groovy code: you are no longer restrained to XML programming!
- If you write your own Gant scripts (in $PROJECT_HOME/scripts), you can apparently completely customize the build process.
- Note that when running the embedded Jetty server (or when running any Grails script for that matter), the additional JAR dependencies are loaded in the classpath.
- It seems that all the jar dependencies must be present in common/lib. Tomcat has problems when some are in shared/lib.
- By default you cannot deploy into a servlet container using the "development" environment. The views would not be copied into the resulting WAR. In addition, even if you correct the Gant script to copy the views, when using the development envrionment, internally Grails does not work the same way. So deploying using development environment is currently NOT possible.
The web-app directory
Part of this directory is recreated by the Grails build script, there seem to be such files that are needed there:
- WEB-INF/web.template.xml
- WEB-INF/applicationContext.xml
- WEB-INF/sitemesh.xml
- WEB-INF/tld directory (Tag Library Definitions) [Not sure if they are really needed]
Without these files the web application won't start or will behave strangely !!
In addition, the css, js, and images folders there are not populated by the default build scripts. They are only copied when running the create-app script.
Data Sources
- Creating a new data source file in grails-app/conf is not enough. Remember you must change the name of the class inside this file too !
Grails and Ajax
- If you use a remote link in Prototype, be sure to write the params attribute with quotes:
params="'parent=${subcat.name}'"
If you forget the single quotes nothing will work.
Scaffolding
- Be careful when using dynamic scaffolding. Apparently scaffolding does not support auto-reloading very well. Overriding scaffolded actions while the embedded server is running is risky.
- It is better to use static scaffolding for any serious work.
Views
- GSP tags can also be used as function calls.
HTTP Methods
- By default scaffolded actions like update only accept an HTTP POST method. I don't know if it is possible to redirect using a POST method.
Documentation
- Apart from books (The Definitive Guide to Grails and Groovy in Action are two excellent books for learning Grails and Groovy), most of the Grails documentation is hosted on the Grails site wiki. This documentation is good but far from complete, as code evolves faster than the wiki.
- An excellent source is the API documentation (Javadoc). Note that strangely, some classes are not present in the documentation provided with the official Grails package (for example the grails.util package).