But after updating to CF10 I realized this didn’t work anymore! I was surprised, since I thought the getPageContext() stuff was pretty standard, and not undocumented. So anyway I’ve rewritten my function to work in CF10. The code is much simpler now.

<cffunction name="formFieldAsArray" returntype="array" output="false" hint="Returns a Form/URL variable as an array.">
	<cfargument name="fieldName" required="true" type="string" hint="Name of the Form or URL field" />
	
	<cfset var content = getHTTPRequestData().content />
	<cfset var returnArray = arrayNew(1) />
	
	<cfloop list="#content#" delimiters="&" index="local.parameter">
		<cfif listFirst(local.parameter,"=") EQ arguments.fieldName>
			<cfif ListLen(local.parameter,"=") EQ 2>
				<cfset arrayAppend(returnArray,URLDecode(listLast(local.parameter,"="))) />
			<cfelse>
				<cfset arrayAppend(returnArray,"") />
			</cfif>
		</cfif>
	</cfloop>
	
	<cfreturn returnArray />

</cffunction>

You may have heard about the new sameformfieldsasarray setting in CF10. This is another option. But it is application-wide. That is, anytime you have form fields with the same name they will come through as an array. This may or may not work for you. In my application, enabling that would break a lot of code so I wrote this separate function to handle when I need the values as an array.

<img src="#productImage#" onerror="this.src='/images/icons/imageDoesNotExist.png'" >

That’s it. Be careful that in your error handling code you point to an image file that really exists, otherwise you could go into an infinite loop. One way to be safe regarding that would be to call a function, and remove the onerror attribute so that it only gets fired once.

<script>
function imageError(element) {
	element.onerror='';
	element.src='/images/icons/imageDoesNotExist.png';
	}
</script>

<img src="#productImage#" onerror="imageError(this)">

You could even use this to report a broken image:

<img src="#productImage#" onerror="this.src='logBrokenImage.cfm?image=' + this.src" >

The onerror event is supported in all major browsers. The other tags that support onerror are object, script, and style.

There are a few ways to get these results into Excel, but this is what I do. After running the query, I click on the blank box that intersects the row numbers and the column headers. This causes all the rows & columns to be selected. You could also press Ctrl+A to do the same thing.

Then I copy the results using Ctrl+C, then switch over to my Excel window and paste the results in. And voilà, the column headers are there.

For example, a customer buys a product at 11:00pm our time on the 1st of the month. The timestamp in the database for this record will be 5:00am on the 2nd, since we are -6 hours from UTC here in the Central timezone.

So we modify timestamps in our reporting queries like this:

...  WHERE
order.createDate > <cfqueryparam value="#DateConvert('local2utc', arguments.startDate)#" cfsqltype="cf_sql_timestamp">
AND
order.createDate < <cfqueryparam value="#DateConvert('local2utc', arguments.endDate)#" cfsqltype="cf_sql_timestamp">

There is an issue with this in CF10. Take this code:

<cfset arguments.startDate = CreateDateTime(2012,1,1,00,00,00) />
<cfquery>
...
WHERE order.createDate > <cfqueryparam value="#DateConvert('local2utc', arguments.startDate)#" cfsqltype="cf_sql_timestamp">
....
</cfquery>
<cflog text="I think I passed #DateConvert('local2utc', arguments.startDate)# to the database" />

If you look in your log you’ll see I think I passed {ts '2012-01-02 6:00:00'} to the database (since I am -6 from UTC). But if you look in the debugging information for this query, or use SQL Server Profiler to view it, you’ll see it gets sent to the database as 2012-01-01 00:00:00:000!

My guess is that the DateConvert() method doesn’t actually change the value. Instead it does something like adjust the timezone or offset inside the date object. And I think the cfqueryparam tag isn’t paying attention to whatever DateConvert has changed. I further confirmed this by trying to add .toString() on the method result, inside the cfqueryparam tag. This causes the expected behavior.

After tracking this down my coworker Jason Troy discovered there is a bug report for this already. From reading through these bug reports it doesn’t sound like Adobe is going to make any changes, however. They do point out that you can set this JVM argument to return to the previous behavior of CF9: -Dcoldfusion.preserveTimeZoneOnPersist=true.

More info:
https://bugbase.adobe.com/index.cfm?event=bug&id=3338974
https://bugbase.adobe.com/index.cfm?event=bug&id=3347145

So for now what I’ve done is change my code to this:

...  WHERE
order.createDate > <cfqueryparam value="#DateConvert('local2utc', arguments.startDate).toString()#" cfsqltype="cf_sql_timestamp">
AND
order.createDate < <cfqueryparam value="#DateConvert('local2utc', arguments.endDate).toString()#" cfsqltype="cf_sql_timestamp">

You may wonder what’s the reason for this change in behavior? It’s alluded to in the bug reports above. I think there is a different way we are supposed to be doing this now, I haven’t got it completely figured out yet. One of the bug report comments from Himavanth Rachamsetty, who is on ColdFusion team, says this:

The current CF 10 behavior included in the update 4 is correct because when you move the time from one timezone to another, date.getTime() should not change at all.
The way date object is defined in Java, the time elapsed since Epoch should not change at all no matter which timezone the date is in. CF 9 and the earlier versions were violating this definition of Java date and were changing the time elapsed since epoch. This caused few issues which we fixed in CF 10.
When the date is persisted and retrieved from DB, the JVM automatically converts it back to local timezone. While retrieving a date, we don’t have any mechanism to find out that a date was converted to UTC when it was first inserted and therefore we would not be able to do any conversion ourselves. It is actually the application’s responsibility to convert the date/time to appropriate timezone after it is retrieved. Another option to work with date and DB is – you always store date as string in DB and when it is retrieved, convert it back to date.
Since this change of behavior in CF 10 could break a lot of applications, we have fixed this by introducing a flag so that the applications can run without any issues. Since this flag changes the way date is defined in Java, we will keep it disabled by default.

<cfset theClientFilename = getClientFileName("myFormField")>
<cfif ListLast(theClientFilename,".") NEQ "pdf">
   // do your error handling here
<cfelse>
  // else the extension is ok. Use cffile to handle the upload and proceed
</cfif>

Here is the getClientFileName function, both in cfscript and regular tag formats.

<cfscript>
function getClientFileName(fieldName) {
	var tmpPartsArray = Form.getPartsArray();
	var clientFileName = "";

	if (IsDefined("tmpPartsArray")) {
		for (local.tmpPart in tmpPartsArray) {
			if (local.tmpPart.isFile() AND local.tmpPart.getName() EQ arguments.fieldName) {
				return local.tmpPart.getFileName();
				}
			}
		}
	
	return "";
	}
</cfscript>

<cffunction name="getClientFileName" returntype="string" output="false" hint="">
	<cfargument name="fieldName" required="true" type="string" hint="Name of the Form field" />

	<cfset var tmpPartsArray = Form.getPartsArray() />

	<cfif IsDefined("tmpPartsArray")>
		<cfloop array="#tmpPartsArray#" index="local.tmpPart">
			<cfif local.tmpPart.isFile() AND local.tmpPart.getName() EQ arguments.fieldName> 
				<cfreturn local.tmpPart.getFileName() />
			</cfif>
		</cfloop>
	</cfif>
	
	<cfreturn "" />
</cffunction>

I wrote and tested this on CF10, but it will probably work all the way back to CF7. I tried this on Railo and it did not work, it errored on the getPartsArray() method. If you need to do this on Railo, this code will work (tested on 4.0.2): GetPageContext().formScope().getUploadResource("myFormField").getName()

var allValues = $("input.someClass").map(function() { return this.value; }).get().join('');

if (allValues.length) {
  // do validation here to make sure all fields are filled in
  }

This problem doesn’t only apply to Mura, it will crop up with framework or code that uses the onMissingTemplate handler. The fix is easy. Edit the web.config file in the webroot, look for an httpErrors tag. It might look like this:

You need to add existingResponse="PassThrough" to it. If that element is missing completely, just add it with the necessary attribute.

Fixed!

Get it here: http://hostek.com/hosting/coldfusion/coldfusion10-hosting.asp

Lets say you have a spread sheet containing these columns: Name, City, State, Postal Code. Then pull it into a query using the cfspreadsheet tag:
<cfspreadsheet action="read" src="c:\Customers.xls" query="customers" headerrow="1" rows="2-65536" sheetname="Customers">

Now try to narrow down the results to only those in a certain postal code. This won’t work of course:
<cfquery name="qryCA" dbtype="query">
SELECT * FROM customers WHERE [Postal Code] = '90210'
</cfquery>

Neither will this:
<cfquery name="qryCA" dbtype="query">
SELECT * FROM customers WHERE [Postal\ Code] = '90210'
</cfquery>

Or this:
<cfquery name="qryCA" dbtype="query">
SELECT * FROM customers WHERE ['Postal Code'] = '90210'
</cfquery>

I have not found any way to escape a space in a column name inside QoQ. But, thankfully there is a way we can manipulate the column names to remove the space.

<cfset colNameArray = customers.getColumnNames() />
<cfloop from="1" to="#arrayLen(colNameArray)#" index="i">
	<cfset colNameArray[i] = colNameArray[i].replace(' ','') />
</cfloop>
<cfset customers.setColumnNames(colNameArray) />

You could use this to completely rename column names if you wanted to. This isn’t just useful for working with cfspreadsheet either, I could see this being used in other circumstances to change the column names.

Thanks to Steven Neiland for pointing me in this direction.

Here is one for formatting XML: http://www.shell-tools.net/index.php?op=xml_format

And one for JSON from the same site: http://www.shell-tools.net/index.php?op=json_format

Here is a SQL one that helped me out a lot tonight: http://www.dpriver.com/pp/sqlformat.htm

I fed it a horrible looking, very complex query and it made it easily readable.