Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with: Matthew Reinbold
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with: Matthew Reinbold@libel_vox )

Dumping ColdFusion Values Into A String Variable Using WriteDump()

By Ben Nadel on
Tags: ColdFusion

When it comes to serializing data in ColdFusion (and other languages), my default choice is JSON (JavaScript Object Notation). JSON is a great choice since it is (fairly) human-readable and can be easily deserialized and consumed programmatically. But, sometimes, I know that I'll never need to deserialize data. And in those cases, having something even more human-readable can trump deserialization. As such, I've taken to using writeDump() to serialize data that I intend to read once and then discard.

Out of the box, there is no option to output the writeDump() result to a variable. But, when you invoke writeDump(), it will output to the current buffer. This means that we can output it to a variable using CFSaveContent and a user-defined output buffer. Then, we can use the result like any ordinary String variable:

  • <cfscript>
  •  
  • /**
  • * I dump the given variable to string variable, using writeDump()
  • *
  • * @output false
  • * @hint The PRE tags are stripped from the output.
  • */
  • public string function writeDumpToText( required any input ) {
  •  
  • // Write the dump to an output buffer.
  • savecontent variable="local.result" {
  •  
  • writeDump( var = input, format = "text" );
  •  
  • }
  •  
  • // When you dump to a text output, it wraps the output in PRE tags. We can
  • // strip those out and defer to the calling context to add them back in if
  • // necessary.
  • result = reReplaceNoCase( result, "^<pre>|</pre>\s*$", "", "all" );
  •  
  • return( result );
  •  
  • }
  •  
  •  
  • // ------------------------------------------------------ //
  • // ------------------------------------------------------ //
  •  
  •  
  • // Define our sample data.
  • // --
  • // NOTE: Quoting the keys to maintain casing during serialization. This is a general
  • // limitation of a case-insensitive language.
  • friend = {
  • "id" = 4,
  • "name" = "Kim",
  • "isBestie" = true,
  • "bestTrait" = "compassion"
  • };
  •  
  • // When it comes to serializing data, most of the time, I just defer to JSON
  • // (JavaScript Object Notation) since it can later be deserialized and possibly
  • // consumed programmtically.
  • serializedFriend = serializeJson( friend );
  •  
  • // But, sometimes, I know that I'll never re-consume the data and I just want to be
  • // able to read it easily (either in a Database "text" field or an Email perhaps).
  • textifiedFriend = writeDumpToText( friend );
  •  
  • // Compare the output of the two serialization approaches.
  • // --
  • // NOTE: I'm using PRE tags here since I'm outputting to a web page. If this were a
  • // database field or a plain-text email, the PRE tags would not be necessary.
  • writeOutput( serializedFriend );
  • writeOutput( "<br />" );
  • writeOutput( "<pre>" & textifiedFriend & "</pre>" );
  •  
  • </cfscript>

As you can see, we're invoking writeDump() inside the body of a CFSaveContent tag. This allows the output to be written to our CFSaveContent buffer instead of the current request response output buffer. And, when we run the above code, we get the following output:

{"name":"Kim","isBestie":true,"bestTrait":"compassion","id":4}

struct

bestTrait: compassion
id: 4
isBestie: true
name: Kim

As you can see, both the JSON (JavaScript Object Notation) and the plain text serialization are human readable. But, the plain text is, at least for me, a bit easier to scan.

Just to be clear, I am in no way trying to imply that plain text is better than JSON. I am only saying that in some cases, when my highest priority is readability - not deserialization - I am finding that storing or sending ColdFusion values in writeDump-text format is a fairly nice experience.




Reader Comments

I think a great use case for this is in error reporting. Those are usually something read by a human directly, then dealt with and deleted.

In my applications, in the onError method of Application.cfc I create a dump of the exception variable and several other scopes, such as FORM, URL, CGI and session. Then, save the cfdump of all that to a variable (using cfsavecontent, like in your post) and email it to myself as an HTML attachment.

This typically provides more than enough information to troubleshoot the error and if there's a user logged in, bonus information about who encountered the error. I get a kick out of being able to email someone out of the blue and say "I noticed you may have experienced an error. Here's what happened, and it's now fixed." :)

Reply to this Comment

@Darren,

Error reporting is definitely the context I had when I wrote this function. I have a error logging service that logs exceptions to a database, example:

  • try {
  • // .....
  • } catch ( any error ) {
  • taskFailure.create( taskID = task.id, error = writeDumpToText( error ) );
  • }

Then, I just look in the "text" field of the database record and its super easy to read.

Reply to this Comment

What happens with all the extra JS and CSS that comes with a WriteDump?

When you view-source with a WriteDump in a page there's a whole heap of extra stuff added in.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.