Failure with cfsetting and cfprocessingdirective?

Thank you,

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

> 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

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

> 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

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.

> 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

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!

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.

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!