Silly CFDUMP Question

Report · Jul 10, 2019

We have just recently updated from CF11 to CF2018.

One thing we do often as we develop is use CFDUMP to view the contents of variables and objects as we're coding. We've grown quite fond of ColdFusion's neat little CFDUMP tables that make viewing objects so convenient such as this little example:

However, since installing CF2018, CF when we use a CFDUMP inside a CFC we no longer get this nice view. We get a plain old HTML table that's much harder to read..especially as the objects grow much larger:

Viewing the source code of the dumped page, CF is not inserting the CSS nor JS for it's CFDUMP tables when used within a CFC.

Everything is fine if the CFDUMP is used on a CFM page.

This was not a problem in CF11 nor any version prior.

Any ideas how to get CF to 'dump' out the CSS and JS when used in a CFC?

Report · Jul 11, 2019

Instead of outputting the CFDUMP to the screen, generate an email with CFMAIL set type="html" and send it to yourself. If you have HTML viewing set in your email client, you will get the CFDUMP _and_ have a record of them.

V/r,

^ _ ^

UPDATE: Okay, that was a bit simplistic.

<cfsavecontent variable="thisDump">
<cfdump var="#yourContent#">
</cfsavecontent>
<cfmail   blah blah blah type="html">
#thisDump#
</cfmail>

Report · Jul 11, 2019

Yea, we've done that. It's just nicer/quicker to dump to the screen.

Thanks for the reply.

Report · Jul 11, 2019

I'd still submit it to Bug Tracker. Seems like an odd thing to happen after an "upgrade".

V/r,

^ _ ^

Report · Jul 11, 2019

</cfsavecontent>

</cffunction>

</cfcomponent>

Also

</cfsavecontent>

<cfoutput>#mydump#</cfoutput>

</cffunction>

</cfcomponent>

Report · Jul 24, 2019

Hi, I am getting the same issue even on cfm files. I am trying to narrow this down. I've asked CFSupport as well and they weren't able to sort this out.

Are you running IIS or Apache ?

Report · Jul 27, 2019

sdsinc_pmascari wrote
... we use a CFDUMP inside a CFC ...
Any ideas how to get CF to 'dump' out the CSS and JS when used in a CFC?

In any case, it is poor programming practice for a function to do that. It was bad design for ColdFusion to enable it in the first place.

A function should be defined to accept 0, 1 or more arguments, and to be void or return a value. It should not have the responsibility of revealing its inner contents. When a function outputs its own inner contents, it goes against the following best-practices:

Separation of concerns, for example, Presentation layer (CFM) / Business layer(CFC)

High Cohesion [GRASP (object-oriented design) - Wikipedia ]

Single Responsibility [SOLID - Wikipedia ]

In short, set the output attribute of the CFC and the function to false.

Report · Jul 27, 2019

Setting aside for now the question of whether one should or should not DO a dump in a CFC--and how one can also use attributes of cfdump or writedump to send that output to a file, or that the cfdump to an email above could be done in the cfmail without need of a cfsavecontent :-), I will say that one absolutely SHOULD be able to do it (if they choose), and that in my testing it DOES indeed work as expected, in 2018.

To the OP, I have setup some code in cffiddle.org that you can run (if you login to it--as only logins allow creation or running or even viewing of multi-file demos in the site). It's at https://cffiddle.org/app/3d71bf0c-a596-4ed7-97e7-d198de1020a4 .

But even if you can't or won't run it, note that that site runs by default on CF2018 update 4 (or can be switched to run the same code in CF2016 update 11), and the code works as expected: a dump of a complex object in a CFC DOES produce the normal tabular output, whether run in a method of the CFC or in the pseudo-constructor (outside a method), and whether as cfdump or a writedump, all of which I demo there. (And the code is not "pretty, as it's meant so show the multiple ways the OP may well be doing things.)

So as for why it's "not working" for you, I would propose there must be another explanation. For instance, are you running the CFC (that you're testing) in exactly the same site and path as the cfm that "works"? If you are not, the problem may be that you have a configuration issue (such as in the web server) to explain the difference.

