Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at cf.Objective() 2011 (Minneapolis, MN) with:

How Do I Get A Pointer To A Built In ColdFusion Method?

By Ben Nadel on
Tags: ColdFusion

Does anyone know how to get a pointer to a built in ColdFusion method? I want to do something along the lines of:

  • <!--- Check for regular expression search. --->
  • <cfif ARGUMENTS.IsRegex>
  •  
  • <!--- Get regex find. --->
  • <cfset Method = REFindNoCase />
  •  
  • <cfelse>
  •  
  • <!--- Get standard find. --->
  • <cfset Method = FindNoCase />
  •  
  • </cfif>
  •  
  • <!--- Use method pointer. --->
  • <cfif Method( "foo", "I like foo bar" )>
  • <!--- Code here. --->
  • </cfif>

The problem with this is that it throws an undefined variable error (FindNoCase). Now, I know the idea is sound as I have done it with user defined methods. But those methods are all scopes in some way and are very easy to reference. Built in ColdFusion methods are proving quite hard to find!

I tried all the different scopes and notations (array and structure):

  • <cftry>
  • <cfdump var="#FindNoCase#" />
  • <cfcatch>
  • "FindNoCase" failed.<br />
  • </cfcatch>
  • </cftry>
  •  
  • <cftry>
  • <cfdump var="#VARIABLES.FindNoCase#" />
  • <cfcatch>
  • "VARIABLES.FindNoCase" failed.<br />
  • </cfcatch>
  • </cftry>
  •  
  • <cftry>
  • <cfdump var="#VARIABLES[ 'FindNoCase' ]#" />
  • <cfcatch>
  • "VARIABLES[ 'FindNoCase' ]" failed.<br />
  • </cfcatch>
  • </cftry>
  •  
  • <cftry>
  • <cfdump var="#APPLICATION.FindNoCase#" />
  • <cfcatch>
  • "APPLICATION.FindNoCase" failed.<br />
  • </cfcatch>
  • </cftry>
  •  
  • <cftry>
  • <cfdump var="#APPLICATION[ 'FindNoCase' ]#" />
  • <cfcatch>
  • "APPLICATION[ 'FindNoCase' ]" failed.<br />
  • </cfcatch>
  • </cftry>
  •  
  • <cftry>
  • <cfdump var="#REQUEST.FindNoCase#" />
  • <cfcatch>
  • "REQUEST.FindNoCase" failed.<br />
  • </cfcatch>
  • </cftry>
  •  
  • <cftry>
  • <cfdump var="#REQUEST[ 'FindNoCase' ]#" />
  • <cfcatch>
  • "REQUEST[ 'FindNoCase' ]" failed.<br />
  • </cfcatch>
  • </cftry>

This gives me the following output:

"FindNoCase" failed.
"VARIABLES.FindNoCase" failed.
"VARIABLES[ 'FindNoCase' ]" failed.
"APPLICATION.FindNoCase" failed.
"APPLICATION[ 'FindNoCase' ]" failed.
"REQUEST.FindNoCase" failed.
"REQUEST[ 'FindNoCase' ]" failed.

Anyone know where I can find these method pointers?




Reader Comments

@Sam,

Yeah, I could work something out. For my directory search UDF, I ended up just putting both test cases into a single CFIF conditional.

@Dan,

The problem is that built in methods are not part of any component that I can check.

Reply to this Comment

How about an evaluate? This works:

<cfset Method = "FindNoCase" />
<cfset x = evaluate("#Method#('foo', 'I like foo bar')") />
<cfoutput>#x#</cfoutput>

Reply to this Comment

My java knowledge is almost non-existent. This may not help at all, but I figure it never hurts to share information.

I found a post about running your own Java libraries with coldfusion. In one of the comments, Mark mentions that his code supports access to built in classes and libraries, although I didn't see an example of that.

http://www.compoundtheory.com/?action=displayPost&ID=114

I played around with some of the code on the page. The code below displays the method names of something. Number 269 is FindNoCase with two parameters. Number 270 is FindNoCase with three parameters.

<!--- Do something? --->
<cfset cfClassLoader = getClass()>

<!--- Get the methods --->
<cfset var_getMethods = cfClassLoader.getMethods()>

<!--- Loop through the methods and display their names --->
<cfloop from="1" to="#arrayLen(var_getMethods)#" index="currentMethodIndex">
<cfoutput>
#currentMethodIndex# - #var_getMethods[currentMethodIndex].getName()#<br />
</cfoutput>
</cfloop>

I tried playing around with CFDUMP to equate a variable to a method but didn't have much success. Again, my Java knowledge is very limited.

Reply to this Comment

Although I think this is interesting I think maybe WHY!? is even more interesting.

