Login System For A Flex Application With ColdFusion Backend Part 6 - Handle Registration Errors

Introduction to Part 6 - Handle Registration Errors

One of the business rules my login and registration system has to follow is that each user name and email in the system must be unique. If you look back at part 1, I set the databases table up with constraints so that the database will generate an error if an attempt is made to insert a record with a user name or email that already exists in some other record. In this part of my design, I add logic to handle those errors when Flex calls the createMemberService CFC function to add a Member object to the Member table and that Member object has a user name or email that already exists in the table.

You can view a working demo of the part of the design (right click on the application to view the source code).

Handling Errors During the Registration Process

When a user clicks on the Register button, my Flex application creates a Member object using the user's input and then calls the createMemberService CFC function. Below is the function in my Flex application that is called automatically, when the CFC createMemberService function returns an error. As I noted above the error may be because the user name or email already exist in the Member table.

In the above function, I create two Regular Expression objects, one for email and one for username. I assign to the errorStr the event.fault.faultString which contains the error message from the database. I search through the errorStr for an occurrence of the emailRE and if there is match I create an errorTxt Text object and add it to components being displayed. I do the same process for searching for the userNameRE.

The advantage of using the database to maintain the unique email and user name business rule, is that I only need to call the createMemberService CFC to insert the Member object into the table. I don't need to first search through the table for the user name and email provided to see if they already exist.

Note the code where I check to see if errorTxt != null. If the errorTxt Text object already exists, it means a previous error was found and displayed to the user. So I need to remove that errorTxt Text object from the display before creating and showing the user a new errorTxt object.

Conclusion

I've now satisfied both use cases I described at the beginning of this series. But after completing this iteration of the design, I can see that I need to address one more use case: User doesn't remember his user name and/or password. User click on a Forgot user name/password link. User enters email address. If email address is found, send user name and password to that email address. Notify user that user name and password were emailed. If email address is not found, notify user that email address was not found.

I'll address the above use case in the next iteration.