Browse: Home / Projects / CFGroovy 1

CFGroovy 1

CFGroovy 1 has been EOLed (April 5, 2010)

As of today (2010/04/05) CFGroovy 1 is abandonware.  This was the intent from the beginning: once CFML engines support Hibernate natively, CFGroovy's Hibernate integration is redundant.  If you are looking for Groovy (or any other JSR-223 language) integration with your CFML applications, CFGroovy 2 is the proper choice.  Not only is it enormously more streamlined and performant, it provides a number of additional features that CFGroovy 1 does not (and could not).

If you are currently using CFGroovy 1, please do not assume that it will simply vanish.  I still use it personally, and we use it where I work for our entire service layer.  But no new development will happen, and the recommended course of action for CFGroovy 1 applications is to upgrade to CF9 (or Railo when it's ORM bits are released) and use the native ORM support.  It comes with far fewer caveats than CFGroovy 1 has, and CFGroovy 2 can still be used to support all your existing Groovy scriptlets (including within persistent CFCs).

CF Groovy is a way to leverage the Groovy language from CFML. In the most basic case, it provides a way to use scriptlets in your CFML code. Scriptlets are written in Groovy, but since Groovy is almost a superset of Java, you may treat them as Java scriplets instead in nearly all cases. Scriplets are embedded within <g:script> tags (imported with CFIMPORT). Scriptlets have direct access to most of the CF data structures you would expect:

  • request – the CF request scope (not the HttpServletRequest)
  • cgi – the CF CGI scope
  • params – the combination of the CF form and url scopes (i.e. the request parameters), with form taking precedence.  The 'attributes' label is still available, but it has been deprecated and will be removed in a future release.
  • variables – the CF variables scope from the context the scriptlet is defined (unless overridden with the 'variables' attribute to <g:script>)
  • pageContext – the result of calling getPageContext(), from which you can get the HttpServletRequest among other things
  • session – the CF session scope, if it's available
  • application – the CF application scope, if it's available
  • server – the CF server scope

By default, scriptlets can access any class on the JVM classpath. For more advanced usage, you can leverage the classloading capabilities of CF Groovy classloading via the <g:setPath> tag. It allows you to add additional directories to search for Groovy classes, so you can write classes in Groovy and leverage them through scriptlets. Those classes are dynamically reloaded just like your scriptlets, so no need to recompile or restart your container all the time like with Java classes.

As well as the core Groovy engine, Hibernate can be enabled via a bundled plugin.  This allows you to use Hibernate to persist Groovy classes.  It operates on CF DSNs, just like you'd expect, and if you use JPA/Hibernate annotations, you don't need a single line of XML.  Check out the demo apps for more details.

Subversion houses both the engine source, and the demo app source (which includes the engine) that shows a little bit of how the engine can be used. In order to run either, you must install the JAR file (groovy-all-X.Y.Z.jar) from the engine directory into your CF classpath (i.e. /WEB-INF/lib). The demo app is available online at http://www.barneyb.com/cfgroovy/, though you'll want the demo source to follow along with what's happening.

For details about Groovy itself, check out groovy.codehaus.org.