The JRE provides TimerTask, but it's a huge pain in the ass to use with CFML because the Java-to-CFML bridges are laughably weak. OpenSymphony has Quartz (which is awesome), but being Java, it suffers the same problem. Yes, even with the bennies CFGroovy offers in the Java space.

CFSCHEDULE is lame, especially on ColdFusion with it's 61 second frequency limit. Even with an optimal implementation the entire mechanism is flawed because it's a) stuck with equal iteration periods, and b) can only invoke URLs. Every distinct task requires punching a hole in your URL security, making a UI-layer facade for the task, etc.

The Java mechinisms are much better because they stay in-JVM (i.e., don't go through HTTP), but the statelessness of CFCProxy is a huge burden. You can't access already-instantiated CFCs, which means you end up writing a massive pile of custom facade/proxy code to interface with your already-running business model.

The natural solution, of course, is implementing cron in CFML. It allows you to pay either the HTTP or CFCProxy cost exactly once, as well as have cron's incredibly flexible scheduling format. This fact, in it's various manifestations, drives me to drink rather ridiculous amounts.

The flip side, of course, is the dynamic reloading nature that CFML servers offer. I simply cannot understand why other JVM frameworks have not copied this feature. The complete avoidance of all the JVM restarts and classloading hell is a benefit worth enormous sacrifice. Which, I suppose, is why I write CFML both for my salary and for personal projects.

Am I the only one who thinks this is a problem? With both CFML and other JVM frameworks.

The basic idea is that your HTML includes a reference to "agg_standard.js", which is an alias for whatever JS files you need for your standard user (as opposed to a mobile user, for example).  That request comes to your server and if the file exists, gets served back like any other JS file.  If it doesn't exist, however, mod_rewrite will forward it to a CFM page to generate it:

RewriteCond     %{REQUEST_FILENAME}     !-s
RewriteRule     (/my_app)/static/(agg_.*)\.js$ $1/aggregator.cfm?name=$2.js

In our example, the request passed to aggregator.cfm would have "agg_standard.js" as the 'name' attribute, which is how we'll figure out what we need to aggregate together:

switch (url.name) {
case "agg_standard.js":
  files = [
    "jquery/jquery" & (request.isProduction ? ".min" : ""),
    "jquery/jquery.ui" & (request.isProduction ? ".min" : ""),
    "yui/yahoo-min",
    "yui/event-min",
    "yui/history-min",
    "util",
    "jscalendar/calendar",
    "jscalendar/lang/calendar-en",
    "jscalendar/calendar-setup",
    "dracula/raphael-min",
    "dracula/graffle",
    "dracula/graph"
  ];
  break;
case "agg_iphone.js":
  files = [
    "jquery/jquery" & (request.isProduction ? ".min" : ""),
    "yui/yahoo-min",
    "yui/event-min",
    "yui/history-min",
    "util"
  ];
  break;
}

The important bits, of course, is the Groovy script that actually does the aggregation and compression.  It uses YUI Compressor, so you'll need to have the yiucompressor-x.y.z.jar file on your classpath (probably in /WEB-INF/lib).  Here it is:

import com.yahoo.platform.yui.compressor.*

sw = new StringWriter()
variables.files.each {
  def f = new File(variables.STATIC_DIR + it + '.js')
  sw.append('/* ').append(f.name).append(' */\n')
  if (! it.endsWith(".min") && ! it.endsWith("-min")) {
    def compressor = new JavaScriptCompressor(f.newReader(), null)
    compressor.compress(sw, -1, false, false, false, false)
  } else {
    sw.append(f.text.trim())
  }
  sw.append('\n')
}
variables.buffer = sw.toString()

Pretty straightforward: it just loops over the files, using a StringWriter to build up the aggregated buffer.  Each file is either compressed into the Writer or simply appended based on whether the file has already been minified (based on ".min" or "-min" in the filename).  Each file also gets a comment label in the Writer above it's contents so that the aggregated file is a little easier to parse (at the expense of a few extra bytes).  Once done, the Writer's contents are stored in the 'buffer' variable caching on the filesystem:

<cfset fileWrite(STATIC_DIR & url.name, buffer) />
<cflocation url="#url.name#" addtoken="false" />

You'll notice that I'm not streaming the buffer back out to the user, but instead 302-ing back to the same URL.  This is important.  The reason is that Apache does a whole bunch of stuff to optimize static assets, and if I serve the content back with CFCONTENT, I'll miss out on all of that.  Yes, the 302 has a little bit of overhead on the initial page load, but it reduces the total transfer size by several hundred KB (because of the GZIPping), and avoids a rerequest on the next page load (because of the cache headers).  So it's completely worth it, the moreso because this is an application likely to generate extended usage rather than a content-centric site that is likely to see single-page "bounce" visits from search engines.

The last piece of the puzzle is handling versioning of your assets.  When you change your JS file, you necessarily have to invalidate your cache (by deleting the files) so the aggregated version can be rebuilt with the new JS.  The easiest way to do that is to use psuedo-versioning of your assets.  You'll see a lot of sites will add a timestamp or a version number to their files (e.g., "arc/yui/reset_2.6.5.css" from Yahoo.com) so that when the update the file it gets a new filename, and is therefore redownloaded by everyone (because it doesn't exist in their cache).  That's great, but it means you have to rename your files all the time which is kind of a pain.  But you can fake it:

