Hi,
I am new to the forums so please let me know if I should post this question elsewhere. Also, although I did search the documentation and the support site I did not come across this issue... if this has been addressed already please let me know and I will look there.
Problem
-------
Some browsers can be set to disable (and the user may not be able to change the setting due to corporate polices etc) the XHR object (and / or ActiveX controls)in these cases is there a workaround employed?
1. With IE 7 only the XHR object can be disabled
a. Separately ActiveX can be disabled as well
2. With IE 6 ActiveX can be disabled
a. Does this effect only the Dojo XHR object or the Dojo rich UI widgets (offered by digit for example) are affected as well – For example the dojo.require function will not work in IE 6 with ActiveX disabled. Is there a list available of the functionalities which work and are there any plans for developing workarounds for things that do not work?
IFrame workaround
-----------------
Dojo has an iFrame backup mechanism this can be used to workaround the disabling of ActiveX. However, the import of the iframe library has to be done manually. There are 3 disadvantages to this approach 1) The framework does not make this a transparent failover i.e. you have to have different code for xhr and iframe where you essentially want the same effect 2) the requires tag does not work even though the iFrame does 3) the output returned from iFrame object has a different data structure and needs to be parsed differently i.e. you need to understand and code in your jsp the different textarea tag and when the data is returned you need to be aware of the different structure and accommodates for it
dojo.io.iframe.send({
url: "HelloWorld.jsp",
method: "GET",
timeoutSeconds: 5,
preventCache: true,
handleAs: "text",
content: {name: dojo.byId('name').value },
load: helloCallback
});
Unit tests fail
---------------
With ActiveX disabled on Internet Explorer 6.0 unit tests fail to run on. With ActiveX enabled all (but a couple) pass.
Thank you
PS: Version of DOJO 1.0.2
You could make "builds" of
You could make "builds" of dojo which combines the resources you need into a js file that you can simply include with tags. I believe that there is a new version of writeIncludes() that also works with current versions of dojo and works by using script tags instaed of XHR calls.
Dustin
Dustin is correct: you can
Dustin is correct: you can use the custom build process to create layers you can load via explicit script tags. Or, you could do an xdomain build, which uses dynamic script tags for dojo.required code. The custom build should also inline widget templates, so that will avoid some XHR calls there.
You may still have a problem with widgets like TabContainer that have the option to load their content dynamically. That uses XHR I believe.
Dustin's reference to writeIncludes() is not applicable to Dojo 1.0+. writeIncludes was needed in pre Dojo 0.9 versions for the debugAtAllCosts feature. Dojo 1.0+ uses a different approach for debugAtAllCosts, so writeIncludes is no longer needed.
Thanks guys - about the transparent failover...
Thank you Dustin and jburke
I think as a workaround I will try out the creation of the xdomain build. I am guessing their is no standard build which deals with XHR being disabled (as you said there may be other UI widgets which would not work)
I also came across the bug #844 which speaks to this issue however, it was deemed to be an invalid bug. Is there a chance that people would reconsider this; I think this is a fairly common use case and should be dealt with in a standard way... the concern in the bug which was expressed was it would take more than the failover (i.e. you would have to wrap the XML (or other data) in HTML on the server side. I think that could be dealt with by simply having the failover disabled by default and if you choose to enable it then you are making an conscious choice. On the client side Dojo could unwrap the XML (by default).
Thanks
Documentation for generating
Documentation for generating a custom build can be found here: http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-syste...
Pulling everything you can into a layer file that is imported in a tag is the best route to go to eliminate usage of xhr to dynamically load modules. Alternatives, such as tag loading all your files individually would be very error prone and problematic.
As for bug #844:
As jburke stated, iframe is not a complete replacement for xhr. It can only do a very limited subset of what the general xhr facility provides. Plus, it requires serverside componentry to do, as jburke notes in that defect, iframe can only handle HTML wrapped content. In other words, it's very limited. Getting around those limitations requires server infrastructure and an agreed upon wrapper protocol for HTML so that the client side knows how to unwrap it. It's unlikely that the owners of the iframe and xhr code in Dojo base would consider some sort of wrap handling built in due to those issues (and concerns of code size increases. Every change in Dojo base is scrutinized for size implications and are quite often rejected because of size increase). Particularly since building a custom build of dojo + paying attention in your application code on how you load and populate widgets can bypass xhr completely. Such as for a ContentPane, you can use dojo.io.iframe() to load the content over, get a handle to the returned DOM object, then use that handle to set the content in the content pane explicitly to that content, and so on.
It can be asked of the owners, of course, and I will contact one of them to review this forum post, I'm just noting that it is unlikely to be reconsidered.
Documentation for generating
Thanks you, Jared.
I understand from the server perspective a different shell or wrapper would need to be generated. I also agree that different users may want distinct wrapper protocols, in addition, the concern about performance rings true as well (it something I am very concerned about as well since we are maintaining a high volume site). Perhaps one approach would be offer this as an optional component for which you have to do a build to include as a pre-requisite for doing the build you would be required to put in your wrapper (perhaps a default wrapper template would be given) into a specified file.
That said I think the approaches outlined here are valid workarounds. I look forward to hearing back if the owners view on this was.
Thanks,
Nauman
Nauman: I think we have a
Nauman: I think we have a workable solution available now: Use the custom build system to:
- Make an xdomain build that loads modules via script tags.
- Inline the HTML templates used by widgets.
That leaves sorting out ContentPane widgets or other widgets that use XHR to get their contents. You can instead code your app to fetch the content via your preferred IO transport (dojo.io.script or dojo.io.iframe) and then you can manually update the ContentPane widget with the content after you receive it.
Or code it so that you do not need to fetch ContentPane content dynamically, but have it in the DOM as soon as the page is loaded.
I think this will be the recommended path for now, since IE 6's percent of the market is on the down slope, and IE 7 supports a native XHR object that is not affected by the ActiveX setting. It is a point of diminishing returns to do this internally in the toolkit, given that there is a way you can manage it yourself.