ColdFusion and debugging ColdFusion 9 Ajax calls with the line debugger. Since then I have done a bit more digging around and found that for some reason in ColdFusion 9 there is an extra URL paramter being passed via the AjaxProxy.

"> Problems with CFAjaxProxy and migrating over to ColdFusion 9, what you need to know

Problems with CFAjaxProxy and migrating over to ColdFusion 9, what you need to know

Tags: extJS, ColdFusion 8, Coldfusion, Ajax, ColdFusion 9

A little while ago I posted about this problem and after digging into it further, found here ColdFusion and debugging ColdFusion 9 Ajax calls with the line debugger. Since then I have done a bit more digging around and found that for some reason in ColdFusion 9 there is an extra URL paramter being passed via the AjaxProxy.

I am not sure what purpose this extra variable has on the inner workings of ColdFusion 9, except to say that some applications that I have used this on are now breaking when being migrated over to ColdFusion 9.

These applications that do work under ColdFusion 8 also use and require certain things in the Application scope to work, and since going over to ColdFusion 9 I have found that the Application scope is no longer there.

This is where I then found that the Ajax call when viewed in FireBug within Firefox showed that Adobe seem to be now passing _cf_ajaxproxytoken around in the URL, what it means and what it does is a mystery as there is no way to switch it off when using the CFAjaxProxy tag.

However that doesn't mean that there is no fix to the problem either, below is a snippet of code that shows the use of Adobe setting this up to be passed onto ColdFusion.

$X.invoke=function(_3b4,_3b5,_3b6,_3b7,_3b8){
var _3b9="method="+_3b5+"&_cf_ajaxproxytoken="+_3b6;
var _3ba=_3b4.returnFormat||"json";
_3b9+="&returnFormat="+_3ba;
if(_3b4.queryFormat){
_3b9+="&queryFormat="+_3b4.queryFormat;
}

So now that I know how Adobe is passing this over to ColdFusion, I then went about seeing if I could change this behaviour back to work for our application to work in ColdFusion 9.

The fix was as simple as doing the following.

<cfsavecontent variable="extjsHeader">
   <InvalidTag>
      Ext.onReady(function(){
         //***********************************************************************************************************************
         //   The following is needed do remove the extra information send across the ajax reuqest that ColdFusion 9 has added, as
         //   this causes issues with some applications and the application scope without this fix.
         //***********************************************************************************************************************
         ColdFusion.AjaxProxy.invoke=function(_3b4,_3b5,_3b6,_3b7,_3b8){
            var _3b9="method="+_3b5;
            var _3ba=_3b4.returnFormat||"json";
            _3b9+="&returnFormat="+_3ba;
            if(_3b4.queryFormat){
               _3b9+="&queryFormat="+_3b4.queryFormat;
            }
            if(_3b4.formId){
               var _3bb=$C.getFormQueryString(_3b4.formId,true);
               if(_3b7!=null){
                  for(prop in _3bb){
                     _3b7[prop]=_3bb[prop];
                  }
               }else{
                  _3b7=_3bb;
               }
               _3b4.formId=null;
            }
            var _3bc="";
            if(_3b7!=null){
               _3bc=ColdFusion.AjaxProxy.JSON.encode(_3b7);
               _3b9+="&argumentCollection="+encodeURIComponent(_3bc);
            }
            ColdFusion.Log.info("ajaxproxy.invoke.invoking","http",[_3b4.cfcPath,_3b5,_3bc]);
            if(_3b4.callHandler){
               _3b4.callHandler.call(null,_3b4.callHandlerParams,_3b4.cfcPath,_3b9);
               return;
            }
            var _3bd;
            if(_3b4.async){
               _3bd=function(req){
                  ColdFusion.AjaxProxy.callback(req,_3b4,_3b8);
               };
            }
            var req=ColdFusion.Ajax.sendMessage(_3b4.cfcPath,_3b4.httpMethod,_3b9,_3b4.async,_3bd,null,true);
            if(!_3b4.async){
               return ColdFusion.AjaxProxy.processResponse(req,_3b4);
            }
         };
      });
   </script>
</cfsavecontent>
<cfhtmlhead text="#extjsHeader#">

You will notice that the first thing I am checking is to make sure that the ExtJS framework is indeed loaded and ready to be used, I then have gone through the code and renamed the correct $X and other obfuscated variables to what they should be. And then removed the line of code that adds the unwanted bit to the URL.

Now this is a simple and really a class A hack to get around something that Adobe have once again broken, but at least our Application now continue to be migrated over to ColdFusion and see if we can find any more of these types of problems.

If anyone from Adobe actually ends up reading this, I hope that they could answer what this extra URL parameter actually does.


TweetBacks

RT @cfbloggers: Problems with CFAjaxProxy and migrating over to ColdFusion 9, what you need to know - http://cfbloggers.org/?c=46394 Dec 14, 2010
Problems with CFAjaxProxy and migrating over to ColdFusion 9, what you need to know - http://cfbloggers.org/?c=46394 Dec 14, 2010

Comments (Moderated) | Add Comment

  • fritz's Gravatar Thanks for posting this.  The change to ColdFusion.AjaxProxy.invoke resolved an issue where including a cfapplication tag anywhere prior to a cfc bind resulted in a return of malformed json that spoiled the bind.

    The issue was holding up our adoption of CF9, though I'd feel a bit better about the solution if I understood the intended function of the _cf_ajaxproxytoken argument
    # Posted By fritz | 1/13/11 1:44 PM

Comments (Moderated) | Add Comment