BarneyBlog

Ben Nadel posted about compiling multiple linked files (JS/CSS) into a single file this morning, and he does it at runtime. I commented about doing it at build-time instead, and a couple people were wondering more, so here's a brief explaination.

The first part is a properties file (which can be read by both Ant and CF (or whatever)). Here's an example (named agg.js.properties):

# the type of file being aggregated (used to do minification)
type         = js
# the URL path the files are relative to.
urlBasePath  = /marketing/js/
# the list of filenames to aggregate.  The first line (with the equals
# sign) should be a filename and a slash, all other lines should be a
# comma, a filename, and a slash  Indentation is irrelevant.
filenames    = date.js\
  ,jquery-latest.js\
  ,ui.datepicker.js\
  ,ui.mouse.js\
  ,ui.slider.js\
  ,ui.draggable.js\
  ,jquery.dimensions.js\
  ,jquery.easing.1.2.js\
  ,jquery-easing-compatibility.1.2.js\
  ,coda-slider.1.1.1.js\
  ,jquery.tooltip.min.js\
  ,jScrollPane.min.js\
  ,jquery.metadata.js\
  ,prototype.classes.js\
  ,reporting.js\
  ,jquery.ajaxQueue-min.js\
  ,script.js

This sets up the everything needed for the aggregation. Within our project, we have this file as a peer of the property file (named agg.js.cfm):

<cfscript>
filename = replace(getCurrentTemplatePath(), ".cfm", ".properties");
fis = createObject("java", "java.io.FileInputStream").init(filename);
bis = createObject("java", "java.io.BufferedInputStream").init(fis);
props = createObject("java", "java.util.Properties").init();
props.load(bis);
urlBasePath = props.getProperty("urlBasePath");
type = props.getProperty("type");
filenames = listToArray(props.getProperty('filenames'));
for (i = 1; i LTE arrayLen(filenames); i = i + 1) {
	if (type EQ "css") {
		writeOutput('<link rel="stylesheet" href="#urlBasePath##filenames[i]#" type="text/css" />');
	} else { // js
		writeOutput('<script src="#urlBasePath##filenames[i]#" type="text/javascript"></script>');
	}
	writeOutput(chr(10));
}
</cfscript>

It reads the properties file, and writes out either LINK or SCRIPT tags as appropriate to the individual assets. This facilitates easy debugging in development, because nothing is modified from it's source. The file is included into the HEAD of our layout templates to get everything in page.

The real magic happens with Ant, which we use for our deployments. Within the build file, we have a call to the aggregateAssets target for each properties file:

<antcall target="aggregateAssets">
  <param name="propfile" value="${output}/wwwroot/marketing/templates/agg.js.properties" />
  <param name="rootdir" value="${output}/wwwroot/marketing/js" />
</antcall>

The params specify the properties file and the root directory. Note that the rootdir param corresponds with the urlBasePath in the properties file. The target itself looks like this:

<target name="aggregateAssets">
  <!-- read the aggregation properties -->
  <property file="${propfile}" prefix="agg" />

  <!-- get the root -->
  <propertyregex property="agg.root"
    input="${propfile}"
    regexp="^(.*)\.properties$"
    select="\1" />

  <!-- split the root into file and path sections -->
  <propertyregex property="agg.fileroot"
    input="${agg.root}"
    regexp="^.*/([^/]+)$"
    select="\1″ />
  <propertyregex property="agg.pathroot"
    input="${agg.root}"
    regexp="^(.*/)[^/]+$"
    select="\1″ />

  <!– set up the output file stuff –>
  <property name="agg.outfile" value="${rootdir}/${agg.fileroot}" />
  <property name="agg.cfmfile" value="${agg.root}.cfm" />
  <property name="minsuffix" value=".yuimin" />

  <!– run everything through the YUI Compressor –>
  <for list="${agg.filenames}" param="filename">
    <sequential>
      <echo message="compressing @{filename} to @{filename}${minsuffix} (in ${rootdir})" />
      <java classname="com.yahoo.platform.yui.compressor.YUICompressor"
        failonerror="true"
        output="${rootdir}/@{filename}${minsuffix}"
        append="true"
        logError="true"
        fork="true">
        <arg value="–type"/>
        <arg value="${agg.type}"/>
        <arg value="–nomunge"/>
        <arg file="${rootdir}/@{filename}" />
        <classpath>
          <pathelement path="${java.class.path}"/>
        </classpath>
      </java>
    </sequential>
  </for>

  <!– aggregate all the compressed files together –>
  <echo file="${agg.outfile}" message="// built by Ant using YUI Compressor" />
  <for list="${agg.filenames}" param="filename">
    <sequential>
      <concat destfile="${agg.outfile}" append="true">
        <header trimleading="true">
          // @{filename}
        </header>
        <filelist dir="${rootdir}" files="@{filename}${minsuffix}" />
      </concat>
    </sequential>
  </for>

  <!– delete all the compressed files –>
  <delete>
    <fileset dir="${rootdir}" includes="*${minsuffix}" />
  </delete>

  <!– write the CFM file to pull in the compressed and aggregated file –>
  <if>
    <equals arg1="${agg.type}" arg2="css" />
    <then>
      <echo file="${agg.cfmfile}"><![CDATA[<link rel="stylesheet" href="${agg.urlBasePath}${agg.fileroot}" type="text/css" />]]></echo>
    </then>
    <else>
      <echo file="${agg.cfmfile}"><![CDATA[<script src="${agg.urlBasePath}${agg.fileroot}" type="text/javascript"></script>]]></echo>
    </else>
  </if>
