How Do I Get A Pointer To A Built In ColdFusion Method?
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?
Want to use code from this post? Check out the license.
Reader Comments
You might just wrap them, if nothing else comes up.
Try this.
if StructKeyExists( component, methodname )
@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.
How about an evaluate? This works:
<cfset Method = "FindNoCase" />
<cfset x = evaluate("#Method#('foo', 'I like foo bar')") />
<cfoutput>#x#</cfoutput>
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.
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
@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.
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
@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.
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
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.
Ben,
I'm interested to know what other languges you've done this in?
D
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
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.
Ben,
Although I am not sure but this method could help you locating builtin functions
getFunctionList().
Thanks
@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.
Sorry not to be in English.
But my two cents.
http://pcsilva.blogspot.com/2007/03/onde-est-funo-mais-uma-que-compartilho.html
@Pedro,
That looks very interesting. I have never invoked a method indirectly like that. I will play around.
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
Hmm, I have never seen those methods, hidden or otherwise. I just tried to do a GetMetaData() on them and got undefined errors.
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
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.
I believe that they can yes, the classes are different.
coldfusion.runtime.CfJspPage._invoke(...)
coldfusion.runtime.TemplateProxyFactory.resolveName()
http://www.mxstudio.com.br/views.tutorial.php?act=view&cid=7&aid=699
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>
Hmmm, very interesting. I will have to study this.