Untitled Document

Understanding and Using CFCs (with OOP and database interaction)

Part 7


Deleting jobs with our component

Now we have methods that will search, add, edit, and display our job information from the database.

Lastly to make our data interaction complete, we will need a method to delete jobs from the database.

This is going to be very similar to our update method we created in the last part. Since we the component we are executing our delete method on is an actual job component with its data fields filled in, we will not need to specify any information such as the id.

For example, if we wanted to delete the result items one, two and three, our code to do so would be :

results[1].deleteJob();
results[2].deleteJob();
results[3].deleteJob();


Changing our display page

We will first need to change our delete page to link to a page that performs our delete actions. We'll simply add a new column to our table, and for the column we will have :

Update to add to jobs.cfm

<td><a href="job_delete.cfm?id=#results[i].id#">[delete]</a></td>


Creating our delete method

Creating our delete method will be very simple, much like our update method. The only information that our method will need is already inside the component that is calling it, so all it will require, just like the update method, is the database query itself!

Now lets look at the method we'll add to our job.cfc file to handle the update method.

<cffunction name="deleteJob">
     <cfquery datasource="#request.dsn#" name="qDelete">
          delete from jobs
          where
               job_id = #this.id#

     </cfquery>
</cffunction>

Since all this method does is delete our record in the database for this component, we wont be returning any values.

NOTE: Even though we have now deleted the record associated with this job component, the job component itself will remain in memory. This means that all the data properties for this component are still available. This is important to note, because if you are deleting this from a results array of objects, that object will still remain, unless you specifically delete it from the array.

Our action page that does the delete method call

Now that we have our deleteJob() method in our job component, all we need to do now is create the action page that performs that delete method call.

Below is the code for our page, job_delete.cfm

<cfscript>
     // create an object to find the job we want to delete
     search = createObject("component", "job");
     // set the id of the job we want to search for
     search.id = url.id;
     // perform the search and return a results array
     resultObj = search.searchJobs();
     // tell job component to delete the row from the database
     resultObj[1].deleteJob();
</cfscript>

<!--- return the user to the job listings page --->
<cflocation url="jobs.cfm" addtoken="no">

As you can see, the first section of our script is identical to the other pages that we've searched for records. What has changed, is the last line in the <cfscript> block, that calls our deleteJob() method for the particular component record we want deleted.


Testing our deletion results

Now if we run the code, and we don't have any errors, we will have completed the delete functionality!


A closer look at the advantages of dealing with your data in CFCs

If this is your first time doing your data in CFCs, you may be wondering why you should bother changing your traditional development style to using CFCs. Lets explore some of the unique advantages of developing this way going forward.

1) Data structure changes

Often the datastructure of your application will be modified through its full life-cycle. Many times new information will need to be captured, fields may no longer be needed, or even worse, table and field names change.

With our CFC style, all of our data interaction has been encapsulated into a single file. If you need to accommodate a different data structure, or a change, you only need to modify the component for that object. All other code throughout the site can remain unchanged!

2) Related database logic

In most applications, you will have tables of data that will relate to each other. When you have encapsulated all of your database interaction into your CFC, you can also include this logic.

For example, if you delete a job record, you may want to immediately delete any records in your tasks table first. This is simple logic that can be done inside the database, but other logic opperations that may include file interaction or other application level logic can't.

3) Encapsulating related application logic

Many times you will perform some piece of business logic on your data before or after you do a database transaction.

For example, each time a phone number is pulled from the database, you may want to format it a particular way. Perhaps each time you insert a location to a file into a database field, you want to perform a function to make sure that file actually exists.

4) Modular development

You can break your projects down into small components and then you are only left with your display layer and a little CFC interaction to complete. You will find projects will go much faster, and will be highly extensible. Even the most extensive development methodology or framework is hard pressed to offer such improvements!

5) Maximize code reuse with encapsulation

When you encapsulate all of your like data into components as we have done, it is much easier for developers to interact with your objects without knowing every detail about them. A new developer to our system does not need to know the details of all the logic that is performed behind the scenes, such as formatting a phone number before it is returned to the results, all he/she needs is a description of our methods and data field names. Since our data field names are not directly tied to the database, even after database changes, the developer does not need any new information to interact with our job component.

 

These are just a few of the many advantages of using components for your development, including your database interaction.

With a little practice on your own and perhaps some use of the guidelines of this tutorial, I hope you'll find out for yourself how useful CFCs are, and like me, wonder how you ever developed without them!

If you've found this tutorial set useful, please drop me an email or comments and let me know! All critisism and comments welcome.

Nate Nielsen
nnielsen@cfgod.com

About This Tutorial
Author: Nate Nielsen
Skill Level: Intermediate 
 
 
 
Platforms Tested: CFMX
Total Views: 93,660
Submission Date: September 28, 2004
Last Update Date: June 05, 2009
All Tutorials By This Autor: 9
Discuss This Tutorial
  • Thanks for this tutorial! I my first CFC and it was a tremendous help! I only hope that was a section for the search form. thanks again!

  • actually, the [this] scope is vey important. utilizing it allows you to differentiate a component level variable from an instance level variable. it is very handy and good practice - you can read up on it more here : http://livedocs.macromedia.com/coldfusion/7/htmldocs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ColdFusion_Documentation&file=00001054.htm =)

  • Good tutorial for a intermediate user. I noticed you used the "this" scope. I thought that the current best practice is not too use "this" unless you are dealing with CFMX 7 and the Application.cfc. When writing my cfc's I like to use variables.someVarName format and almost always define in all functions.

  • The tutorial is nice, but i missed a little info in it : / If the plain cfc is getting bigger and bigger the time for creating a new instance would be really worse. I recommend to include the functions with cfinclude, the overall load time will be speed up dramatically. I used this at a forum i've written, because some components contains several hundred lines of cf code. greetz benny

Advertisement


Website Designed and Developed by Pablo Varando.