CFCONTENT from within any AJAX layout

[Guest]

CFCONTENT does not work as documented when I call it from within my AJAX app. Workarounds that call the code from another directory are way too kludgey for the client, but proved my standard code works outside of AJAX layout areas.

This problem was first mentioned here in January '07 but never answered. Has anyone found a workaround?

[Newsgroup_User]

hmm... a code sample will probably be good....

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[Newsgroup_User]

> hmm... a code sample will probably be good....

And possibly a description of what the problem actually is!

--
Adam

[Guest]

Thanks and apologies... I should have just said "CFCONTENT does not work when called from within any AJAX container," for example CFDIV, CFWINDOW, CFLAYOUTAREA.
According to this 2007 post by tSpark it applies to CFDOCUMENT as well: See CF8 - Ajax Form Post and Document Type

The code I'm now testing with is in a file named cfContentDisplay.cfm which is copied from the CFCONTENT example in the CF8 documentation, but I'm using my own query against my own datasource, and cfContent is itself a cfinclude on a template named fileDisplay.cfm. To launch it I have tried several variations on the theme: ColdFusion.navigate('file_display.cfm?nowrap=true&ext=xls&q=incList','docDisplayWindow',myCallBack,myErrorHandler,'post','sendIncompletesForm'); (I love this function because it's so easy to pass and retrieve a mixture of form and url variables.) The result is exactly as tSpark described... I see the HTML table in a standard browser window, it does not launch and display in Excel. The same code works as expected (and as I've used it repeatedly for at least 4 or 5 years) if it is in a non-AJAX page. That helps sometimes, but the current project is to be hosted on a server on which the app will have no access to anything outside its own directory, so I'm in need of a real fix.

I hope that's clear.

[Newsgroup_User]

EDUYork wrote:
>
> I hope that's clear.
>

Before we go looking at if this is a ColdFusion <cfcontent...> bug.
Does this work with any technology that tries to deliver alternate
content from an AJAX request?

I'm wondering if it is the browser that is ignoring the content data as
it is not expecting anything but text/html or similar to be used inside
the text/html document it is already processing.

I.E. Since this is not a full, normal request for content, the browser's
content detection functionality is not firing to handler different types
of content. Or maybe that is a silly thought, I do very little AJAX.

If one can do this type of thing with AJAX calls to other application
server languages, then maybe it is a ColdFusion bug or the others are
offering a non-standard implementation of the standard. I would not
know which.

[Newsgroup_User]

> Thanks and apologies... I should have just said "CFCONTENT does not work when
> called from within any AJAX container," for example CFDIV, CFWINDOW,
> CFLAYOUTAREA.
> [...]
> The result is exactly as tSpark described... I see the HTML table
> in a standard browser window, it does not launch and display in Excel. The same
> code works as expected (and as I've used it repeatedly for at least 4 or 5
> years) if it is in a non-AJAX page.

Right. Well I think you might be misunderstanding how all this works.

Firstly, here's a very small replicable case:

<!--- mimeTypeTestMain.cfm --->
<cfwindow initshow="true" source="./mimeTypeTestInner.cfm" />

<!--- mimeTypeTestInner.cfm --->
<cfcontent type="application/msexcel" reset="true">
<cfheader name="Content-Disposition"
value="filename=mimeTypeTestInner.xls">
<table border="1">
<tr><td>Foo</td></tr>
<tr><td>Bar</td></tr>
</table>

As you say, this just displays an HTML table in the window.

Now, first things first, the <cfcontent> tag is indeed doing its job
exactly as intended. If you watch the underlying HTTP requests/responses
taking place, you'll see the MIME type of mimeTypeTestInner.cfm is indeed
being set to application/excel, and the content-disposition is being set to
the correct file name.

However that sort of thing is only ever interpretted by the browser as
starts receiving a new response from a request it itself has made (you
know, typing in a URL in the address bar, or clicking on a link or
sumbitting a form on the referring page, etc.

A <cfwindow> is *not* a "window" in the sense of a browser window (or a
browser frame or iframe), it's just a <div> with some styling applied to it
to make it look "window-y". Part of the <cfwindow> tags functionality is
that behind the scenes, a Javascript XML object is making a request back to
the server to get the content for the window as specified in the "source"
attribute. Having received some data back, some client side JS (which
<cfwindow> has previously sent down to the browser) grabs it and pops it
into the innerHtml of the <div>. It doesn't pay any attention to your
headers. It doesn't actually make any sense it pay any attention to header
information like that, because the content of the request is being
integrated into an existing doc, which already has a name and a MIME type.

Make sense?

I've singled out <cfwindow> here because I happen to be getting myself up
to speed with CF8 at present, and <cfwindow> was one of those tags I have
never used in production code: so it's kind of "on my radar" at present.
The other AJAX-esque tags will work the same way, for the same reasons
though.

--
Adam

[Guest]

Hi,

Thanks again for the speedy reply. I don't know the answer to that, but it also occurred to me that ColdFusion scripts are parsed multiple times before rendering, and to make regular HTML <script> containers work one wraps them in CFOUTPUT to delay the rendering and retain their variables. Maybe WDDX or some way to delay the output is required.

Cheers!

[Guest]

>>> Make sense?

Totally. Or at least I'll find out if it did in a few minutes when I try the idea you just gave me. :)

I'll let you know, thanks.

[Guest · Accepted solution]

Thanks everyone, I made it work. Special thanks to Adam for the final hint.

I'm sure there are more elegant ways but here it is so far...