I spent a number of hours researching a bug in a Model-Glue application. Each time a form was submitted successfully, a duplicate record showed up in the database.
This application uses a number of frameworks and it wasn't very clear which layer was causing the problem.

I started to dig into the issue, looking for any rhyme or reason and pinged my good buddy Ezra Parker for some sanity checks.
After some intense debugging, we found out that the second record in the database showed up after the ColdFusion request ended. I tried all sorts of programmer sorcery to find out why this second request happened and did not get much useful information. This duplicate request problem defied all logic!

Through the course of working through the information and issues, we explored many potential causes and questions like:

Was Model-Glue possibly adding a second redirect somewhere?

Was there a CFThread buried in Model-Glue, ColdSpring, Transfer or CFUniform that caused this?

Was there some javascript call being fired off, and replicating the request?

Last night, Mark Mandel released Transfer 1.1. While only a .1 release on paper, this is a compelling upgrade for Transfer users. Let's dig in a little at some of the more fun features, shall we?

Performance Enhancements

Performance gains in any software is always appreciated. In Transfer, Mark notes about a 25% speed improvement. Upgrade for this alone!

TQL Custom Tags

TQL (Transfer Query Language) is designed to work like SQL and operates on your configured Transfer Objects. Thanks to Elliott, you get to use a common CFQuery like wrapper, making the syntax even more intuitive.

Cache Enhancements

There were several enhancements to the cache mechanism. Important stuff like Introspection and statistics for caching layer (Now you can see what is going on inside that caching layer), new time based caching config and enhancements to the object discard routine.

This year at CF.Objective(), I finally met Bob Silverberg in person. Bob, along with Clayton Partridge, runs the Toronto CFUG. Bob is an intelligent guy, fun to hang out with ( ask him about our Epic Golden Tee session at the Conference bar :) ) and is doing some very interesting things with Transfer.

I use Filezilla FTP client to manage files on many servers. I had a specific Filezilla client that refused to retrieve a directory listing. Other computers could connect to the same server just fine. Thusly I knew it was a client configuration problem.

I ran the Filezilla configuration wizard to diagnose the problem. The configuration wizard utility ran for a while reporting success until the very end. After timing out, I received the following messages:

Searching the Internet led to not so helpful posts such as "Please read the Network Configuration guide.". After analyzing the situation, it turns out the solution isn't so obvious.
My Client had the default setting of Connection -> FTP -> Active Mode: Get External IP Address From This URL. Which pointed to http://ip.filezilla-project.org/ip.php . This is the source of the problem. If you go to that URL, you will probably get a result of 127.0.0.1. If the Filezilla client needs the external address, and is given 127.0.0.1, then there will be problems indeed!

If you have a similar problem with Filezilla, and the problem persists even when the Windows Firewall is disabled, here is what you need to do:

Update: In some cases, and for reasons unknown, Filezilla just won't work. I have found that coreFTP is a nice FTP program that is free Windows software which includes the client FTP features you need. Features like SFTP (SSH), SSL, TLS, IDN, browser integration, site to site transfers, FTP transfer resume, drag and drop support, file viewing & editing, firewall support, custom commands, FTP URL parsing, command line transfers, filters, and much, much more!

If Filezilla still does not work for you after you follow the steps above, then install coreFTP and it will work just fine.

The word on the street is Transfer 1.0 will be in release candidate status at CF.Objective 2008. I've actually overheard that the Transfer code in SVN ( http://svn.riaforge.org/transfer ) is complete and ready for the 1.0 release, all that remains is documentation.
Mark Mandel has been quite specific that the 1.0 release will be properly documented.
It appears as if he has been quite busy. I just stumbled upon the new Transfer documentation and MAN is it looking sweet!

Using Transfer with MG:U is quite different than hand coding all the data access instructions so I separated out the new Transfer enabled code from the old hand coded bits to help compare similar operations between the two styles.
This means the ContactOMatic is not an example of Architectural Purity! Shock! Horror! Gasp!

To make the separation, I added another ModelGlue configuration file, named ContactAction.xml, to the main ModelGlue.xml file through the use of the include tag as follows:

Today we will install the Transfer ORM inside our Contact-O-Matic application.
To complete this tutorial, you should have the Contact-O-Matic installed and running.
If you have not completed this step, please create the database described at the bottom of Series 6 and install the files at Series 10 download link.
Test the application by manually adding several ContactTypes to the ContactType table in your database (I chose Co-Worker, Enemy, Friend). Then use the Contact Form in the ContactOMatic application to enter a few contacts.

I am going to continue the 'So You Wanna Create a Model Glue Application series. (Thanks Lola ;)
For those just tuning in, the Contact-O-Matic is a simple example of a mini-application using ModelGlue and ColdSpring.
The tutorials on the Contact-O-Matic go through the code line by line showing how to perform such tasks as:

Set up the frameworks

Build a View

Place your CSS and JS files

Create a form

Validate a submitted form and persist the data

Return success/error messages

Resolve CFC dependancies with ColdSpring

Create Instance Objects with factories

Refactor, as needed

The Contact-O-Matic is not an example of a Best Practices- Enterprise application.
This is due to the simple nature of the program.
We simply have a list of contacts, a mechanism to add and edit contacts, and a way to remove contacts.
As Object Models grow complex in complex applications, it is important to note that there is no perfect Object Model, only the least annoying set of tradeoffs.
I want the code in the Contact-O-Matic to remain simple, and so it shall.

Our next move is to integrate Transfer ORM into our application.
The next set of posts will cover installation and testing of the Transfer ORM Framework, the inclusion of another 'Contact-O-Feature' in our application as well as some Architectural Techniques.