Failure with cfsetting and cfprocessingdirective?

Report · Dec 24, 2008

I have the following code buried deeply in our application. I've tried to reproduce a simpler example without success. This example clearly fails. What can I do to get the cfsetting and cfprocessingdirective tags to work correctly?

The code:

<cfsavecontent variable='AlsVar'><cfprocessingdirective suppresswhitespace='yes'>before<CFSETTING ENABLECFOUTPUTONLY="yes">
<cfloop index="i" from="1" to="6" step="1">
<cfif i mod 2>
#i# is Als odd 

<cfelse>

#i# is Als even 

</cfif>

</cfloop>
<CFSETTING ENABLECFOUTPUTONLY="no">after</cfprocessingdirective>
</cfsavecontent>
<cfmail from="support@uniformmarket.com" to="al@uniformmarket.com" subject="ProcessTag:#strElementName#">#AlsVar#</cfmail>

The content of the email that I get is:

before
#i# is Als odd 

#i# is Als even 

#i# is Als odd 

#i# is Als even 

#i# is Als odd 

#i# is Als even 

after

Which shows that both tags are being ignored: There is output outside the cfoutput tag AND the irregular spacing shows that whitespace is not being suppressed.

As stated, when I try simpler examples, it works and the documentation says that a "yes" in either tag overrides any number of previous "no"s!

Report · Dec 24, 2008

the way i usually structure similar code is:

<cfprocessingdirectvive>
<cfsetting>
<cfsavecontent><cfoutput>
...
</cfoutput></cfsavecontent>
<cfsetting>
</cfprocessingdirective>

in many cases dealing with creating content for emails or XML/CSV/etc
files, you still need to carefully control whitespace in your code
inside <cfsavecontent> block...

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

Report · Dec 25, 2008

Where are your <cfotuput> tags: around the whole lot? There's none in your
example code, so that's what I'm having to ass-u-me.

Put your <cfotuput> tags around just the bits you want to output, eg:

<cfoutput>#i# is Als odd </cfoutput>

--
Adam

Report · Dec 25, 2008

The point is that without the <cfoutput></cfoutput> nothing should have been output! The #i# isn't being resolved because the code is NOT inside paired cfoutput tags.

Thus, nothing should have been generated inside the:

<CFSETTING ENABLECFOUTPUTONLY="yes">
...
<CFSETTING ENABLECFOUTPUTONLY="no">

But, because the code IS being generated, this smells like a bug. If it is, I need to know what triggers the bug because the code shown ALWAYS fails and yet when I try to create simple test cases, they ALWAYS work!

Therefore, *something* is making the CF interpreter erroneously ignore the <CFSETTING ENABLECFOUTPUTONLY="yes"> tag!!!!

Ditto for <cfprocessingdirective suppresswhitespace='yes'>!!!!

What?

Report · Dec 25, 2008

Al Baker wrote:
> What?

from the docs: "You cannot use this tag to suppress output from a tag library."

Report · Dec 26, 2008

But, that is exactly where we NEED it suppressed? Otherwise the tags are generating HUGE HTML files!

That being the case, how DO we suppress the white space and non-cfoutput content? (Without duplicating the code, and maintenance nightmare, in 273 (and growing) different online stores, that is!)

Report · Dec 26, 2008

Al Baker wrote:
> The content of the email that I get is:
>
> before
> #i# is Als odd 
>
>
>
> #i# is Als even 
>
>
> #i# is Als odd 
>
>
>
> #i# is Als even 
>
>
> #i# is Als odd 
>
>
>
> #i# is Als even 
>
> after

now that i actually ran you code, that's not what i'm getting on cf8. all i see is:

beforeafter

Report · Dec 27, 2008

> now that i actually ran you code, that's not what i'm getting on cf8. all i see is:
>
> beforeaft

Also confirmed for me on CFMX7.0.2 and CF8.

So - Al - what version of CF are you seeing this on?

--
Adam

Report · Dec 27, 2008

If you read my initial posting, the code works when I try to reproduce it with simpler examples. The only place it fails is in the actual application.

So, PaulH, why does your test work, why does Adam's test work, why do my tests work, and yet the IDENTICAL code in the actual application fails?!?!?

Clearly my attempts to reproduce the problem is on the same version of CF8 where it is not working in this SPECIFIC case!

You stated before that this is because it doesn't work inside a tag library. I'm on vacation right now so can't test this, but it strikes me as extremely bad policy to have code that works in testing and then fails as soon as you move it into a generally useable tag library!

