Creating Globally Accessible User Defined Functions In ColdFusion (Safer Version)

Wouldn't the request scope be safer to shove this into?

Understood. If I shoved a include() UDF into the url scope, all it takes is for the user (or an unaware developer) to type &include=whatever and your website is borked.

In the end, I don't think trying to get around having to type {scope.}functionName() is necessarily safe(r). :) I guess I'd rather just shove into the request scope per-request and then in the CFC, pull it back out of the request scope and perhaps into a private function.

I concur. Wouldn't surprise me to see it somewhere else in the future.

What I like about Railo's method is that it is completely sandboxed. Host A's tags & functions libraries never cross/conflict with Host B's libraries unless they're put into the global server folders. It's the same way for the virtual file system too and pretty much everything else (datasources, etc).

Using the $functionName() would definitely be safe(r) than not using it, but it is definitely security by obscurity / obfuscation.

I usually use the application scope for UDFs and load them onApplicationStart. The call is a bit longer (application.udf.getMessage() with my setup), but it seems to me a more logical choice than the url or request scope (UDFs are not request specific).

Jean

Thanks for thinking outside the box. I like this.

All right, all right, point taken :-)

"All to say, we really need a native way to do this (ala Railo)"

FWIW, at one time Adobe listed a feature of CF10 (codename Link) as "Pluggable Architecture".

http://www.codersrevolution.com/index.cfm/2008/9/17/A-Look-Into-ColdFusions-Future-Centaur-Sully-Link

Sadly though, the latest version of that piece of marking no longer includes the "Pluggable Architecture" part.

http://www.codersrevolution.com/index.cfm/2009/10/24/A-Look-Into-ColdFusions-Future-Again-Sully-Link-Storm

Ben, awesome posts.

I lobbied my ass off to get this capability into CF9, even suggesting solutions as cheap as letting you add application and request to the unscoped variable wiring queue on a per-application ( application.cfc setting ) or per-instance basis ( administrator option ).

But, mostly because of some oldschooler CFers tantrumming "how will people ever figure out where those functions are! It'll be a debugging nightmare!!!! People will get confused and overdose on narcotics!!", not enough people got behind it.

So sadly, I end up injecting all of my languagey functions( which in my mind are just extensions and enhancements of CFML ) into the application scope onAppStart and calling them with a global shorthand like this: app.getSentences( string, 2 ) or app.stripHTML( string )

It's the closest you can get to the native CF euphoria you're going for here without Railo, or at least I thought it was before I saw your post leading up to this ( I wonder if there's a getApplicationContext or anything similar to get to one of the persistent scopes! ).

The one thing that will probably stop me from using that approach in production though is the performance overhead of doing all of that work on every request. But it was an effing sweet experiment. Thanks for the knowledge.

Just set up your utility methods/functions in an application-scoped singleton as David suggests, then loop over the collection of functions at the top of your onRequest, assigning each to a same-named alias in the variables (or unnamed) scope. You can even programmatically disambiguate the function names (or add a unique prefix like an underscore) if you're worried about collisions.

So now app.util.kick(type='crescent') can be called on the page as the ersatz-native function kick(type='crescent') or _kick(). Calls will be by reference to the original functions in the application-scoped utility cfc.

Good point -- structappend() is even better, assuming you don't need to inspect the function names individually. And I suppose it's unlikely you would, unless you're in some highly dynamic or unpredictable context (e.g., you're writing a framework or plug-in that could be used across multiple CFML engines with differing native function lists).

I'm still not sure about the url scope versus variables/unnamed. If we're working in onrequest(start), either is an option. I think variables is checked earlier in the scope walking sequence, for what that's worth. The use of either could still result in variables being stepped on at page execution...

"create a base Component that all of the other CFC's extend"

ColdFusion already has a base component that all components extend. Its called located here: WEB-INF/cftags/component.cfc :)

So, how about having any page/component/udf declare that it intends to use global udfs go get the global udfs into the unnamed scope?

Here is some code that I use for what Ken talked about ("Just set up your utility methods/functions in an application-scoped singleton...")