</target>

First, it reads the properties file, runs each listed asset through the YUI Compressor, and then aggregates the result. Finally, it overwrites agg.js.cfm (from above) with one that contains a single LINK/SCRIPT element to the aggregation result. End result is a single aggregated, compressed asset in production for speed, and separate uncompressed assets in development for easy debugging.

Edit: Do note that you'll need both the ant-contrib package and the YUI Compressor JARs to be installed into Ant for this to work.

Brian Rinaldi posted on his blog about dummy queries in CF 8.0.1, and it struck me as a weird solution. So here's a drop-in replacement, that I think works in a more reasonable fashion, and doesn't have any dependency on an existing DSN.

<cffunction name="dummyQuery2" access="public" output="false" returntype="query">
  <cfargument name="queryData" type="struct" required="true" />
  <cfset var i = 0 />
  <cfset var columnName = "" />
  <cfset var myQuery = queryNew(structKeyList(queryData)) />
  <cfset var queryLength = arrayLen(arguments.queryData[listFirst(structKeyList(arguments.queryData))]) />
  <cfloop from="1″ to="#queryLength#" index="i">
    <cfset queryAddRow(myQuery) />
    <cfloop collection="#arguments.queryData#" item="columnName">
      <cfset querySetCell(myQuery, columnName, queryData[columnName][i]) />
    </cfloop>
  </cfloop>
  <cfquery dbtype="query" name="myQuery">
    select *
    from [myQuery]
  </cfquery>
  <cfreturn myQuery />
</cffunction>

As you can see, the structure is almost identical, but it doesn't use a database, it just builds in memory. The "no-op" QofQ at the end is to ensure there is actual query metadata, not just the raw records, which Brian listed as one of his prerequisites. If you don't care, it can be removed with no ill effects.

One interesting benefit of this approach is that the rows come out in the same order as they go in - with Brian's DB-based one, that's not guaranteed because there is no ORDER BY clause on the query. Running his example on my box (using MSSQL 2005), I got rows sorted by first name. With the in-memory building, the rows are explicitly kept in order throughout.

Back in October I posed a fledgling cycle-safe CFDUMP replacement.  Today, I had need for that same anti-cycle processing in serializeJson, so I abstracted the processing out into a CFC that handles both breaking cycles (for serialization) as well as restoring them (for deserialization).  By running a cyclic data structure through the breakCycles method, you can use CFDUMP, serializeJson, or whatever other context-free recursive algorithm you want on it without fear of infinite looping.  If you later turn that data structure back into an in-memory structure, you can use the restoreCycles method to recreate the cyclic references that breakCycles removed.

You can download the CFC (as a text file) here: cyclicutils.cfc.txt.  If you have the example from the cycle-safe CFDUMP somewhere, save the CFC in the same directory and tack this code on to the end of the test case:

<cfset cu = createObject("component", "cyclicutils") />
<cfset b = cu.breakCycles(b) />
<cfdump var="#b#" label="b" />
<cfset b = cu.restoreCycles(b) />
<u:dump var="#b#" />

You'll see the cyclic structure dumped with the cycle-safe CFDUMP as before, then the cycles are broken and it's dumped with the standard CFDUMP, and then the cycles are restored and it's dumped with the cycle-safe CFDUMP again.

Otherwise, just create yourself a cyclic structure and pass it to breakCycles.