Ask a Jedi: cfinvoke and createObject
Gary sent in a question I've dealt with in the past, but I hear it brought up multiple times so I thought I'd share my response here. First, Gary's question:
Simply asked, given the two examples below, how are these two methods different and what are the pros and cons of each. I'm leaning towards 'why is the creatobj method preferred?' This all goes to having a better understanding of OOP.<cfset application.blog = createObject("component","org.camden.blog.blog").init(blogname)>
<cfinvoke component="org.camden.blog.blog" method="init" returnvariable="application.blog">
<cfinvokeargument name="name" value="#blogname#">
</cfinvoke>
There are few different ways to answer this. First off - the result of both these code blocks is the exact same. They both call the init method on a CFC named blog, pass in a variable, and assign the result to a variable named application.blog. So if you consider the results - they are the same.
Technically of course they are different. One uses createObject and one uses cfinvoke. Under the hood, I'd be willing to bet they compile down to pretty much the same code.
So which is better?
The createObject method is typically what is used by most developers. I'm not sure I'd call it a "standard" but I think you would see that in code more often than the cfinvoke version.
The cfinvoke method has the benefit of working on hosts, like GoDaddy, that block access to createObject.
What do I do? When creating an instance of an object using the init method, I'll always use createObject. When calling a method on a CFC, I'll use simple script format (foo = mycfc.goo()) unless my arguments have complete logic in them. If they do - I'll use cfinvoke since you can conditionally include arguments. Here is an example:
<cfinvoke component="#application.blog#" method="goo">
<cfif hour(now()) lt 10>
<cfinvokeargument name="morningmode" value="true">
</cfif>
<cfinvokeargument name="name" value="dharma">
</cfinvoke>
Comments
As to your second point - I'm not sure what you mean.
So now I'm reading about createObject and I find the entry dated April 5, 2006, Ask a Jedi: cfinvoke versus createObject (http://ray.camdenfamily.com/index.cfm/2006/4/5/Ask...) and the fifth comment mentions that someone changed BlogCFC so it could work on a host that does not allow createObject().
And of course even more information on cfinvoke vs createObject. And now to my point. I always read Ray's and Sean's blog on a daily basis because at any given point they have the answers to most of the asked questions. Together, these two blogs have such a wealth of information from themselves and the hundreds of other programmers that leave comments.
To Ray and Sean and the entire CF community, I say Thank You. The time you spend on your respective blogs is well spent.
<cfcomponent>
<cffunction name="f">
<cfreturn "first one">
</cffunction>
<cffunction name="g">
<cfreturn "second one">
</cffunction>
</cfcomponent>
<!--- caller.cfm --->
<cfset o = createObject("component", "c")>
<cfset dynamicMethod = o["f"]>
<cfoutput>#dynamicMethod()#<br /></cfoutput>
<cfset dynamicMethod = o["g"]>
<cfoutput>#dynamicMethod()#<br /></cfoutput>
eg
<cfscript>
user = createObject("component","cfc.user");
user.setFName("Rahul");
user.setLName("Narula");
user.age("31");
</cfscript>
Quickly we can see that all operations are done on single object.
Also the object ref is easier using this approach.
<cfscript>
args = StructNew();
if (hasField1) args.field1 = "some text";
if (hasField2) args.field2 = "true";
myObj = CreateObject("component","cfcs.util").init(argumentCollection=args);
</cfscript>
You can still save objects for referencing later using cfinvoke:
<cfinvoke component="basecamp" method="init" returnvariable="APPLICATION.cfc.basecamp">
<cfinvokeargument name="basecampdomain" value="http://gaylordhotels.projectpath.com">;
<cfinvokeargument name="username" value="ioweray>
<cfinvokeargument name="password" value="awishlistitem>
</cfinvoke>
then:
<cfscript>
myvar = APPLICATION.cfc.basecamp.someMethod();
</cfscript>
Creating the object and keeping it to reuse it for different methods in different sections of the application (if scoped) would definitely save the instantiation and initlalization time.
Aren't there also edge cases where createObject won't work - you've mentioned those before I swear (I think it was in one of the Friday puzzlers?)