I can't think of a case where this would be particularly useful? Maybe you could give a fuller example of what you're trying to do?

D

Reply to this Comment

@David,

Look at the example I gave. It checks a flag for regular expression usage and then uses either a REFind() or Find() method. This is actually the situation where this came up. REFind() and Find() have the same arguments, it should be very easy to swap them out.

Now, imagine if that was part of some HUGE CFIF statement. I wouldn't want to duplicate the logic depending on a flag.

Plus, this is mad elegant and sexy.

Reply to this Comment

Hi Ben,

Yes I get what you're trying to do but probably just disgaree on it's elegance factor.... (definitely on the mad factor tho! :p)

This situation sounds like it would fit the proxy(?) pattern nicely:

cffunction myFind(regEx, str, sub, ....)
cfif regEx
cfreturn refind()....
cfelse
cfreturn find()...
/cfif
/cffunction

Wouldn't that be a more elegant solution?

D

Reply to this Comment

@Dave,

I guess it's just a matter of opinion. Your solution, which is good, requires another UDF to be defined. Nothing wrong with that. But I just feel for something that should be really simple, having a proxy method ties the given UDF to more parts of an application that it needs to be.

But, in the end, your suggestion might just be the best idea.

Reply to this Comment

David,
In that situation, I don't think there is much difference between

if (condition)
return something
else
return something else

In fact, a lot of people are big fans of having a single point of return in a function, as it can make it easier to follow knowing there is only one place the function returns control to its calling code.

From that view, it would certainly be worse that doing something like

if(condition)
result=something
else
result=something else

return result

Reply to this Comment

With all that said though, I think I'd simply use the REFind if there was a chance of using regular expressions. After all, it's still a regular expression even if you don't use any special characters.

Reply to this Comment

Sam

I agree on the single return point. I was kinda just illustrating the point of abstracting the functionality into another function.

I agree on the just use reFind() although I imagine Ben was aware of that too. I think the question was more about can you do it the pointer way and/or is there a more elegant way (ans: probably not).

Without doing any tests I would also think that always using reFind() is faster than a function because it'd be another class to deal with.

D

Reply to this Comment

The problem with always using REFind() is that the string you are searching for might have "reg-ex" specific characters, so unless you want to escape all characters in the reg-ex substring, then no go.

Reply to this Comment

@Qasim,

Thanks for the suggestion. I talked to Michael Dinowitz yesterday at CFUNITED Express NYC and he said that this cannot be done (getting method pointers) for built in methods because the methods (as opposed to UDFs) are just wrappers for the Java methods. They are not really first class objects like UDFs.

Reply to this Comment

@Pedro,

That looks very interesting. I have never invoked a method indirectly like that. I will play around.

Reply to this Comment

Ben,
I tried to work with the functions undocumented _invoke and _invokeUDF, but did not discover which the first parameter.

<cfoutput>#_invoke()#</cfoutput>
<cfoutput>#_invokeUDF()#</cfoutput>

Regards

Reply to this Comment

Hmm, I have never seen those methods, hidden or otherwise. I just tried to do a GetMetaData() on them and got undefined errors.

Reply to this Comment

See Ben,
<cfdump var="#getpagecontext().getpage()#">

It looks for the methods initiated for _, you will see some (undocumented)

_invoke(java.lang.Object, java.lang.String, java.lang.Object[]):java.lang.Object

_invoke(java.lang.Object, java.lang.String, java.util.Map):java.lang.Object

_invokeUDF(java.lang.Object, java.lang.String, coldfusion.runtime.CFPage, java.util.Map):java.lang.Object

_invokeUDF(java.lang.Object, java.lang.String, coldfusion.runtime.CFPage, java.lang.Object[]):java.lang.Object

Reply to this Comment

Oh, I see. Yeah, those are some tricky methods. I think that is part of what the JavaProxy thing does - it figures out how to invoke those between CF and Java. I have heard that no one can figure out how to call the Invoke methods directly.

Reply to this Comment

It had reason how much to the direct access.

it does not work.
<cfscript>
pageContext=GetPageContext();
Object=pageContext.getClass().forName('coldfusion.runtime.TemplateProxyFactory').newInstance().resolveName('POIUtility', pageContext);

arg = ArrayNew(1);
Invoke = _invoke(Object,JavaCast('string','GetNewSheetStruct'),arg);
</cfscript>

it works

<cfscript>
pageContext=GetPageContext();
Object=pageContext.getClass().forName('coldfusion.runtime.TemplateProxyFactory').newInstance().resolveName('POIUtility', pageContext);

page = pageContext.getPage();
arg = ArrayNew(1);
Invoke = page._invoke(Object,JavaCast('string','GetNewSheetStruct'),arg);
</cfscript>

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.