<cfset STATIC_ASSET_VERSION = 15 />
<script type="text/javascript" src="static/agg_standard_#STATIC_ASSET_VERSION#.js"></script>

That'll generate a request to "agg_standard_15.js", as you might imagine, which isn't going to work so well.  But we can just change the 'switch' line from the first snippet to this:

switch (REReplace(url.name, "^(agg_.*?)(_[0-9]+)?\.js$", "\1.js")) {

Now it'll strip out that "fake" number string and switch on just "agg_standard.js", which is what we want.  But that 'fileWrite' call later will still use the full filename (with the number embedded).  That way subsequents will get the filesystem cacheing, the headers and GZIPping from Apache, and all the other love.  And when you rev your files, you need only increment the STATIC_ASSET_VERSION variable and you'll have a brand new set of virtual URLs for all your assets, no fuss, no muss.

Oh, and just in case you're wondering, the aggregation and compression is fast.  If you've ever used the command line or Ant task, you might fear that it's slow, but most of the time you see there is from the JVM spinning up, not the actual compression.  Since this is all in-JVM, you don't pay any of that cost.  It's certainly not fast enough to have it run in production on every request (hence the file caching), but it's totally reasonable to do on your production box as part of deploying a new version of the app.  It's also probably fast enough to have running every request on your internal test/staging boxes, though that'll depend on how much you're aggregating/compressing among other things.

The benefit of using the flash scope for doing this is that it only lasts one request, so if the user refreshes the listing page, they won't see the success message again (nor should they, since a user wasn't updated on the refresh).  It also keeps your URLs clean (because you don't have to pass stuff along on the query string), and lets you pass complex data (since there is no serialization).

I'm sure a lot of people have faked this functionality in some sort of use-specific way, and I know I'm guilty.  However, after preparing to do it yet again, I thought I'd build a more generic mechanism that I could reuse.  Before I give you the actual code, here's how you might use it:

<cfcase value="onRequestStart">
  <cfset flashScope = createObject("component", "FlashScope") />
</cfcase>

<cfcase value="updateGoal">
  <cfset xfa.success = "goalList" />
  <cfset goalService = request.beanFactory.getBean("goalService") />
  <cfset goalService.updateGoal(
    session.user.getId(),
    attributes.id,
    attributes.name,
    attributes.definition
  ) />
  <cfset flashScope.put("message", "Goal Updated Successfully!") />
  <cfset location("#self##xfa.success#") />
</cfcase>

<cfcase value="goalList">
  <cfset goalService = request.beanFactory.getBean("goalService") />
  <cfset goalList = goalService.getGoals(session.user.getId()) />
  <cfif flashScope.has("message")>
    <cfset statusMessage = flashScope.get("message") />
  </cfif>
  <cfset include("dsp_goallist", "bodyContent") />
  <cfset do("lay_auto") />
</cfcase>

As you can see, we're instantiating the flash scope at the start of every request.  Then in 'updateGoal', the 'message' key is set into the flash scope.  Finally in 'goalList', if there's a 'message' in the flash scope, it is set into a local variable (to be emitted within dsp_goallist.cfm).  Pretty straightforward.  The actual mechanism is a pair of structures: one in the request scope for incoming variables and one in the session scope for outgoing variables.  The FlashScope CFC is nothing more than a facade to those two structures.  This implies that you must have the session scope available to your application, of course.

I haven't created a full-on project for this but it garners sufficient interest and development activity, I'll certainly do that.  In the meantime you can view/download the CFC (or if you're using Subversion, svn:externals it into your project).

In the interest of full disclosure, I want to call out two shortcomings in the implementation, both of which are intentional (to minimize complexity):

1. There is no respect paid to dealing with concurrent requests.  They'll happily intermix their variables in the flash scope, potentially causing errors and/or bizarre behaviour.
2. The scope isn't really tied to the 'next' request, it's tied to the 'next request that reads the flash scope'.  This can yield behaviour if your app assumes that the flash scope will be consumed, but it isn't for whatever reason.

Both of these would require some sort of nonce on every request, which adds a whole layer of complexity and necessitates passing some sort of request parameter on the URL or whatever.  That's a) a mess, b) complicated, and c) application-specific.  As such, I've opted to intentionally not handle those cases since they're edge cases and I'd rather keep things simple.  That and I have this inexplicable obsession with 80-100 line, single-file microframeworks (see FB3lite, CFGroovy, TransactionAdvice, etc.).  :)

It's "Barney still wants CFML closures" time!  Yay!

Today's impetus is Edmund, Sean Corfield's event driven programming framework.  In order to register event listeners, you have to a CFC instance with a specific method to be invoked on it, and which accepts an Edmund Event as it's sole argument.  Which means you have to have these silly little CFCs hanging about that simply get the event and then hand it off to the appropriate business components to actually do stuff.  Yes, I understand that's a very OO way to do it: lots of little, purpose-specific types passing messages between them.  But it's a bitch with CFML because every type has to be it's own file and you don't get context inheritance.

In Java most of the time your event listeners are anonymous inner classes – instances of classes that are defined inline.  That mechanism gets a lot of grief, and while I agree that it's a little more verbose than necessary in simple cases, it's a lot better than the crap that static typing and/or checked exceptions foists on you, and having a full class definition can be useful as things get more complex.

Groovy smoothes that a little by allowing you to define Closures and use them instead.  Under the hood, it's just converting them to your standard Java anonymous inner classes, but the syntax is rather nicer.  If you know Ruby, think lambdas.

This is what I'd do in Java:

edmund.register("eventCreated", new GenericHandler() {
  public handleEvent(Event e) {
    beanFactory.getBean("eventservice").postprocessEvent(e.value("eventId"));
  }
});

or in Groovy:

edmund.register("eventCreated", {
  beanFactory.getBean("eventservice").postprocessEvent(e.value('eventId'))
})

But in CFML, I need to create a separate type (in a separate file):

<cfcomponent>

  <cffunction name="init">
    <cfargument name="beanFactory" />
    <cfset variables.beanFactory = arguments.beanFactory />
  </cffunction>

  <cffunction name="handleEvent">
    <cfargument name="e" />
    <cfset beanFactory.getBean("eventservice").postprocessEvent(e.value("eventId")) />
  </cffunction>

</cfcomponent>

And then register it like this:

<cfset edmund.register("eventCreated",
  createObject("component", "MyEventHandler").init(beanFactory)
) />

What a mess.  Not only do I have to create a separate file to have that one single line of code in it (line 10), but I also have to worry about passing context around (in this case, the beanFactory), because the CFC instance doesn't inherit the context it's instantiated in (as closures and anonymous inner types do).  And this is a ridiculously trivial example.  Here's what I'd like to see in CFML:

edmund.register("eventCreated", function(e) {
  beanFactory.getBean("eventservice").postprocessEvent(e.value("eventId"));
});

You can see that I'm following the ECMAScript-like nature of CFML expressions and stealing ECMAScript's function literal syntax (one of them, at least) to create an anonymous function.  In order for this to work, it'd have to be a closure (as ECMAScript functions are), not just a context-free function.  As an alternative (which is more complicated, but which has certain advantages in certain scenarios), would be to have a CFC literal (anonymous inner CFC) as well:

edmund.register("eventCreated", new component() {
  function handleEvent(e) {
    beanFactory.getBean("eventservice").postprocessEvent(e.value("eventId"));
  }
});

Personally, I'd much prefer the closure if I only got one, but both would be nice.  The semantics of anonymous inner types can be a little wonky, and the advantages over simple closures is small, but they can still be really useful.  Now that we have a CFSCRIPT-based way of defining components, the language at least has syntactic constructs to express anonymous types, so it's theoretically possible.

So since I can't do all this neat stuff, you might ask what I did do.  I used ColdSpring with a purpose-sepecific adapter I wrote, along with a custom extension to Edmund to allow registering listeners from ColdSpring.  So my Edmund config looks like this:

<bean id="edmund">
  <constructor-arg name="asyncByDefault"><value>false</value></constructor-arg>
  <property name="eventListeners">
    <map>
      <entry key="eventCreated">
        <bean class="edmund.framework.ColdSpringListener">
          <constructor-arg name="handler"><ref bean="eventservice" /></constructor-arg>
          <constructor-arg name="method"><value>postprocessEvent</value></constructor-arg>
        </bean>
     </entry>
  </property>
</bean>

The ColdSpringListener bean simply takes care of delegating the configured method to the supplied bean when it is triggered, passing along the event arguments along.  This obviously is still pretty verbose, but the per-listener overhead is four lines of XML (in an existing file), not a 13 line CFC (in a new file).  That counts as a win by me.  The way I extended Edmund allowed passing a single listener or an array of listeners.  The method I added is here:

<cffunction name="setEventListeners" returntype="any" access="public" output="false"
  hint="I register multiple new listeners at once.  I DO NOT REPLACE listeners,
    despite being a setter.  I should be named addMultipleEventListeners, but must
    be named setEventListeners so I can be used from ColdSpring.">
  <cfargument name="listeners" type="struct" required="true"
    hint="I am a struct with event names as keys and either a single listener or
      array of listeners as values.  Note that there is no way to specify the
      handler method or whether listeners are asynchronous." />
  <cfset var e = "" />
  <cfset var i = "" />
  <cfloop collection="#listeners#" item="e">
    <cfif NOT isArray(listeners[e])>
      <cfset i = listeners[e] />
      <cfset listeners[e] = arrayNew(1) />
      <cfset arrayAppend(listeners[e], i) />
    </cfif>
    <cfloop from="1" to="#arrayLen(listeners[e])#" index="i">
      <cfset register(e, listeners[e][i]) />
    </cfloop>
  </cfloop>
  <cfreturn this />
</cffunction>

So is this good stuff?  It's OK.  It's solid for a CFML solution.  But there is no question that it pales in comparison to the elegance with which you could solve the problem in other languages.  Java (same age as CFML) has this, Ruby (a little older than CFML) has this, Python (much older than CFML) has this, and don't even get me started on Lisp (more than double the age of CFML).  It's not a concept new to computer science.

Alright.  Rant over.  Until next time I seriously consider rebuild huge swaths of CFML in Groovy just for closures and start yelling again.

Most of the time, transactions are a bit of a bear because their use is orthagonal to your business tasks.  To put that another way, business operations flow vertically from UI to backend to UI, and the various operations in your app typically flow mostly in separate parallel channels.  Transactions go across your application's structure, needing to be uniformly applied to all those operations, but being independent of all of them.  The "right" term for this is a "cross-cutting concern."

Fortunately, there are a pile of people in this world who are way smarter than I, and they've come up with Aspect Oriented Programming as a way to deal with these cross-cutting concerns.  The typical example shown is with logging, but transaction management is rather more useful, I think, isn't any more complicated, and is also more specific to AOP (whereas logging could be done with event-driven programming as well).  I'm not going to go into AOP, but if you're not using it, you should spend the time to learn a bit about it.  Really.

So the idea is to leverage AOP to automatically wrap your business methods with transactions.  In the CFML world, that means ColdSpring and its AOP support (which is modelled after Java's Spring framework).  Unfortunately, that's the easy part.  Since CFML servers abstract away DB connections (behind DSNs), it's hard to get ahold of the proper context to do the transaction demarcation correctly from your application code.  Somehow you have to know what the engine is doing behind the scenes so you can start/stop transactions at the right places.

When I wrote transactionadvice.cfc many years ago, I used a psuedo-ThreadLocal for tracking transactional method depth.  That way it can apply transactions at the top level, but skip them lower (nested) levels.  It works, but it doesn't handle multithreaded requests (i.e., using CFTHREAD) correctly, so it's far from ideal.  Using a real ThreadLocal would be better, but it requires Java or Groovy, and that's a dependency I don't want to require.  But for the majority of cases, it works fine.

Today, however, I discovered that Railo has this method:

getPageContext().getDataSourceManager().isAutoCommit()

It will tell you whether you're currently in autocommit (non-transaction) mode.  With this direct check of the transactional status, all the issues simply vanish, and the advice can be whittled down to this:

<cfcomponent extends="coldspring.aop.MethodInterceptor">

  <cffunction name="invokeMethod" access="public" output="false" returntype="any">
    <cfargument name="methodInvocation" type="coldspring.aop.MethodInvocation" required="true" />
    <cfif getPageContext().getDataSourceManager().isAutoCommit()>
      <cftransaction>
        <cfreturn methodInvocation.proceed() />
      </cftransaction>
    <cfelse>
      <cfreturn methodInvocation.proceed() />
    </cfif>
  </cffunction>

</cfcomponent>

Copiously excellent, if you ask me.  About the only thing that would make it better is if CFML grew a isAutoCommit() or isInTransaction() method so you don't have to dig into the underlying Java bits in an engine-specific way.

Fortunately, Railo implements the 'location' function as a CFML template, so you can easily go change the default.  If you install the WAR version the template is here:

/WEB-INF/lib/railo-server/context/library/function/location.cfm

If you install the bundled version, the 'railo-server' directory will be outside the webroot, typically here (thanks Todd):

{installation-dir}/railo/railo-server/context/library/function/location.cfm

Changing this file requires restarting your Railo webapp as the files are loaded once on startup.  As you'll quickly notice, there are a bunch of functions and tags that are implemented this way, so you can easily modify any or all of them to customize your environment.  Just be careful when you upgrade your Railo, as your changes will be overwritten.

<cfparam name="url.path" default="" />

<cfset s3 = createObject("component", "amazons3").init(
  "YOUR_AWS_KEY",
  "YOUR_AWS_SECRET"
) />

<cfoutput>
<cfset bp = "" />
<h1>
<a href="?path=#bp#">ROOT</a>
<cfloop list="#url.path#" index="segment" delimiters="/">
  <cfset bp = listAppend(bp, segment, "/") />
  / <a href="?path=#bp#">#segment#</a>
</cfloop>
</h1>

<cfif url.path EQ "">
  <cfset b = s3.listBuckets() />
  <ul>
    <cfloop query="b">
      <li><a href="?path=/#name#">#name#/</a> #dateLastModified#</li>
    </cfloop>
  </ul>
<cfelse>
  <cfset q = s3.listObjects(listFirst(url.path, '/'), listRest(url.path, '/')) />
  <ul>
    <li><a href="?path=#reverse(listRest(reverse(url.path), '/'))#">..</a></li>
    <cfloop query="q">
      <li>
      <cfif type EQ "dir">
        <a href="?path=#listAppend(directory, name, '/')#">#name#/</a>
      <cfelse>
        <a href="#s3.s3Url(bucket, objectKey)#">#name#</a>
      </cfif>
      </li>
    </cfloop>
  </ul>
</cfif>
</cfoutput>

The default mode of operation assumes a delimiter of '/' (just like a filesystem).  If you want to do non-delimited operations (like generic prefix matching), you'll want to supply an empty delimiter, or you'll get weird results.  For example:

<cfset k_objects = s3.listObjects('my-bucket', 'k', '') />

If you omit the third parameter, the default 'k' will be used, and you'll get back objects within the 'k' psuedo-directory, rather than objects that begin with a 'k'.  This is the reverse of the default position of the raw S3 API, which assumes you want simple prefixing and makes you explicitly add the delimiter if you want psuedo-directory contents.

This dichotomy can also lead to weird results in the resulting recordset.  Every recordset comes with both 'bucket' and 'objectKey' columns that match the raw S3 nomenclature and 'directory' and 'name' columns that match the filesystem "view" of S3.  If you're doing raw prefixes you'll want to use bucket/objectKey (as the directory/name semantic doesn't work with prefixes).  If you're doing filesystem type stuff you'll probably want directory/name (though bucket/objectKey will still be correct).

Gravity, however, is kind of nasty to work with (from a computational perspective), particularly in a game situation (where you want realism, but not so real the game play sucks).  Fortunately, it's also exactly the kind of thing that I enjoy wasting my free time playing with.  So I threw together a simple model in Groovy, including a little type system and DSL to help keep my numbers straight.

So now when I divide a Force by a Mass, I'll get an Acceleration back.  Or if I multiply an Acceleration by a Time, I'll get a Velocity.  This was a huge win.  In the world of paper calculations, you don't do just arithmetic, you do unit algebra as well, which helps you ensure your answer makes sense (e.g., if you solve for velocity and get units of "meters per kilogram second", you screwed up somewhere).  But with a computer you don't have units, so I employed a simple type system to afford the same check I'd usually get from unit algebra.  And Groovy makes it remarkably easy to create both an expressive type system and a simple syntax (via operator overloading).

Then I hacked up Processing ever so slightly so I could implement a PApplet in Groovy and avoid the compilation step, and built a simple viewer for the model.  Emphasis on "simple".  Here's a capture with three bodies:

The bodies' sizes represent their relative mass, the green lines represent gravitation between them, the red lines are the velocity vector (per body), and the pink lines are acceleration (also per body).  Here's a few seconds later in the same simulation:

Now, because the bodies are far closer, the forces between them are much greater, which is going to result in a couple fairly impressive slingshots in a moment.  They've also picked up a fair amount of speed, though their active acceleration has surpassed their velocities (i.e., slingshots are imminent).  Here's after the slingshots have happened:

After the two larger bodies slingshotted around each other, the two smaller bodies did the same thing, resulting in a rapidly expanding model.  As you can see the forces are falling away, though the smallest and largest bodies will soon meet up and cross paths.  The velocity of the little one is high enough that the big one can't slow it down enough to do more than deflect it upward a bit.

Processing again completely delivered on it's promise of providing a remarkably simple way to sketch out visual stuff.  Simple event handling, simple setup, a simple draw loop, and solid primitives.  I need to do a little mucking about, but adding 3D support (which the model handles, but the viewer doesn't) will be similarly trivial: flip the "use 3D" bit, and add 'z' coordinates from the model in the various calls.  Very nice, especially when coupled with the Groovy syntax and capabilities.

An interesting project, though we'll see how generally useful.  Code, of course, is available from SVN.  It's a single Eclipse project, including Groovy, Processing, the hacked PApplet (from Processing), the model and the viewer applet.  Check it out and run driver.groovy to see it in action.  While running SPACE will pause/unpause the action, though there is currently no way to rewind/reset the simulation.  If you don't want to check out the project, you can browse it directly.  The interesting bits are in the /src/com/barneyb/gravity/ package.