If you invoke a component function by using the CFINVOKE tag, ColdFusion creates an instance of that component and calls the function named in the Method attribute. In essence, ColdFusion instantiates an object of the class of that component, but the name of that object is invisible to you. (It’s internally referenced by ColdFusion Server.) If you use CFINVOKE to call three of a component’s functions in a single ColdFusion template, as shown in the code, ColdFusion Server creates three separate instances of that component to give you what you want, and that’s not very efficient.

<cfinvoke
   component=”Company”
   method=”GetCompany”
   returnvariable=”companyRecord1”>
   <cfinvokeargument name=”CompanyID” value=”8”>
   </cfinvoke>
   <cfinvoke
   component=”Company”
   method=”GetCompany”
   returnvariable=”companyRecord2”>
   <cfinvokeargument name=”CompanyID” value=”9”>
   </cfinvoke>
   <cfinvoke
   component=”Company”
   method=”GetCompany”
   returnvariable=”companyRecord3”>
   <cfinvokeargument name=”CompanyID” value=”10”>
 </cfinvoke>

The correct way to call a component’s functions multiple times from a single template is to separately instantiate an object with a formal name and then call the functions of that one instance as you need them. The code shows this principle in action. Notice that the component attribute of the CFINVOKE tag references an instance of the component rather than the component itself.

<cfobject name=”myCompany” component=”Company”>
   <cfinvoke
   component=”#myCompany#”
   method=”GetCompany”
 returnvariable=”companyRecord1”>

<cfinvokeargument name=”CompanyID” value=”8”>
   </cfinvoke>
   <cfinvoke
   component=”#myCompany#”
   method=”GetCompany”
   returnvariable=”companyRecord2”>
   <cfinvokeargument name=”CompanyID” value=”9”>
   </cfinvoke>
   <cfinvoke
   component=”#myCompany#”
   method=”GetCompany”
   returnvariable=”companyRecord3”>
   <cfinvokeargument name=”CompanyID” value=”10”>
 </cfinvoke>

You create a single instance of the Company component that persists for as long as the current page request lasts; then you simply call the functions of that one instance as many times as you need. After the current page request ends, ColdFusion automatically destroys the instance that you create. (In the following part, you learn how to make your component instances live longer.) Using the CFOBJECT tag isn’t the only way to instantiate an object. The CreateObject() function returns an object as well. The following three lines of code, for example, produce the same results:

<cfobject name=”myCompany” component=”Company”>
   <cfset myCompany = CreateObject(“Component”, “Company”)>
 <cfscript>myCompany = CreateObject(“Component”, “Company”);</cfscript>

Similarly, using CFINVOKE isn’t the only way to invoke a component function. After you create an instance of a component, you can call its methods by using simple dot notation. The code, for example, returns the list of companies produced by the ListCompanies function to a variable named listOfCompanies.

<cfscript>
   myCompany = CreateObject(“Component”, “Company”);
   listOfCompanies = myCompany.ListCompanies(‘A’);
   </cfscript>
 <cfdump var=”#listOfCompanies#”>

In fact, the code is probably the most popular way of working with component functions for ColdFusion developers who are versed in object-oriented languages, as the syntax is very close to the way that both Java and C++ instantiate objects and call their methods. You can directly access component functions via forms and URLs, but the results are basically worthless. Instead of defining a return value to pass from your function to the function call that invokes it, you must push displayable content directly out of the body of the function, as shown in the code.

<cffunction name=”OutputTest” output=”yes”>
   <cfquery name=”companyRecs” datasource=”#Request.MainDSN#”>
   SELECT
   CompanyID,
   CompanyName,
   Address,
   City,
   State,
   ZipCode,
   Comments
   FROM
   Company
   ORDER BY
   CompanyName
   </cfquery>
   <cfoutput query=”companyRecs”>
   <p><b>#CompanyName#</b>:<br>#Comments#</p>
   </cfoutput>
 </cffunction>

This kind of coding is nasty stuff, folks. Don’t do it. The real power of content-producing functions, whether they are local to a template or encapsulated within a component, comes from returning content contained in a complex variable of a specific data type and then merging the content with presentation code. Separating logic from presentation (and, by extension, data from presentation) should be your mantra. If you absolutely must create a function that directly outputs content, remove the ReturnType attribute from the CFFUNCTION tag and add Output=”Yes”. Never have both a return type and direct output in the same function. The Output attribute actually has the following three states:

Output=”Yes” treats the entire function as if it were inside a CFOUTPUT tag pair.

Output=”No” treats the entire function as if it were inside a CFSILENT tag pair.

Eliminating the Output attribute entirely enables explicit CFOUTPUT tags inside the function to leak output to the caller.

We haven’t been explicit about the Output attribute yet because this is a learning article, and we want to eliminate as much extraneous code as possible so that you can focus your concentration on specific topics. In the preceding parts of this article, you learn how to create a named instance of a component, you find out about the basics of instance properties in a component’s This scope, and you learn the differences between class methods and instance methods. Now to put these theories into action! The instance of the component that you create in the code persists only as long as the page request and then ColdFusion Server automatically destroys it. If you want to work with a persistent component past a single page request, you simply must create it in a persistent scope that lives longer than one request, as shown in the code.

<cfscript>
   Session.myCompany = CreateObject(“Component”, “Company”);
   listOfCompanies = Session.myCompany.ListCompanies(‘A’);
   </cfscript>
 <cfdump var=”#listOfCompanies#”>

Now this instance persists as long as the user’s session does, which means that its properties do, too. This means that you can execute one ColdFusion template that creates an instance of the Company component, go have a cup of coffee, execute a second ColdFusion template that invokes a function of that component, go place a bid on eBay, execute a third ColdFusion template that invokes another function of that component, and so on, until you pause longer than your session timeout permits and the instance is destroyed. This is why we refer to Company as a long-lived persistent component. Components can also be persisted in the Application scope as well. Just remember that all users of your application use the same instance of your component, so locking becomes even more critical and performance bottlenecks potentially become more of a concern if your component manipulates properties in its This scope. We bet that, right now, you’re thinking, “I’m clustering my application, which means that I don’t use Session variables anywhere, so I’m going to persist my component instance by serializing it with WDDX and storing it in the Client scope.” That’s a clever idea, but unfortunately, it doesn’t work. If you serialize a component instance, the properties in the This scope serialize just fine, but you lose all your functions, so on deserialization, all you get back are the properties.