Hmmm.... another case of not having read the documentation.

From the documentation for the CFSETTING tag:

If you nest cfsetting tags: to make HTML output visible, you must match each enableCFoutputOnly = "Yes" statement with an enableCFoutputOnly = "No" statement. For example, after five enableCFoutputOnly = "Yes" statements, to enable HTML output, you must have five corresponding enableCFoutputOnly = "No" statements.

That explains why I'd been finding cfsetting "unreliable" for the purpose of setting the EnableCFOutputOnly flag, because I'd always assumed it was just an on/off thing. It also means I'll have to go back through the framework and find the places where I've used it, for example, the cf_html tag now automatically un-sets the EnableCFOutputOnly flag to eliminate the need to nest cfoutput tags in every cf_html instance, even when no variables are being used, which is something I used to do to ensure that the code wouldn't break if someone put cfoutputonly in their applicatin / onRequestStart. I'm pretty certain this will result in a new function:

<cffunction name="EnableOutputOnly" output="false" returntype="numeric">
<cfargument name="enable" type="boolean" required="false" default="true" />
<cfargument name="repeat" type="numeric" required="false" default="1" />

<cfif enable>

<cfloop index="repeat" from="#repeat#" to="1" step="-1">
<cfsetting enablecfoutputonly="true" />

<cfreturn 0 />
<cfset repeat = -1 />
<cfset enable = true />

<cfloop condition="enable">

<cfset repeat = repeat + 1 />
<cfsavecontent variable="enable">false</cfsavecontent>
<cfset enable = len(enable) />


<cfreturn repeat />

update: (later the same day) -- yeah, I saw this coming... it can't be a function, because it starts a new output buffer when it enters the function, which circumvents the enablecfoutputonly setting. So I just uploaded a new build with a custom tag that does this instead.

BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress