Hi everyone I have found that I often have to use:

<cfinclude />

When creating cross cfml engine [ACF/Lucee] compatible code. For instance, if you do something like this, you will get a compilation error:

function GetFrameworksByParam() {
        
        var local = {};
        
        local.frameworkbyparam = {
            var1 = "hello world"
        };

        local.szResponse = {};

        if(server.keyExists( 'lucee' )){
            local.serializeParam_lucee_object = local.frameworkbyparam;
            local.serializeResponse_lucee = Serialize(local.serializeParam_lucee_object);
            local.szResponse = local.serializeResponse_lucee;
        }
        else{
            local.serializeParam_acf_object = local.frameworkbyparam;
            local.serializeParam_acf_type = "xml";
            local.szResponse = Serialize(local.serializeParam_acf_object, local.serializeParam_acf_type);
        }
        
        
        WriteDump(var=local.szResponse);
}

GetFrameworksByParam();

The error occurs because of there are differences between the amount of params that the native method:

Serialize()

Can accept. In ACF, it is two params, whereas in Lucee, it is just one param. Differences in param names, if the params are named within the method call, also cause errors. The compiler checks code in every conditional branch. But, if you hide the code in an include, there is no error:

function GetFrameworksByParam() {
        
        var local = {};
        
        local.frameworkbyparam = {
            var1 = "hello world"
        };

        local.szResponse = {};

        if(server.keyExists( 'lucee' )){
            local.serializeParam_lucee_object = local.frameworkbyparam;
            include "includes/serialize-lucee.cfm";
            local.szResponse = local.serializeResponse_lucee;
        }
        else{
            local.serializeParam_acf_object = local.frameworkbyparam;
            local.serializeParam_acf_type = "xml";
            include "includes/serialize-acf.cfm";
            local.szResponse = local.serializeResponse_acf; 
        }
        
        
        WriteDump(var=local.szResponse);
}

GetFrameworksByParam();

includes/serialize-lucee.cfm

<cfset local.serializeResponse_lucee = Serialize(local.serializeParam_lucee_object) />

includes/serialize-acf.cfm

<cfset local.serializeResponse_acf = Serialize(local.serializeParam_acf_object, local.serializeParam_acf_type) />

Am I correct in thinking that CFML application servers don't check code within

cfinclude

, at compile time?

yep

Cheers for the confirmation...🙏

Railo/Lucee were not around, when Coldfusion was created, so it can't be a strategy for building cross compatible code. Why do CFML engines exhibit this behaviour?

that's just how parameter validation works, aside, i generally avoid using serialize and only use serializeJson

Wait a second. Are you saying that it is only method parameter validation, which is not carried out inside a

cfinclude

, by the compiler, but that the compiler does check other code constructs inside a

cfinclude

no\

So, essentially, it is like the 'wild west' inside a

cfinclude

😊

nope

I guess, runtime errors are still caught?

cfinclude is compiled on demand

OK. I see...

so in the good old early days of cfml, you could write extra dynamic code by writing out a template and including it

A template. being a view [HTML/CFML tags]?

a .cfm file

so in the good old early days of cfml

And you can't do that now?

why not? but the language evolved, so you didn't need to use that hack approach anymore

So are you saying: https://github.com/lucee/Lucee/blob/6.0/test/functions/ImageFormats.cfc#L29 Is a modern approach to circumventing the compilation error for method param differences? So this bypasses the compiler?

var imgFormats = evaluate("imageFormats( true )"); // v2, evaluate to bypass compile error with v1

well it works

So I could do:

local.szResponse = evaluate("Serialize(local.serializeParam_acf_object, local.serializeParam_acf_type)");

once a variable is created, the local scope is the immediate scope, so there's no need for the prefix

Do you know when this evaluate strategy started working? What version of ACF, roughly? Or has it been around since evaluate() was introduced?

but like with JS, you are better off using feature detection https://trycf.com/gist/fe5355de2a20b31f5ad2521f1c29e176/lucee5?theme=monokai

arrayLen(getFunctionData("serialize").arguments)

This is not how I would handle this, if I am reading things correctly. I would have something like this:

/shims/
    lucee/
        Shims.cfc
    CF/
        Shims.cfc

On lucee map

/shims

to

/shims/lucee

, and one CF map

/shims

to

/shims/CF

And in yer app use

Shims::serialize

@Charles Robertson This is exactly what ColdBox does in a few places (though I'd be more likely to use subclassing and method overrides rather than cfinclude). Note, sometimes you can work around this by using

attributeCollection

when it comes to tags with differing attributes per engine. https://github.com/coldbox-modules/s3sdk/blob/development/models/AmazonS3.cfc#L1410-L1413

Just out of interest, can you use argumentCollection with a native method? I know you can definitely use it for UDFs. This would also resolve the problem.

I would encourage you to report back what you find when you test that 🙂

nah, argumentCollection doesn't work with BIFs yet https://luceeserver.atlassian.net/browse/LDEV-18

I preferred Brad's answer to that question 😉

@zackster That’s great to know. Maybe, ACF will follow suit, one day 🤔