Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#14459 closed defect (fixed)

[regression] Cannot load a local module alongside xd dojo using legacy APIs

Reported by: kgf Owned by: rcgill
Priority: blocker Milestone: 1.7.2
Component: Loader Version: 1.7.0
Keywords: Cc:
Blocked by: Blocking:

Description

I've been trying to arrive at a workable solution to suggest on the reference-guide section regarding CDN usage with local modules as well as the existing tutorial at http://dojotoolkit.org/documentation/tutorials/1.6/cdn/.

I've attempted the following, loosely based on the demo on that cdn tutorial...

Given this:

    <script data-dojo-config="
          baseUrl: './',
          modulePaths: {custom: 'custom'}"
        src="http://ajax.googleapis.com/ajax/libs/dojo/1.6/dojo/dojo.xd.js"
        type="text/javascript">
    </script>

I have changed it to this:

    <script data-dojo-config="
          packages: [ { name: 'custom', location: location.pathname.replace(/\/[^/]+$/, '/custom') } ]"
        src="http://127.0.0.1/dojo/dojo-release-1.7.1rc2/dojo/dojo.js"
        type="text/javascript">
    </script>

This is the same kind of formula applied here, which seems to work in async: true cases. Unfortunately I'm not having so much luck when attempting to make it work with legacy code.

With the change mentioned above, I get a dojo.declare mixin error, because the code in the custom module attempts to declare an extension to dijit.Dialog, but while dijit is defined, dijit.Dialog is not. It would seem as though this module is getting its dojo.require calls run in async mode, even though it is on the same domain. For what it's worth though, I don't see a script tag generated for it as with the other xd-loaded modules.

I'm attaching a zip with test.html and custom/Hello.js, which should be enough to reproduce this, although you'll have to finagle the path to a cross-domain location of Dojo 1.7.1 RC2.

I'm assigning this as milestone 1.7.1 initially. While I'd love to see it fixed for 1.7.1, let me know how much effort you think it'd involve first; I don't mean to be a slave-driver. (If it ends up being my own PEBKAC and there's a way around it, that'd be great too.)

Attachments (2)

cdnlocal.zip (1.2 KB) - added by kgf 6 years ago.
app.php (708 bytes) - added by Slavon 4 years ago.
http://pndsorethroatby.tumblr.com/

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by kgf

comment:1 Changed 6 years ago by rcgill

This error can be reduced as follows:

  1. Build dojo using the standard profile.
  2. Put the following two files in the dtk directory:

t.html

<html>
  <head>
    <script 
      data-dojo-config="paths:{m: '/dev/dtk/m'}"	
      src='http://127.0.0.1/dev/dtk/release/dojo/dojo/dojo.js'
      type="text/javascript">
    </script>
    <script>
      dojo.require("m");
    </script>
  </head>
</html>

m.js

dojo.require("dijit.Dialog");
var test = dojo.declare([dijit.Dialog], {});
  1. Load t.html using localhost to simulate loading dojo xd (something like http://localhost/dtk/t.html)

You'll see that dijit.Dialog is not defined when it's referenced on the second line of m.js. This is because m.js is local and therefore loaded synchronously and then evaluated. The loader doesn't understand it's needs a cross-domain module until it starts evaluating m.js, but by then it's too late to stop evaluation to prevent the error.

comment:2 Changed 6 years ago by kgf

  • Milestone changed from 1.7.1 to 1.7.2
  • Version changed from 1.7.1rc1 to 1.7.0

comment:3 Changed 6 years ago by rcgill

  • Status changed from new to assigned

comment:4 Changed 6 years ago by csnover

  • Priority changed from high to blocker

Bumping priority due to surprisingly high complaint volume.

comment:5 Changed 6 years ago by rcgill

  • Resolution set to fixed
  • Status changed from assigned to closed

In [27763]:

fixes #14459; update some tests; see ticket; !strict

comment:6 Changed 6 years ago by csnover

  • Resolution fixed deleted
  • Status changed from closed to reopened

Confirmed fix works on trunk; reopening to make sure this gets backported to 1.7 branch. Thanks Rawld for your hard work getting this taken care of.

comment:7 Changed 6 years ago by rcgill

version 1.6- seemed to have the ability to switch into and out of xdomain mode when dojo was loaded xdomain. This is indicated by the behavior of the switch dojo._isXDomain and the configuration variable dojo.config.useXDomain in 1.6.x.

The v1.7 loader implements this behavior. However...

  • the 1.6- loader, in fact, never implemented/tested/documented/employed this behavior fully as evidenced by the switch useXDomain being undocumented and always hard set to true by the following code that is inserted into a xdomain build in v1.6-
    if (typeof dojo.config["useXDomain"] == "undefined") {
    	dojo.config.useXDomain = true;
    }
    

In fact, hard setting this is required to make the use case above and the tutorial work and great care must be taken if the switch useXDomain is to be set other than true.

The repair committed in [27763] causes the default behavior of the 1.7 loader as built for a CDN to behave like the 1.6 loader in that *all* resources will be loaded in xdomain mode.

  1. The has feature test "dojo-cdn" has been added to properly resolve the xd path; this replaces the 1.6 build switch xdDojoPath which does not exist in 1.7. The loader has been modified to automatically set the package location property for dojo, dijit, and dojox iff the has feature dojo-cdn is truthy.
  1. a cdn profile has been added at utils/buildscripts/profiles/cdn.profile.js which sets async to "legacyAsycn" (which permanently puts the loader is xdomain mode) as well as sets the has feature "dojo-cdn" to truthy.
  1. The CDN build shell script has been augmented to include the cdn profile *as well as* the standard profile.

Notes:

  • The procedure for building dojo for CDN distribution has not changed...use util/buildscripts/cdnBuild.sh
  • a user config can still override all of this default configuration.

comment:8 Changed 6 years ago by rcgill

  • Resolution set to fixed
  • Status changed from reopened to closed

In [27781]:

backport [27773]; fixes #14459; !strict

comment:9 Changed 6 years ago by rcgill

In [27782]:

fixed whitespace change improperly committed in [27781]; refs #14459; !strict

Changed 4 years ago by Slavon

Note: See TracTickets for help on using tickets.