Create a new CFC called contacts.cfc, and add your cfcomponent tags to define the component.

Add the following method in the contacts.cfc file. This new function runs a SELECT query on the Project Tracker application database to retrieve a recordset of all contacts:

<cffunction name="getContacts">
<cfset var rstContacts = "" />
<cfquery name="rstContacts" datasource="projectTracker">
SELECT firstName,lastName FROM Owners
</cfquery>
<cfreturn rstContacts />
</cffunction>

Listing 1.28

We now have a function returning our query data. We also want to have a query to pull out a specific record based on the record ID of a particular person.

We can create a second function to handle this as well:

<cffunction name="getContact">
<cfargument name="ID" type="numeric" />
<cfset var rstContact = "" />
<cfquery name="rstContact" datasource="projectTracker">
SELECT firstName,lastName FROM Owners WHERE ID = <cfqueryparam cfsqltype="cf_sql_integer" value="#arguments.ID#" />
</cfquery>
<cfreturn rstContact />
</cffunction>

Listing 1.29

These two methods within the contacts.cfc file interact with our database and return query data. However, the two queries pull out exactly the same information from the database. The only difference between the queries is that getContact() returns records for a specific user, based upon the ID value. We can easily streamline our CFC by combining these two methods into one, which will remove unnecessary code from our files and theoretically turn one function into two.

In this example, we will combine the two SELECT queries into one method, using the cfargument tag.

<cffunction name="getContact">
<cfargument name="ID" type="numeric" default="0" />
<cfset var rstContact = "" />
<cfquery name="rstContact" datasource="projectTracker">
SELECT firstName,lastName FROM Owners
<cfif arguments.ID GT 0>
WHERE ID = <cfqueryparam cfsqltype="cf_sql_integer" value="#arguments.ID#" />
</cfif>
</cfquery>
<cfreturn rstContact />
</cffunction>

Listing 1.30

The cfargument tag has a default attribute, which allows you to provide a default value for an argument if you do not pass one into the method. As the customer ID parameter type is set to "numeric", we have set the default value of the argument to "0". This value will now always be available within our method and will stay at the default value until a parameter is passed in to the function.

By providing a default value, we are now able to wrap a cfif tag block around the WHERE clause of the query. If the value of arguments.ID (the value of the parameter within the arguments scope) is greater than 0, that is, if we have passed a numeric value into the method ourselves, then include the WHERE clause when running the SQL within the cfquery tags.

By doing this, we have merged the two methods within the contacts.cfc into one, optimizing our code and allowing it to perform more than one function.

Let's run this query. Create a new page template called query.cfm, and paste in the following code to create the object and run the method without sending in any parameters:

<!--- instantiate the object --->
<cfset objContacts = createObject('component', 'contacts') />
<!--- dump the results --->
<cfdump var="#objContacts.getContact()#" />

Listing 1.31

If no ID value is sent through as a parameter, meaning the default value is 0, the method will return the full recordset of all content from the Owners database table:

Amend the code by adding in a numeric value to pass through as the ID argument:

<!--- dump the results --->
<cfdump var="#objContacts.getContact(2)#" />

Listing 1.32

If we provide an ID within the argument, the method will only return the row for the contact that has the matching ID value:

The dumped object now shows us the parameter sent through in the arguments scope and the SQL query that now includes the WHERE clause.

The simple solution of using an argument with a default value and a cfif statement to control the flow has streamlined and reduced the amount of extraneous code within your application.