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

Posted March 1, 2007 at 2:18 PM by Ben Nadel

Tags: ColdFusion

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.

Post A Comment

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.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment