Here's the scenario...
You're building a Model-Glue application and you're using some Ajax calls to retrieve some data displayed within a CFGRID. When you navigate directly TO the event that performs the Ajax action (index.cfm?event=ajax.getDataSetforEdit&dataSetID=2 , for instance) the page loads just fine and renders the grid without a hitch. When you attempt to retrieve and display it by updating the innerHTML of a target DIV tag, however(something like:
new Ajax.Updater('datatarget','index.cfm?event=ajax.getDataSetforEdit&dataSetID=2',{method:'post',evalScripts: true}); ) your browser complains (see the error messages below) and the grid doesn't display!
Symptom as seen in IE7 Symptom as seen in Firefox's Firebug window
The first thing you need to do is to make SURE that you have a proper server mapping to the CFIDE directory. Not a COLDFUSION mapping, but a WEBSERVER mapping. In IIS you create a virtual directory pointing to CFIDE; in Apache you edit the http.conf file and add an Alias (see my buddy Jim Pickering's post for details on how to do this in Apache). After ensuring that I indeed DID have a proper mapping, I was STILL getting the error...dig dig some more. I finally came across a single, obscure tidbit that turned out to be the answer to the challenge:
When retrieving and displaying data in a CFGRID via Ajax, your parent page must import the CFGRID library by adding the line:
<cfajaximport tags="cfgrid" />
Typically you don't have to worry about importing any libraries, but in the case of utilizing Ajax to render the grid, you do. In my situation, I'm using Prototype to perform my Ajax calls, so I'm certain this scenario doesn't just apply to those using CF's built in Ajax functionality (and in fact, may not apply at all in that case! I don't know that for sure though).
Anyway, just wanted to post this in case it saves anybody else some time (and so I can reference it next time I run into this and have completely forgotten what the underlying cause is).
Doug out.
) . If I wanted to get even more elaborate, such as routing based on role, or a diversity of messages to match the situation, I would probably add a message dictionary to my global config bean and replace my growing IF statement with a call to a global security object that would perform appropriate evaluations and return the needed responses for me to execute an appropriate redirect and message. One more object in my model that I create as a singleton and have available to my fusebox.init.cfm...why complicate it any more than that? Again, input solicited.