cfdump

<cfdump 
   var = "#variable#"
   expand = "Yes or No" 
   label = "text">

<cfif IsXmlDoc(mydoc) is "True">
   <cfdump var="#mydoc#">
</cfif>

<cfdump var="#URL#">

Comments

rraga said on Dec 2, 2003 at 2:16 PM :

Anyone know what version of CF did CFDump first appear?

rraga said on Dec 2, 2003 at 2:24 PM :

For that matter, it would be nice if MM included version of inclusion for all CFML and functions. This would be beneficial in doing compliancy and backward compatibility evaluations.

jrunrandy said on Dec 3, 2003 at 6:02 AM :

The CFDUMP tag was new in CF 5 (although it originated in Spectra 1.0).

The CMFL Reference lists changes since CF 5 on http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-p17.htm

Additionally, the Macromedia ColdFusion Support site has a technote with complete information: http://www.macromedia.com/support/coldfusion/ts/documents/cfmlhistory.htm

No screen name said on Dec 5, 2003 at 2:35 PM :

Note: If you have a cfdump inside an output suppressed component function, it will break your future cfdumps (even in non-supressed functions).

This happens because cfdump will only write needed style and script data once, but if it's called from an output supressed component, these definitions never get written, and future cfdumps think it is included in the document already and dont attempt to include them again.

csteinola said on Jan 23, 2004 at 12:35 PM :

Why does EXPAND="no" not work for dumps of queries?

I would expect that the output would be collapsed to the header row.

halL said on Jan 30, 2004 at 10:59 AM :

A ColdFusion bug (number 51732) has been reported against this issue.

inix said on Feb 3, 2004 at 4:00 AM :

EXPAND="no" and all the Javascript for expanding and contracting also doesn't work on pages containing the <CFCACHE> tag, even if that tag is set to 0...

halL said on Feb 3, 2004 at 6:09 AM :

A ColdFusion bug (No. 54114) has been entered against this behvior.

wlee said on Mar 23, 2004 at 6:44 AM :

We are working to improve the examples in the ColdFusion reference pages. We propose to replace the current example on this page with the the following example. If you have any comments on this example, add them to this page.

This example shows how to use this tag to display the CGI scope as a structure:

<cfdump var="#cgi#">

csteinola said on Mar 23, 2004 at 10:58 AM :

It seems CFDUMP is trying to be intelligent about whether it has already been called once during the request.

If it hasn't, then the call to CFDUMP outputs the stylesheet and javascript, then outputs the data.

If it has been called already, then CFDUMP only outputs the data.

Except we've found many instances where this isn't the desired behavior (the first call was within a CFMAIL or CFFILE tag, hence the stylesheet was written in that context, but then a subsequent call in the template scope is missing all the styles/js behaviors).

A workaround is to set the REQUEST.cfdumpinited=FALSE right before calling the tag in such situations ... forcing CFDUMP to reinitialize (and, thus, output styles, etc) even though it may already have been called elsewhere during the request.

Perhaps this could be pointed out in the documentation. Or some other solution provided (like CFDUMP being aware of whether it's called within CFMAILs, etc).

spage said on Apr 16, 2004 at 11:29 PM :

It seems if you use the label attribute but you dump a simple variable, you don't see the label. The label would go in the fancy HTML decorating a complex structure, but this doesn't get output for simple variables.

This feels like a bug, it makes it hard to troubleshoot your debug output when you can't find your dump labels.

E.g.
<cfdump label="here is my complex label" var="#cgi.SCRIPT_NAME#">
just dumps out the script name, with no label.

ChronoCrypt said on Sep 10, 2004 at 4:18 AM :

since MX 6.1 cfdump can not handle cfcatch, right? i only get an "unknown type" message...

S.Wright said on Sep 22, 2004 at 10:12 PM :

CFDUMP is royally stuffed in 6.1.... dumping #cfcatch# no longer works, and worse still, dumping #cgi# results in an INCOMPLETE data set, ignoring ANY custom HTTP header passed to the web server.

Not happy.

S.Wright said on Sep 22, 2004 at 10:15 PM :

The inline CSS that CFDUMP inserts doesn't work with XHTML pages. The table colors aren't pounded, which means web browsers which follow strict rules with XHTML (incredibly, this INCLUDES Internet Explorer 6) will show the dump in black and white.

Shivang13 said on Oct 21, 2004 at 7:02 AM :

Is MM doing anything about CFCATCH not dumping after applying Updater that released on August 25th 2004. MM needs to be active on this issue since lot of developers rely on dump information to better debug the application.

martypaz said on Nov 29, 2004 at 11:25 PM :

I have a fix that I've written.. It's a replacement for the broken one.

http://www.beetrootstreet.co.uk/products/index.cfm?Content_ID=5F8D9453-AE1F-3B96-86FBB3A0DED55060

martypaz said on Nov 29, 2004 at 11:28 PM :

Sorry, I'm a bit tired and that last note didn't make sense... I have written a replacement so that you can now do a CFDUMP of CFCATCH.

mocax said on May 24, 2005 at 8:05 PM :

the stylsheet included in cfdump isn't standard compliant.
the formatting breaks when a standard doctype is defined in the html document.

gonzoprosperity said on Jun 8, 2005 at 1:22 PM :

Because cfdump'ing CFCATCH results in wacky errors you can get around this by employing this loop rather than a cfdump:

<cfloop collection=#cfcatch# item="i">
<cfset data = StructFind(cfcatch, i)>
<cfif IsSimpleValue(data) AND (Not i CONTAINS "stacktrace")>
<cfoutput><strong>#Ucase(i)#</strong> = #data#<br></cfoutput>
</cfif>
</cfloop>

moneybagsxp said on Feb 8, 2006 at 1:41 PM :

Ran across this one the other day, thought that it was an issue with our DB model, but turns out it was CFDump. (on CF 6.1) My apologies in advance if this has already been reported/corrected.

When CFDUMPing a query with like-column names, i.e.

SELECT a.colName, b.colName
FROM table1 as a, table2 as b
WHERE a.likeKey = b.likeKey
and a.colName <> b.colName

...though a.colName should not be equal to b.colName in the example above, the values output by CFDUMP do not reflect this, as they are displayed identical.

Further, this appears to be the case for ANY like column name, regardless of whether you're joining or not:

i.e.

select 'a' as test, 'b' as test from fakeTable

Outputs:

Result Set - query
TEST TEST
1 a a


Some obvious confliction going on there! For us, we simply aliassed the resulting joins to unique names to view the desired output, but the bug silently remains!