ColdFusion – Stillnet Studios

Accessing form fields as an array in CF10

Ryan — Wed, 20 Feb 2013 00:20:44 +0000

A while back I wrote a post about accessing form fields in ColdFusion as an array. This is useful when you have several fields with the same name, and there is a chance they could contain a comma. Working with the data as an array is much more robust.

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.

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.

Using DateConvert to get a UTC timestamp may not return what you expect

Ryan — Thu, 13 Dec 2012 18:57:56 +0000

I ran into an interesting issue today. Our database timestamps are all stored in UTC. So when a user runs a report from a webpage, we convert the time they entered into a UTC timestamp. If we didn’t do this, the report may miss some records.

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 > 
AND
order.createDate <

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



...
WHERE order.createDate > 
....

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 > .toString()#" cfsqltype="cf_sql_timestamp">
AND
order.createDate < .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.

Getting the client filename before using cffile

Ryan — Tue, 04 Dec 2012 06:41:47 +0000

When accepting uploads from a browser, it can sometimes be handy to have access to the filename before using CFFILE to “upload” the file onto the file system. For example say you want to show an error message if the file is not a PDF. In that case what I’ve usually done is use CFFILE to place the file onto the file system, and then check the extension. If its not in my allowed list, then I delete the file and send an error message to the client. But using the code below I can check the file extension without having to use CFFILE first. For example you could do something like this:



   // do your error handling here

  // else the extension is ok. Use cffile to handle the upload and proceed

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


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 "";
	}

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()

Free ColdFusion 10 beta hosting

Ryan — Mon, 05 Mar 2012 03:47:22 +0000

Wanting to try out the new ColdFusion 10 beta without downloading and installing it? Hostek is offering free CF 10 beta hosting. You’ll get 5GB of storage space, and 200GB of transfer. Plenty of resources to play around with. You’ll get your own subdomain to use, and access to a MySQL database.

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

Removing spaces from columns in cfspreadsheet (or any query)

Ryan — Mon, 17 Oct 2011 02:33:07 +0000

I love the CFSPREADSHEET tag that was added to ColdFusion9. It makes working with spread sheet data so easy. The spreadsheets I am given to work with often contain descriptive column names that contain spaces like “First Name” or “Home Phone”. This causes a problem when you try to work with the data in a QoQ (query of a query).

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:

Now try to narrow down the results to only those in a certain postal code. This won’t work of course:
SELECT * FROM customers WHERE [Postal Code] = '90210'

Neither will this:
SELECT * FROM customers WHERE [Postal\ Code] = '90210'

Or this:
SELECT * FROM customers WHERE ['Postal Code'] = '90210'

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.

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.

Formatting CFGRID with JavaScript

Ryan — Mon, 04 Apr 2011 14:47:24 +0000

A while back I had the need to do some formatting on a cfgrid. I was using a typical product/price table but the prices are stored with 4 decimals and we needed to display that much resolution. The html version of CFGRID does not directly support this.

Consider this “fake” query set:

Note the prices have 4 decimal values, this is how they come to us from the database. If you try to display these with this cfgrid code:

You will end up with this:

Notice the 3rd material is displayed correctly, but the others are not, we would like them to all have the same number of decimals for consistency. You might think you could use cfgridcolumn tags and the numberformat attribute like this:

But this will not work, the numberformat attribute only works on Java type cfgrids, not HTML ones. This attempt will silently fail with no error message, leaving you scratching your head for a while. Lucky for us, ColdFusion creates its grids using the populat EXT JavaScript framework. This means there is a lot of documentation and examples out there on how to work with this code in EXT. Its pretty easy to hook into the grid with JavaScript and format the data.

But you can’t run the JavaScript code when your page loads because the grid takes a few milliseconds to get setup, so if your code runs right away it won’t find the grid. You could use the JavaScript setTimeout() to delay execution of your code:

However you would be guessing at how long it will take and its going to vary on each client. I know ColdFusion has the built in ajaxOnLoad function that is supposed to run your code after things like grids have been created, but I have never gotten this to work. I know for sure it won’t work for content that is loaded secondarily after the base page has finished loading, like many of my pages are. But I can’t get it work even on a simple test file. So I wrote a little function to watch for the grid, and call the formatting code when the grid exists.

And this is the result:

The code could definitely be cleaned up a little, so the grid name isn’t duplicated at least, but its a good start. There are lots of other formatters available also, we’ve found the DateRenderer to be useful.

Accessing ColdFusion form values as an array

Ryan — Tue, 22 Mar 2011 13:44:49 +0000

When you pass several form or URL variables into ColdFusion with the same name, they end up as a comma separated list. This is commonly done with checkboxes – a user can check as many items as they want, then they will end up in your code all in a single variable. In many other languages, Ruby or PHP for example, the selected items will end up in an array. Getting these values as a list usually works fine, until one of your values contains the list delimiter (comma). Take this form, for example:


Select your books:

A Wrinkle in Time


A Tale of Two Cities


The Lion, the Witch and the Wardrobe

If you check the first two boxes and submit the form, you will end up with this in the form scope:

But if you check the third book, which has a title containing commas, things start to get messy:

How can you tell the selections apart!? You can’t. Now, ideally you should be using an ID for the checkbox values instead of a string. In this example maybe you’d use the ISBN number instead of the title. But this is not always possible. Sometimes you are receiving a form post from a third party which you have no control over. I’ve run into situations where the checkbox values contained part numbers, which you would think would be comma-safe, but we did encounter some part numbers that contained commas (don’t get me started…)

But, ColdFusion gives us the power of Java under the hood, and we can reach down into the Java layer to pull out these parameters as a real array! Its very easy:

getPageContext().getRequest().getParameterValues('Your form or url field name')

So lets try it with the ‘books’ field:

Gives us:

Nice! Another interesting method is getParameterMap(). It gives us Form and URL variables, with each variable coming through as its own array. To show this, I’ve modified the form tag a little to include a URL variable:

Here is the output of the getParameterMap() method:

As I was wrapping up this blog post another opportunity arose to use this idea at work. We tried this, but for some reason it wasn’t working, we always got an undefined value instead of an array. After some research we discovered this way of pulling parameters only works on regular application/x-www-form-urlencoded encoded forms. When you upload files on a form, as we were in this case, you need to use the multipart/form-data enctype. Which renders this nice trick useless.

But there is another way to get the values as an array when the enctype is set to application/x-www-form-urlencoded. Below is a method that will return a form or URL variable as an array, and it works for either enctype. All values with the given name will be returned, whether they came in on the URL or the Form scope.


	

	
	 
	
	
	
	< !--- if the getPartsArray method did not return NULL, then this is a multipart/form-data request, which must be handled as such. --->
	
		
			
				
			
		
	
	
	< !--- Add the values that maybe on the URL with the same name, also if this *wasn't* a multipart/form-data request then
	the above code did not get any of the data, and the method below will return all of it. --->
	
	
	< !--- that may have returned null, so need to test for it. --->

If you copy and paste the code above you’ll need to fix the comments to get it to execute, I had to mangle them to get them to display properly in this post.

Loading CFrichtext / FCKeditor on-the-fly

Ryan — Sun, 06 Mar 2011 22:20:06 +0000

At work we had an issue where we had too many FCKeditor rich text controls on a page at once. We probably had 6 or 7, each on their own tab. For the tabs we are using the tag. FireFox would handle the page with no problems, but IE would sometimes fail to load one or more of the rich text controls and would not throw any kind of error about it. The controls simply did not display.

A solution we came up with was to load the rich text controls on demand, when the user needed to use them, rather than load them all when the page first loads. At first I thought we’d have to install a separate, stand alone copy of FCKeditor (now called “CKEditor”) to do this, but we found out this is unnecessary, you use the version that comes with CF to do this.

