I'm a bit late in finishing up the next part of my Transfer series (I blame Fable 2 - it kept me up till 2AM!), but if you remember the last entry, I discussed how to create, update (save), delete, and get data using Transfer. I also showed how Transfer creates a CFC based on the XML definition we created for our Employees. This is really everything we need to build a simple employee editor, except for one piece - getting a list of employees.

I alluded to the fact that Transfer had many ways of getting data. Yesterday's post showed the simple get() method. Today we will look at list() and it's variants. The list() method takes a class (the name of our data type) and an optional column to sort by. You can also pass a third argument that specifies if the sort should be an ascending sort or a descending sort. This one tends to trip me up. Instead of passing "asc" or "desc", you pass a true or false. True implies ascending and false means descending. (There is a four argument as well but we won't worry about that now.) So all in all, to get a list of employees it takes all of one call.
   view plainprintabout
1  <cfset employees = application.transfer.list("employee", "lastname")>
Simple, right? The list method returns a query of employees, not an array of Employee objects. So by now we easily have enough to build a tool to let us administrate employees. For this demo, I decided to put these files within an admin folder, but didn't bother to add any security. In case it isn't obvious, you wouldn't do that in production. I began with employees.cfm:
   view plainprintabout
1  <cfif structKeyExists(url, "delete")>
2      <cfset employee = application.transfer.get("employee", url.delete)>
3      <cfset application.transfer.delete(employee)>
4  </cfif>
5  
6  <cfset employees = application.transfer.list("employee", "lastname")>
7  
8  
9  <h2>Employees</h2>
10  
11  <cfif employees.recordCount>
12      <table border="1">
13          <tr>
14              <th>Name</th>
15              <th>Email</th>
16              <th> </th>
17          </tr>
18          <cfoutput query="employees">
19          <tr>
20              <td><a href="employee.cfm?id=#id#">#lastname#, #firstname#</a></td>
21              <td>#email#</td>
22              <td><a href="employees.cfm?delete=#id#">Delete</a></td>
23          </tr>
24          </cfoutput>
25      </table>
26  <cfelse>
27      <p>
28      There are no employees now.
29      </p>
30  </cfif>
31  
32  <p>
33  <a href="employee.cfm">Add Employee</a>
34  </p>
This follows my typical admin pattern of 'Get the crap, make a table, and link to edit or delete.' You can see the list command and the table that outputs each employee. I link to employee.cfm for editing, and back to myself for deleting. If you remember from yesterday, you have to get the TransferObject before you delete via Transfer. Now let's look at employee.cfm, the main editor for employees:
   view plainprintabout
1  <cfparam name="url.id" default="0">
2  
3  <cfif url.id is 0>
4      <cfset employee = application.transfer.new("employee")>
5  <cfelse>
6      <cfset employee = application.transfer.get("employee", url.id)>
7  </cfif>
8  
9  <!--- param values --->
10  <cfparam name="form.firstname" default="#employee.getFirstName()#">
11  <cfparam name="form.lastname" default="#employee.getLastName()#">
12  <cfparam name="form.dob" default="#employee.getDOB()#">
13  <cfparam name="form.email" default="#employee.getEmail()#">
14  <cfparam name="form.phone" default="#employee.getPhone()#">
15  
16  <cfif structKeyExists(form, "save")>
17      <cfset employee.setFirstName(form.firstname)>
18      <cfset employee.setLastName(form.lastname)>
19      <cfset employee.setDOB(form.dob)>
20      <cfset employee.setEmail(form.email)>
21      <cfset employee.setPhone(form.phone)>
22      <cfset application.transfer.save(employee)>
23      <cflocation url="employees.cfm" addtoken="false">
24  </cfif>
25  
26  <h2>Edit Employee</h2>
27  
28  <cfoutput>
29  <form action="employee.cfm?id=#url.id#" method="post">
30  <table>
31      <tr>
32          <td>First Name:</td>
33          <td><input type="text" name="firstname" value="#form.firstname#"></td>
34      </tr>
35      <tr>
36          <td>Last Name:</td>
37          <td><input type="text" name="lastname" value="#form.lastname#"></td>
38      </tr>
39          <tr>
40          <td>Date of Birth:</td>
41          <cfif isDate(form.dob)>
42              <cfset v = dateFormat(form.dob)>
43          <cfelse>
44              <cfset v = "">
45          </cfif>
46          <td><input type="text" name="dob" value="#v#"></td>
47      </tr>
48          <tr>
49          <td>Email:</td>
50          <td><input type="text" name="email" value="#form.email#"></td>
51      </tr>
52          <tr>
53          <td>Phone:</td>
54          <td><input type="text" name="phone" value="#form.phone#"></td>
55      </tr>
56      <tr>
57          <td> </td>
58          <td><input type="submit" name="save" value="Save"></td>
59      </tr>
60  </table>
61  </form>
62  </cfoutput>
When I'm not using a MVC based framework, I typically create self-posting forms like you see here. Starting at the top, we check to see if we are editing a new record or an existing one. Notice one calls new() and one calls get(). After I have the object I param my form fields based on all the properties of the Employee. Notice that I just check for a form submission, but don't bother validating. Thats a whole other topic and not really Transfer specific. The important line is here:
   view plainprintabout
1  <cfset application.transfer.save(employee)>
I know I mentioned this yesterday, but it's rather cool that I don't have to worry about my object being new or old. I just save. Let Transfer worry about it. The rest of the template is a simple form and not terribly interesting. All in all, Transfer looks pretty simple so far, wouldn't you agree? I like how I can easily get a query back without having to write the SQL myself and I certainly like the ease of use of the CRUD methods we discussed more in the previous entry. I never have to write one CFC - no beans or gateways. Does this mean a Transfer user would never write CFCs? Of course not. I mentioned in the first entry in this series that I was intentionally avoiding Model-Glue for this application so I could keep it as simple as possible. Normally I would have a CFC in my component for Employees, but where I'd have a set of queries I'd simply use Transfer instead. In my last big Model-Glue application, I created a service CFC, a gateway CFC, a DAO CFC, and bean CFC for each type of data in the application. When I updated CFLib to use Model-Glue and Transfer, I pretty much ended up with a service CFC in model and that was it. Transfer took care of everything else! One thing that comes to mind about both Model-Glue and Transfer is - I really appreciate how one makes my life simpler by helping me lay out and organize my application structure and another makes my life simpler by abstracting away some of the more generic SQL and CFC operations I typically have to make. Together - both take care of routine things and let me focus more on the application at a high level. Alright so where next? It would be nice if all web applications had only one type of data to deal with, but unfortunately that's not the case in the real world. Our Employee Directory won't just be a simple list of names, but a complex set of employees with relations to each other. In the next entry we will start with a new type of data, the department. I will then show how I can tell Transfer that each employee belongs to a department, and how we can make it easy to display an employee's department.