1) In application.cfc cfinclude the function library (which isn't a component, just a file containing cffunction tags). Could rework to be a component if you insist.

2) Put this function in application.cfc (or in the cfincluded file in #1:

<cffunction name="registerglobalmethods" output="no">

<cfscript>

keys = structkeylist(application.globalmethods);

for (i=1; i LTE listlen(keys); i=i+1) {

key = listgetat(keys,i);

evaluate(key & " = structfind(application.globalmethods, """ & key & """)");

}

</cfscript>

</cffunction>

3) Put this onApplicationStart:

application.globalmethods = structnew();

keys = structkeylist(this);

for (i=1; i LTE listlen(keys); i=i+1) {

key = listgetat(keys,i);

if (iscustomfunction(this[key]) and left(lcase(key),2) NEQ "on") // hide application methods

structinsert(application.globalmethods, key, this[key]);

}

application.registerglobalmethods = this.registerglobalmethods;

4) Whenever a page/cfc/udf wants to use global functions, first do: application.registerglobalmethods();

@Ben Nadel,

It's really just a (manual, late/runtime) pseudo-inheritance of a base class! Har har har....

It is a bummer that those functions become public functions of the component. Can't think of any way to make them private.

Very strange thing happened as I was tinkering:

I changed registerglobalmethods() to take take a parameter and to use implicit dynamic evaluation instead of the call to evaluate() (and I forgot to use the var statements). Here is out it looks now:

<cffunction name="registerglobalmethods" output="no">

<cfargument name="scope" required="false" default="variables"/>

<cfscript>

var key = ""; var i=1;

var keys = structkeylist(application.globalmethods);

for (i=1; i LTE listlen(keys); i=i+1) {

key = listgetat(keys,i);

"#scope#.#key#" = structfind(application.globalmethods, "#key#");

}

</cfscript>

</cffunction>

Now I cand call this from my page component with this:

application.registerglobalmethods("this");

I can get the functions into whatever scope I want. If I call it with "this", things work as I expect. The strange part is, if I call it with argument as "variables", the function pointers are declared in the unnamed scope, but they are still public! They don't show in cfdump of the cfc, but the page that instantiated the cfc can call just fine one of my global functions: sanitize() as mycfc.sanitize("test") !!

Can you shed some light as to why it is that in this case, the unnamed or variables scoped variables are available to the caller of the cfc that called this register function?

From the CF docs:

"The Variables scope

The Variables scope in a CFC is private to the CFC. ... You set a Variables scope variable by assigning a value to a name that has the Variables prefix or no prefix."

Shouldn't that mean the variables registerglobalmethods creates would be private? I don't understand why the global sanitize function, registered inside mycfc with my registerglobalmethods("variables") is callable by my page component that instantiated mycfc as mycfc.sanitize("test").

Sean

@Ben,

All right. Your idea worked splendidly! Now the API of the cfc is not changed using this scheme. Also, I stopped the loop-on-structkeys silliness and just used structappend.

Here is the whole package:

[Put in application.cfc:]

<cffunction name="onApplicationStart">

. . . snip . . .

<cfscript>
application.globalmethods = structnew();
keys = structkeylist(this);
for (i=1; i LTE listlen(keys); i=i+1) {
key = listgetat(keys,i);
if (iscustomfunction(this[key]) and left(lcase(key),2) NEQ "on")
structinsert(application.globalmethods, key, this[key]);
}
application.registerglobalmethods = this.registerglobalmethods;

</cfscript>

. . . snip . . .

</cffunction>

<cfinclude template="GlobalFunctions.cfm">

<cffunction name="registerglobalmethods" output="no">
<cfset StructAppend(variables, application.globalmethods, true)>
</cffunction>

Finally, in any cfc that uses a global function, call the register function:

<cfset application.registerglobalmethods();>

Now, you could skip the register function and just use:

<cfset StructAppend(variables, application.globalmethods, true)>

when ever a cfc needed to use global functions. But I think this is more readable.

Sean

Sean Corfield over at Mere Mortals offered a cleaner method for the code:

http://stannard.net.au/blog/index.cfm/2008/5/9/Using-Constants-in-ColdFusion-Components#c7E7025A1-3048-2D64-FCB1288CFBE390B4

application.globalmethods = structnew();
for (key in this) {
if (iscustomfunction(this[key]) and left(lcase(key),2) NEQ "on")
structinsert(application.globalmethods, key, this[key]);
}

The code skips the registration of any application scope methods (methods defined in application.cfc) that are the CF application control methods:

onApplicationStart()
onRequestStart()
onSessionStart()
onError()
onApplicationEnd()

I just did that to cut down clutter. It's doubtful any page would want to call these methods (I'm assuming you have a url.reinit like block in onRequestStart to restart the app).

If you just had to have a custom global method that began with "on", like maybe onFormPost(), then you'd want to cut out of the code the left check:

left(lcase(key),2) NEQ "on"

Sean

I was wondering why you did not use the CGI scope instead of URL, now I know.

@Ben,

you are right, unfortunately altering CGI scope is impossible. i learn something new every day :)

i ended up using the url scope as you suggested, but i fear as the UDF library grows, that name collision will create errors which are hard to debug (i already had my share of debuging errors coming from coldfusion trying to validate form variables based on their name, i think the field was called location_required).

Ben,
I'm not clear with the code: application.cfc.test()
In here I think test() refers to a function name? but on the other hand, this code indicates that test is a component name not a function's name:
<cfset application.cfc = createObject( "component", "Test" ) />

If I go back to your explanation codes, where the name of global UDF is UDF.cfc and in Application.cfc you are setting it as:
<cfset structAppend(url, createObject( "component", "UDF" ) ) />

Than how can I call getMessage function and passing parameters?
Is it:
<CFSET application.cfc.UDF.getMessage(parameter1,parameter2)? ?