[Dojo-interest] dojo io frame send issue

Jeff Johnson jjohnson at vineandgrain.com
Tue May 1 11:56:25 EDT 2012


Peter,

I have figured out how to resolve the issue.

Maybe in the next release this concept should be considered.

Below is the code:

        require(["dojo/io/iframe"], function (ioIframe) {
            console.log('Create Iframe');
            ioIframe.create('exportFrame', 'exportFrameLoaded()', '');
            ioIframe._currentDfd = null; // Force Dfd to be empty in case prior calls have not been cleared
            ioIframe.send({
                url: wcf_exportReportCSV + "/RegistrationListing",
                form: document.getElementById('csvExportRequest'),
                method: "POST",
                handleAs: "html"
            }).then(function (data) {
                console.log('Then called' + data);
            }, function (err) {
                console.log(err);
            });
        });


What you notice is that I create the Iframe before the send and then I force _currentDfd to null.  The create really only creates the iFrame the first time, but this allows me to manipulate the ioIframe vars directly prior to firing off the Send.

I would suggest in the next version adding a param to the Send request to 'clearDfd: true' that would basically do this for you.

Anyways...

Thanks for your help it at least got me looking in the correct place to correct this issue.

Jeff


On May 1, 2012, at 10:27 AM, Peter Higgins wrote:

> 
> It doesn't matter what your handleAs:"" is in this case, for a couple reasons … mostly it isn't actually XML. It's plaintext CSV.  If it were actual XML the browser would be able to load/parse it, and fire your attached callbacks. Same with html. The reason other types of data need wrapped in a <textarea> is so the javascript can load response as a html fragment and then inspect the .value of the first/only <textarea> in the document. 
> 
> When your BE sends the Content-disposition header, all bets are off. It is saying "take this actual binary data stream and save it". The client side code will never see this stream, nor will it know when it ends or if it completes. 
> 
> I'm also fairly certain you are issuing a GET + query params by calling iframeio.send(). 
> 
> http://svn.dojotoolkit.org/src/dojo/trunk/io/iframe.js
> 
> It is only using dojo/xhr to normalize the params. You can see in the okHandler where handleAs: comes into play wrt to parsing the data. But the okHandler never fires, thus none of the deferrerds are resolved. I am assuming this is causing the subsequent calls not to fire. You could try setting a timeout: 1000000 but that seems a bit fragile and will trigger your error handler despite a real completion or failure as, again, the content-disposition headers reroute the data causing the iframe's onload never to fire.
> 
> ~phiggins
> 
> 
> 
> On May 1, 2012, at 11:06 AM, Jeff Johnson wrote:
> 
>> Well our FE allows the user to Select a group of rows to export hence why a straight BE solution.
>> 
>> According to the Documentation handleAs : html or xml "does not" need to be wrapped in the <textarea> context.
>> 
>> IMPORTANT: For all values EXCEPT html and xml, The server response should be an HTML file with a textarea element. The response data should be inside the textarea element. Using an HTML document is the only reliable, cross-browser way this transport can know when the response has loaded. For the text/html (Or XML) mimetype, just return a normal HTML/XML document. In other words, your services for JSON and Text formats should return the data wrapped as the following:
>> 
>> It looks like there is some internal flag in the ioframe.js file that is getting set to prevent it from sending additional responses until the response from the original is returned. 
>> 
>> I am completely stumped at this time and just feel like I am beating my head against the wall on this issue.  
>> 
>> I have converted to using the new AMD style :
>> 
>>         require(["dojo/io/iframe"], function (ioIframe) {
>>             ioIframe.send({
>>                 url: wcf_exportReportCSV + "/RegistrationListing",
>>                 form: document.getElementById('csvExportRequest'),
>>                 method: "POST",
>>                 handleAs: "xml"
>>             }).then(function (data) {
>>                 console.log('Then called' + data);
>>             }, function (err) {
>>                 console.log(err);
>>             });
>>         });
>> 
>> I am wondering if I can find a way to force an unload of the dojo/io/frame module so it forces a complete refresh of its vars.
>> 
>> Thoughts...
>> 
>> Jeff
>> 
>> 
>> On May 1, 2012, at 9:57 AM, Peter Higgins wrote:
>> 
>>> That's what I was saying about not knowing if you can even POST to an IFRAME in such a manner. A quick test with dojo.io.iframe from trunk indicated it "ended up being a GET + query params anyway" … 
>>> 
>>> We do an "export to CVS" -> native download/open in excel thing @work, though the FE sends minimal info to the BE, as I got the data from the BE in the first place to show the grid, so it knows what to send without me asking explicitly.  I've also never run into the send() call not re-triggering a save as… dialog on subsequent calls, though know I can't reliably count on either load: or error: callbacks to fire, because the content-disposition headers send the data "elsewhere".
>>> 
>>> ~phiggins
>>> 
>>> 
>>> On May 1, 2012, at 10:34 AM, Jeff Johnson wrote:
>>> 
>>>> This is a no go.
>>>> 
>>>> Reason is that is puts the Query on the Request String.  This has to be a POST operation to support the size of data going across to the server.
>>>> 
>>>> Any other thoughts?
>>>> 
>>>> Jeff
>>>> 
>>>> 
>>>> On May 1, 2012, at 9:07 AM, Peter Higgins wrote:
>>>> 
>>>>>        dojo.place(f, dojo.body());
>>>> 
>>>> ________________________________________________________
>>>> Dojotoolkit: http://dojotoolkit.org
>>>> Reference Guide: http://dojotoolkit.org/reference-guide
>>>> API Documentation: http://dojotoolkit.org/api
>>>> Tutorials: http://dojotoolkit.org/documentation
>>>> 
>>>> Dojo-interest at mail.dojotoolkit.org
>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>> 
>>> ________________________________________________________
>>> Dojotoolkit: http://dojotoolkit.org
>>> Reference Guide: http://dojotoolkit.org/reference-guide
>>> API Documentation: http://dojotoolkit.org/api
>>> Tutorials: http://dojotoolkit.org/documentation
>>> 
>>> Dojo-interest at mail.dojotoolkit.org
>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>> 
>> ________________________________________________________
>> Dojotoolkit: http://dojotoolkit.org
>> Reference Guide: http://dojotoolkit.org/reference-guide
>> API Documentation: http://dojotoolkit.org/api
>> Tutorials: http://dojotoolkit.org/documentation
>> 
>> Dojo-interest at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
> 
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
> 
> Dojo-interest at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-interest/attachments/20120501/2e044b5b/attachment.htm 


More information about the Dojo-interest mailing list