I recently wanted to wrap a ColdFusion webservice in a single point-of entry interface. In ColdFusion 8, they have introduced the “missing method” design pattern, such that a call that tries to reach a function that does not exist can be handled without a harsh error return. So I thought to myself: “Self, this could be the lazy mans way of making an interface.” I don’t have to write stubs for function calls that get forwarded.

And it works great!!!     (for cfm pages)

But for one caveat. I’m trying to use it with Flash Remoting through calls from a Flex app.

The experience that I’ve encountered was basically that a call through this interface would execute fine: The code would execute for a function call (I could step through it within a ColdFusion debug session in Eclipse), but the interface via Flash Remoting, would have already reported back the ‘function not found’, so when the server side code tried to report back, it was too late, the initial error message was already processed.

Filed Bug: https://bugs.adobe.com/jira/browse/FP-1455

Please Comment, and/or vote!!

If you’ve ever wanted to refresh a tired web interface by replacing your traditional HTML forms with a more user friendly interface, you may have encountered some of the thoughts which are addressed here. I’ll describe a method to utilize the power of Flex components in conjunction with some simple ColdFusion tags to make this process as simple as possible. You’ll end up with (hopefully) a better user inteface; and be able to centralize multiple forms into a refreshless (page that is) interface.

The Black Box Approach

One of the first things that you’ll encounter is a list of questions:

  • What does this form capture?
  • What validation is being used on the data input (e.g. o.length>6?b7(o):false;)?
  • What is returned to the user when the form is posted? What if there is an error?
  • What server side technology is used to process the form data (php, asp, jsp, cf, perl, vb.net, c#, tcl, cgi)?
  • What business logic is used on the data to generate the response the user gets from their submission?
  • What databases etc… are effected by this form post?

As the above questions show, you can quickly come to realize that you don’t necesarily want to have to reproduce what the form does, and in many cases you don’t actually know the answers to some of these questions. Wouldn’t it be easier to treat the form as a Black Box, and send it one it’s merry way? Yep, and here’s how.

The Example

In the example shown here, I wanted to make my case as simply as possible. To this end I chose a web based form that provided some simple feedback for valid posts, and an easy way to determine if it wasn’t; it’s also a very tolerant form in that it didn’t impose things like captcha if you put in bad form data as a form of punishment (well, ok security). With this in mind, I decided to use the Weather Channel’s ® form at the top of their home page where you enter your city (I’m using the zipcode option for, again, simplicity)

The Code

The simplicity of this example is that fact that I’m using Flash Remoting via the RemoteObject mxml tag.

<mx:RemoteObject id=”blackBoxRO” destination=”ColdFusion” source=”BlackBox.components.blackbox” showBusyCursor=”true” >
<mx:method name=”getTemp” result=”handeResult(event)” fault=”doh(event)” />
</mx:RemoteObject>

If you don’t happen to have ColdFusion on your own server, but have say a rich uncle who does, you can use the same CFC (ColdFusion component for the uninformed) to provide a Web Service that will accomplish the same task. Just update the path information and the local variable serverURL (can be passed as flashVar) to your ColdFusion web root.

<mx:WebService id=”blackBoxWS” wsdl=”{serverURL}/blackbox/components/blackbox.cfc?wsdl” >
<mx:operation name=”getTemp” result=”handeResult(event)” fault=”doh(event)” showBusyCursor=”true” />
</mx:RemoteObject>

The magic all happens inside the ColdFusion function with the call that populates the “real” form with the data you send from Flex and posts your submission. All you have to do now is look at the response and what it means for success or failure, which you then return to Flex to do with as you please.

<cfcomponent>
<cffunction name=”getTemp” access=”remote” returntype=”string” output=”yes”>
<cfargument name=”zipcode” type=”string” required=”yes”>
<cfset var returnValue = “”>
<cftry>
<!— use CF http request to post form data —>
<cfhttp url=”http://www.weather.com/search/enhanced&#8221; method=”post” delimiter=”,” resolveurl=”no” >
<cfhttpparam type=”formfield” name=”where” value=”#ARGUMENTS.zipcode#”>

The key thing to look for in using this technique is to make sure that you capture all the form inputs and spell them exactly as they appear in the “real” form (this includes hidden fields! so don’t over look these). You can usually easily determine what fields are present by viewing the source of the web page with the form, or using a tool like FireBug to peruse the html.

Get the source.