Coding for both engines, cannot CFIF around an unsupported tag

It’s understandable that this line in my CFC file will not run in Lucee:

<cfreport template="myReport.cfr" query="myData" format="PDF" filename="myFile.pdf">

Even when I attempt to load the wsdl breakdown, I will get the following message:
“the tag [cfreport] is not implemented yet.”

As already done with so much code in our application, such differences have been handled with something like this:

<cfif uCase(server.coldfusion.productName) eq "LUCEE">
     <!--- do some Lucee version --->
<cfelse>
     <cfreport template="myReport.cfr" query="myData" format="PDF" filename="myFile.pdf">
</cfif>

But this does not stop the compilation error. Lucee will not let me run this cfc, even though Lucee will never be asked to run that line.

I know the tag is not supported in Lucee, but it is supported in ACF - and this file may be running in one engine or the other.

So what cfsetting or admin switch can I use to get something like this to work?

Thanks!

Others may have better thoughts, but I have something that could work for you:

put the incompatible code in a file that you cfinclude within that condition

That’s not always the best solution. Let me elaborate.

First, it’s worth nothing that the problem here is not unique to Lucee: it could happen with different cf versions, where one would support some tag or function that another version does not. And for those situations, where I had code that needed to run in both, I solved it this way. And I’ve confirmed that the approach works in Lucee also.

The issue you hit is that the compiler (of cfml to Java) does not RUN your code, so it does not know that the code is within a conditional statement, as you’d expected. But the INCLUDE is NOT a compile-time directive: it’s a RUNTIME directive. And so that include will NOT be executed unless the condition is true, and only then is the code within the include processed. Simple solution, though not obvious. :slight_smile:

Let us know if it works for you. And I’ll let others share thoughts on when this approach has proven NOT to be suitable.

2 Likes

Thanks @carehart! I do have some rudimentary grasp of compiler errors vs runtime errors. I was hoping that there might be some directive setting or compiler switch, telling it to ignore or catch what is essentially a warning message (that “we know this won’t run”). Sometimes there can be rare, undocumented stuff in there :wink:

Yes, I will follow the <cfinclude> solution - although it’s remotely possible that the client might abandon the ACF-to-Lucee path once they realize that 70+ of their legacy <cfreport> definition files will become worthless. This code gimmick is so they can have it both ways for a little while, as I’m suggesting they rework all the reports anyway, I suspect cfr’s days are numbered.

1 Like