Last night at dinner I was talking with Mark Mandel and Luis Majano and realized I'd completely misunderstood the way JavaLoader worked based on my initial look see. So for the price of 21 additional lines (nine of which are purely for misbehaving CFML runtimes), CFGroovy will transparently load an internal copy of Groovy if it can't find one on the classpath.
I've created a branch in Subversion to house the new version at https://ssl.barneyb.com/svn/barneyb/cfgroovy/branches/cfgroovy2/engine/. It's organized the same way as the trunk, so there is a ../demo/ directory that contains a trivial demo application. Here's the demo template, so you can get a feel for how easy CFGroovy is to use:
<cfimport prefix="g" taglib="engine" />
<cfset variables.myArray = listToArray("barney is tall,CFML is taggy,Groovy is AWESOME!") />
<cfoutput>
<h1>Inline Groovy</h1>
<p>This demo creates an array of strings, CFDUMPs it, uses some inline
Groovy (via <code><g:script></code>) to add a few more, and
then CFDUMPs it again.
</p>
<h1>Only Three</h1>
<cfdump var="#variables.myArray#" />
<g:script>
// better add emery
variables.myArray.add("emery")
// and some other stuff, using some other syntaxes
variables.myArray += "CF Runtime: " + server.coldfusion.productname + " " + server.coldfusion.productversion
variables.myArray << "User Agent: " + cgi.http_user_agent
</g:script>
<h1>There we go!</h1>
<cfdump var="#variables.myArray#" />
</cfoutput>
Does 'access="private"' mean anything in script.cfm?
I thought access attribute only means something when the cffunction is defined inside cfcomponent?
Henry,
No, it's ignored by the CFML runtime except in a CFC context. I usually put it in to indicate that it's an internal implementation detail versus something deemed to have a stable API. In this case, you can't call the functions without modifying script.cfm itself, but outside a custom tag context, that's not always the case.