If, on the other hand, the test you performed was from inside a tag library, then it SHOULD work in a tag library! Then there is something else that is modifying the context of the code and causing it to fail. I can't concieve or what this might be!

Can you?

In this case, it is probably a bug that either Adobe knows about and can explain, or doesn't and someone (me, probably) will have to keep working on to reproduce in an example that can be reported.

My problem is that if it intentionally doesn't work in a tag library, how do I maintain the code so that almost 300 web sites can use it without copying it to all 300 sites with the nightmare THAT would be: that is CLEARLY a violation of one of the major reasons for even using tag libraries in the first place!

Report · Dec 27, 2008

Al Baker wrote:
> So, PaulH, why does your test work, why does Adam's test work, why do my tests
> work, and yet the IDENTICAL code in the actual application fails?!?!?

because they're not identical. you maybe have a cfsetting, etc misplaced/not
closed or you're actually using it inside a cftag lib as the docs state. you
said your code produced that output. it doesn't on my server.

> Clearly my attempts to reproduce the problem is on the same version of CF8
> where it is not working in this SPECIFIC case!

no, nothing you've shown is "clear" as to the cause or it being a bug.

> You stated before that this is because it doesn't work inside a tag library.

yes, you said it didn't work & all i did was read the docs to see if there was
an answer. when i actually tested your example, it worked as it was supposed to.

> bad policy to have code that works in testing and then fails as soon as you
> move it into a generally useable tag library!

it doesn't fail. your app fails, that's not the same thing.

> In this case, it is probably a bug that either Adobe knows about and can
> explain, or doesn't and someone (me, probably) will have to keep working on to
> reproduce in an example that can be reported.

two people can't reproduce what you called a bug using your code. while you can
raise a bug w/adobe, i wouldn't bother until you can come up w/a case that can
be reproduced.

Report · Dec 27, 2008

PaulH,

Thank you. You make excellent points. I thought your test was by placing the code in a tag library and it worked. If that is not the case and the documentation is correct: that it does NOT work in a tag library, then there is no need to determine if this is a bug. It is defined as not working in that case!

Then my problem is different: How do I support a single piece of code being used by just under 300 independent domains (and growing!) without using a tag library?

But doesn't that still make you wonder why they would intentionally make the identical code behave correctly when used by a single application but not when it is to be used by a large number from a tag library? It seems that if there is anyplace you would want your code to be non-gassy and most efficient in HTML generation that would be IN tag libraries!

Report · Dec 27, 2008

> If you read my initial posting, the code works when I try to reproduce it with
> simpler examples. The only place it fails is in the actual application.

Well, here's the thing. I *did* read your initial post, and your initial
post says this:

"I have the following code buried deeply in our application. I've tried to
reproduce a simpler example without success. This example clearly fails."

Well: no. That example clearly works. Which - I think - is what Paul and
I were saying.

If this stuff only doesn't work when it's within some other code that you
didn't post, I think what we've demonstrated here is that there's nothing
wrong with the CF functionality, it's how your using it. However it's hard
to say, given - as you point out - you're not actually posting the code
that doesn't work.

> So, PaulH, why does your test work, why does Adam's test work, why do my tests
> work, and yet the IDENTICAL code in the actual application fails?!?!?

Applying Occam's Razor to this would have me thinking the cause of the
problem is not what you think it is.

It might help if you post the code that's not working. Rather than an
approximation of the code, wherein the approximation actually *is* working.

That said, I'm about to disappear up to the arse end of Scotland for a
quiet week out in the wilderness, and what little online access I shall
have will not be dedicated to these forums, so - if you post some code that
is more representative of your actual problem - I probably won't get a
chance to eyeball it until Jan 5 or so. But I'm sure Paul will sort you
out.

--
Adam

Report · Dec 27, 2008

Adam,

Everything you are saying is exactly correct. That is why I suspect the "tag library" answer is unfortunately the correct one. Both the cfsetting and cfprocessing directive tags are defined such that a "yes" overrides any number of previous "no"s! Thus, as far as those directives are concerned, no outside state would (should) impact them, by definition! In fact they are defined such that for "ENABLECFOUTPUTONLY='yes'", the only thing that would permit output is being contained inside "cfoutput" tags, (either inside or outside the scope of the cfsetting tags, doesn't matter which). Given the display of #i# instead of a number, no cfoutput tags are operational, so no display should exist.

Thus the only thing that makes sense is PaulH's statement that the tags are defined not to work inside tag libraries.

A] If they DO work inside a tag library (which I will test when I get back to my office in a few days), then there is nothing that is documented that states that the code I presented should not work regardless of what is "surrounding" it! The bug is either there or the external scope that overrides the tags isn't documented!