Indeed, I'd be willing to bet that if you view your browser dev tools feature, and its network tab (if you know how to get to those), you would find that one of the supporting files being pulled down for the page rendering is getting a 404 or some other code--and THAT is why you'd not be seeing the "nicely formatted" dump. Can you check?

And perhaps the reason you find it "works" from a CFM is that it's in another folder or site separate from the CFC--and something causes the failure to load the supporting files, for the request which ultimately calls the CFC, versus the request which calls the cfm.

If that's not it, let us know. And in that case, if (regardless of my demo) you may say you "can't test both files in the same site/folder" on your server because you have some reason to need to separate them, fair enough. Just create a test folder and do both there. You're asserting that it doesn't work in CF2018, because of CF2018. I have proven that it does.

One last thing: I'm assuming you are not calling the CFC directly via a URL (passing in a method and perhaps args), right? We can't test doing that at cffiddle.org, and I'm not able to quickly test that otherwise as I am writing this.

If the above doesn't help, please help us know more specifically how what you are doing is different, and we should be able to get to the bottom of this.

/Charlie (troubleshooter, carehart.org)

Report · Jul 29, 2019

Thank you for the replies.

Charlie, I looked into the Network tab and there is nothing. There never would be because the CSS and JS that are needed to format the DUMP look to be coded into the page if you view the source code.

So, I examined the CFFiddle and copied it to my environment and it, too, worked as expected. The dump is formatted as expected.

However....most CF coding in our shop is still done in tags. So, for giggles I rewrote your little test using tags in the CFC and there it is:

https://cffiddle.org/app/7c53bab1-8ecc-4062-9df8-80561d68b158

The CFDUMP in a CFC when the functions are tags, rather than script, the formatting disappears.

Report · Jul 30, 2019

First, a heads-up for folks: unless you login at cffiddle.org, you can't see code shared there via a link like the OP and I have done. I didn;t realize that until now myself.

And when we see the code the OP shared, we see that the issue is not JUST that their problem occurs when using a tag-based cffunction with a tag-based cfdump (the one thing my example did not have), but also they are showing using the OUTPUT="false" attribute of CFFUNCTION.

So you've come to expect that if you said output=false (which is supposed to render no output from the CFC) that you would still see CFDUMP output? I'd think THAT is a bug, or at least unintended behavior--rather than that it doesn't render the table right. Indeed, FWIW, if you specify output=false on the script-based function (which is done AFTER naming the method args or the () if there are none), then the script-based function does NOT render the dump at all, as I'd think is what should be expected.

Anyway, at this point, if you feel that CFDUMP SHOULD still render even in a cffunction with output-false--and that it did before and now does not, then I'd think you'd want to proceed to filing a bug report at tracker.adobe.com. And do be sure to clarify that you're using output=false. You never said that in your opening note here, or in the notes since. You didn't even mention it when BKBK was making his point that in his opinion CFCs should always be set to have output=false, and never produce output.

/Charlie (troubleshooter, carehart.org)

Report · Jul 31, 2019

Yes, it looks like you've nailed it. The OUTPUT="false" is the culprit. And, yes, I feel the dump should still format even when this is in place. And, yes, it always has in previous versions of CF. For instance, in the CFFiddle, run the #dumpsvrTAG()# function on the CF2016 server and it is formatted...even though output is false. Only in 2018 does the formatting disappear.

Around here, we don't use CFDUMP in any final product. We use it during development to verify objects and data as well as during debugging. This makes it vital the data continue to be easy to read for our devs regardless of whether the function has been set to output=true.

Thanks for the help. I will file the bug.

Report · Jan 20, 2021

Just to follow up on this - we also recently moved from 2016 to 2018 and are seeing this issue.

The weird thing is I see this on our development server (native install on Windows), but in my local dev environment (Commandbox Docker) I get the correct blue styled error screen.

And of course this worked fine on CF2016 in both environments.

And I am NOT calling the dump within a CFC. Its basically a FW/1 app, I have an error() method in my main which does some logging, and then in my error.cfm view - I call cfdump.

Report · Jan 20, 2021

And there is a bug open for this: https://tracker.adobe.com/#/view/CF-4204866