Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#14381 closed defect (invalid)

Switching off "dojo-sync-loader" breaks XHR in compiled builds?

Reported by: Aleksey Rechinskiy Owned by: Rawld Gill
Priority: high Milestone:
Component: Loader Version: 1.7.0
Keywords: xhr, loader, has Cc:
Blocked By: Blocking:

Description

Hi!

I tried to build minimalistic dojo-AMD loader and played with 'dojo-sync-loader' option. If one to set in a profile

staticHasFeatures: {
	'dojo-sync-loader':0,
}

then a big bunch of code in dojo.js starting from line 202 to line 284 is completely eliminated by has("dojo-sync-loader")->0. This code amongst other things defines function require.getXhr() that becomes undefined in that case. Looks like it is the only place in dojo's code, where require.getXhr() is defined.

require.getXhr() function is used in dojo/_base/xhr.js line 15 to define dojo._xhrObj

if(has("dojo-xhr-factory")){ // set to 1 by default build profile.
	dojo._xhrObj = require.getXhr;
}

And dojo._xhrObj is used later in dojo.xhr() to create XHR transport object.

So, looks like any build with 'dojo-sync-loader' disabled crashes on any attempt to use xhr machinery...

Change History (4)

comment:1 Changed 8 years ago by Rawld Gill

In [27246]:

added profile to demonstrate AMD build; refs #14381

comment:2 Changed 8 years ago by Rawld Gill

Resolution: invalid
Status: newclosed

If you look at the top of dojo/_base/xhr.js, you'll see that the module handles the case when dojo-xhr-factory is falsy correctly. I added profile util/buildscripts/profile/amd.profile.js (which doesn't include the sync loader) to build a dojo.js to contain only the AMD loader and then for dojo/main to contain all of "base" dojo (including the lite query engine). I then verified that dojo.xhrGet works correctly with the build consequent to that profile.

comment:3 Changed 8 years ago by Aleksey Rechinskiy

I was not sure it's safe to turn off dojo-xhr-factory.. The profile is very helpful, thank you very much for quick responce!

comment:4 Changed 8 years ago by Aleksey Rechinskiy

By the way, could you please tell a little bit about the following things related to the new profile?

Please, look at following use case: I want to build small AMD loader AND to include dojo/on in it - lets name this layer as 'dojo.js'. And I want to make a second layer with main application code - "app/main". Here is how I organize 'layers' parameter:

,layers : [
		{
			name: "dojo.js",
			customBase: true,
			dependencies: [ 'dojo/on' ]
			//include: [ 'dojo/on' ] //include won't bake 'dojo/on' into resulting file!
		}
		,{
			name : "../app/main.js",
			dependencies : [ "dojo/selector/lite","app/main" ]
			//,include:["dojo/selector/lite"]
			,layerDependencies: [
				"dojo.js"
			]
		}
	]

Questions:

  1. What's the point of dojoBootText:"require.boot && require.apply(null, require.boot);" parameter, specified in amd.profile.js?

Even though 'dojo/on' in baked into the resulting dojo.js file (I can verify it by inspection and build-report.txt tells the same), nonetheless, require('dojo/on') issues special http request that fetches dojo/on.js from server. I have spent a lot of time to find out, that the undocumented dojoBootText param is actually responsible for that. What's the point of that param?

  1. What's the point of has(' dojo-sniff ') parameter?

When it is off, it's impossible to load any additional modules via require(), because its http requests are relative to current document.location. If document.location is '/news', than require('app/main') would be issued to /news/main.js, instead of /js/app/main.js. Even require('dojo/on') would make a request to /news/on.js, instead of /js/dojo/on.js Is it a normal behavior? require() looks almost useless in that case, but why it still exists?

Note: See TracTickets for help on using tickets.