B] If they DON'T work inside a tag library as PaulH states, then I need to know how to reference a single piece of code from almost 300 different domains without using a tag library!

(And, completely unrelated to this entire conversation, if is true, then I personally believe that such behavior is a bug that was documented as how it works instead of fixing it: I can't see why putting code into a tag library and thus breaking it would be considered "ok"-- but that's just me.)

If It does work in the tag library I will continue to try to reproduce the problem so that it can be written up wither as a bug or as documentation as to what undocumented external circumstances prevent a simple cfloop from behaving properly inside the two tags.

Report · Jan 02, 2009

I found the BUG in <CFSETTING ENABLECFOUTPUTONLY="yes">!!

<cfoutput> does not propagate to the code inside a <cfinclude> (thank goodness).

However, <CFSETTING ENABLECFOUTPUTONLY="yes"> thinks they do!

To demonstrate exactly how insidious this is, I have created three simple files to demonstrate the bug. This shows that "cleaning up" the <cfoutput> before a single <cfinclude> doesn't work. The middle file, "testinc.cfm" carefully does not surround the important <cfinclude> with <cfoutput>, but this is not enough! You would have to find EVERY occurrence and clean them all up, even inside modules you may not control, to get around the bug!!!

test.cfm:
------------------------
<cfoutput>
Works: 
</cfoutput>
<cfinclude template="testinc.cfm"> 
<cfoutput>
 
Fails: 
<cfinclude template="testinc.cfm"> 
</cfoutput>
------------------------

testinc.cfm:
-----------------------
<cfoutput>code </cfoutput>
<cfinclude template="testinc2.cfm">
-----------------------

testinc2.cfm:
-----------------------
<cfset NoCfoutput="YesCfoutput">Before:#NoCfoutput# <CFSETTING ENABLECFOUTPUTONLY="yes">
**** BEGIN INSIDE ENABLECFOUTPUTONLY="yes" **** 
Variable NoCfoutput is #NoCfoutput# 
**** END INSIDE ENABLECFOUTPUTONLY="yes" **** 
<CFSETTING ENABLECFOUTPUTONLY="no">After:#NoCfoutput# 
-----------------------

Report · Jan 05, 2009

> I found the BUG in <CFSETTING ENABLECFOUTPUTONLY="yes">!!
>
> <cfoutput> does not propagate to the code inside a <cfinclude> (thank
> goodness).
>
> However, <CFSETTING ENABLECFOUTPUTONLY="yes"> thinks they do!
>
> To demonstrate exactly how insidious this is, I have created three simple
> files to demonstrate the bug.

Well done for getting some code to reproduce here, and - yeah - I'm seeing
the same behaviour you are.

Have you raised a bug with Adobe?

I'm not sure there's much one can do here other than - as you suggest - be
judicious with one's usage of <cfoutpu> tags (which doesn't help too much
with existing code).

--
Adam

Report · Jan 05, 2009

I'm not exactly sure how to submit a bug to adobe. I'll need to determine how to do that.

Also, there is a problem with fixing this in a general way: a lot of web sites might break if code that thinks <CFSETTING ENABLECFOUTPUTONLY="yes"> is working are unintentionally relying on data being generated outside <cfoutput> pairs!!!!

I, for one, would not want to install a patch to ColdFusion that fixed this bug even though I desperately need it fixed!

Instead, I think the behaviour should be documented and a separate value or parameter be used to control what should have been the correct behavior originally, such as:

<CFSETTING ENABLECFOUTPUTONLY="local">

or

<CFSETTING ENABLECFOUTPUTONLY="yes" GLOBALCFOUTPUT="no">

(Both are cumbersome and something beside "local" could be used, but this is safer than a general fix.)

Report · Jan 05, 2009

> I'm not exactly sure how to submit a bug to adobe. I'll need to determine how
> to do that.

http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

I half-way agree with the rest of what you say. However all you can do is
bring it to their attention and see what they decide.

The alpha for CF9 is on at present, so it's a suitable time for it to be
put on the radar.

--
Adam

Report · Jan 05, 2009

Thank you,

I've submitted the bug along with my concern about a general fix.

Adobe Community

Failure with cfsetting and cfprocessingdirective?

1 Correct answer