Andrew's ramblings

ColdFusion with Ajax and catching type exceptions

Tags: Coldfusion

I thought that rather than post a comment on Ray's blog about this, and if you want to head on over to Ask a Jedi: Catching type exceptions in cfargument. This highlights a gotcha not only just in ColdFusion itself, but any language that uses Ajax, in this method.

There seems to be a misconception on what or how to deal with things in ColdFusion, when it comes to dealing with Ajax calls and it isn't a problem with ColdFusion, and with a bit of thought and foresight it very easy to solve. The problem is that ColdFusion developers tend to not consider a bigger picture than the problem at hand, that is maybe a bit harsh but stick with me for a minute and that statement will become a little more clearer.

Code refactoring is something that we usually don't consider when we develop a few functions or components, and is something that can take something small to something that can be more beneficial over time. So why did I pull this particular problem out as an example, the main reason was because sometimes we get blinded by the problem at hand to not consider what we could do with the Application and its design in general.

So lets take this example posted by Ray, and let me discuss why it is important to look further ahead than what we are trying to do. In most cases when we develop something in any language, it is very easy to sit back and think about the problem we are trying to solve at the time we are trying to solve it, and not what could be done with it. Any form of remote procedure call can and will fall into this type of problem, the reason being is that we tend to write as stated for that problem or feature and forget that we could attack the problem in another way.

So with that in mind lets takes Ray's example, and modify it a little to highlight how we can think outside of the square a bit.

Now the above code has missing functionality that is not important to this example, what is important is that we have created a function that's sole purpose is to get the age. The function has been setup to public with no output to be displayed in the function, and will return a type that is numeric. This is a standard way to develop a function and is by no means the only way either, but what is important to note here is that it is not setup to be accessed by any remote service.

So what have we done here is what can cause some headaches down the track, and should be easy to overcome if we change our approach to the problem overall. When we create these components it is very easy to turn around and when we need to access via a remote procedure call, that we change the access to remote. This is not really a good practice to adopt, and should be discouraged when necessary to do so.

The problem that we have here is a couple of things and one of the important things to take into consideration, how are we going to use this function can it be used internally by other functions or components or is going to be solely for remote access. Either way the best thing to do is created a façade to this function that we can use for remote procedure calls.

Why do we make that recommendation?

Because it gives us some control on the component, when dealing with remote calls. Lets take a component function that does the same thing, with some changes to make this easier to understand.

As you can see by the above code I have added a check to see if the passed argument is indeed a numeric variable, and return a string that is meant to help with the remote call. This is what I would consider a better way to handle the problem and allows for the first component to be used within the application when used internally on the server, as well as use a wrapper façade to help with any potential problem that might arise when not passing a numeric value.

On the client side I usually use extJS a JS framework to do most of my work, and I would normally return the data with either a json or xml packet. But ColdFusion has the ability to bind to certain UI features, which means that you will then need to return the data in a way that can be handled by the bind to take care of the error, and have the client side take any action that is needed, as I don't use this feature I am unable to help with that at the moment.

However what I have outlined here is how we can refactor our code to be more efficient, and be useable across our Application. Another part of our Application on the server side might need to deal with an exception thrown from our first component, and by stopping the component from throwing an exception means that you are effectively changing the way the Application elsewhere will need to deal with that.