First, we manually load the FCKeditor JavaScript:

Then create a function that can change a regular textarea into a rich text controls:

Then we changed the places on the page that used to have rich text controls to instead use plain textareas. Then placed an link next to each one the user can click on to change the textarea into a rich text. Sometimes they don’t need the functionality of rich text and will just enter plain text into a textarea. Here is the code:

click to use editor

This is used for creating records only, not editing. But it would not be hard to modify this to make it work on an edit page also.

Mura URL rewriting on Windows 2008 / IIS7

Ryan — Thu, 09 Dec 2010 23:21:00 +0000

I have been involved in setting up a new Mura site on Windows 2008 Server. Mura is a full featured CMS written in ColdFusion.

By default Mura URLs look something like /index.cfm/SiteID/pagename. So for example the contact us page might look like /index.cfm/default/contact-us. Not a great URL. But its fairly simple to translate into /contact-us which is much nicer.

Getting rid of the SiteID

Getting rid of the siteID is easy in the newest version of Mura. In the config/settings.ini.cfm file there is a setting named “siteidinurls”. Set this to 0 and Mura will no longer add the siteID to the URLs it generates. Of course this only works if you plan on only using Mura for one site. If you had more than one site, Mura wouldn’t know which one you are trying to access. There are several ways to get around this if you have more than one site, but I won’t get into that in this article.

Getting rid of the index.cfm

Getting rid of the index.cfm takes a little more work. There is another setting in the ini file called indexfileinurls. Setting this to 0 will remove the index.cfm from the URLs Mura generates. But when you click on any of those links you are going to get the 404 page. To fix this, you’ll need to tweak your webserver.

Apache is pretty straight forward, as you would expect. Enable the mod_rewrite module and drop this into an .htaccess file in your webroot:

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^([a-zA-Z0-9/-]+)$ /index.cfm%{REQUEST_URI} [PT]

Our site happens to be hosted on Windows 2008 Server / IIS7. To do the rewriting on II7 you’ll need to install Microsoft’s URL rewriting extension. You can get it from here: http://www.iis.net/download/URLRewrite

Once its installed, open IIS Manager. Click on your website, then double click on the new URL rewrite icon.

Select Import Rules from the right hand side.

Then paste the apache lines above into the Rewrite rules box.

Instantly you’ll see the new rules appear in the Converted Rules box. Click Apply in the upper right.

Now change the Mura ini file I mentioned above, then click the Reload link in your Mura admin.

That’s it!

Be careful using ucase() on odd characters

Ryan — Wed, 08 Sep 2010 01:53:31 +0000

I ran into an issue today where users were unable to lookup a certain part in our system. The part in question had a µ character in the product code (don’t get me started!). I started adding some debug outputs and found that when the part number was passed to our back end system, the µ had been replaced with an ‘M’!

After some more troubleshooting I figured out the culprit was ucase(). We run all part numbers through ucase() before passing them in. At first I thought this was a CF bug, after verifying that the java string.toUpperCase() method did exactly the same thing I had to look into it some more.

It turns out that M actually is the uppercase version of µ, sort of. The µ character, which is ascii code 181, is often used to abbreviate ‘micro’ as in microamp (µA) or microfarad (µF). Its the 12th letter of the greek alphabet, ‘Mu‘. The lowercase version is μ, the uppercase version is M.

I tested this on Railo and got exactly the same result, which makes sense because I think both engines just call the .toUpperCase() method in the JVM.

So while this is technically correct, I’m certain is almost never what the developer actually wants to do. I have not found a good way around this issue, except to maybe look specifically for this character, replace it out, do the ucase(), then put the character back. For now I was able to remove the ucase() calls because they were not absolutely necessary. Any other ideas?

Update: This is what I came up with as a work around. I thought it would be slow but benchmarking it shows its 0ms even with a 50 character string.