multi-version creating a global dojo as a date object

[lee]

I'm not sure if this is even a bug but thought I'd raise it to confirm. I'm doing a tutorial for multi-version usage and found some strange behaviour, I'm not sure if my packageMap configuration is actually legal or not.

What I wanted to investigate is whether it's possible to renamespace all packages i.e. no default dojo/dijit/dojox packages and use 2 versions of packages named e.g. dojo17/dijit17/dojox17 and dojo18/dijit18/dojox18 (and then have declarative code parsing for those scopes).

I'm using noGlobals but what I've found is with my attached testcase a dojo18 global is created but it's value is a date object. Initially I thought this was due to date/locale and found a bug I thought might be related #16401 however I don't know enough about the machinery so would appreciate eyes on this to tell me if my package config is valid or if this is a bug.

I've attached 2 tests, the bothamdwithwatch.html is using a polyfill for the watch property as I wanted to track what was setting the variable. This test doesn't create the dojo18 variable. I've some console logging to show when the var is created.

---

I've also found another problem which I'll add as a separate bug but.. I started off using the map configuration (instead of packageMap) but could not get both packages to have separate scopes. It created a dojo18 scope but the 1.7 version was always dojo so when parsing widgets I'd have to use dojoType rather than dojo17Type

[lee]

dojo18 global as a date object created

[lee]

no global dojo18 added

[bill]

Very strange, no idea why you would get a Date object. If you find out where it's being created let us know.

[lee]

I started debugging in FF using native watch and it's dojo/_base/lang.getProp() doing the setting, like neonstalwart said in #16401

the stack chain is

//dojo/_base/lang
context = context || (p in dojoGlobal ? dojoGlobal[p] : (create ? dojoGlobal[p] = {} : undefined));

//dojo/_base/lang
var parts = name.split("."), p = parts.pop(), obj = getProp(parts, true, context);

//dojo/date/locale
lang.setObject(module.id.replace(/\//g, "."), exports);

Where p is 'dojo18' therefore dojoGlobal[p] creates a global named 'dojo18'. locale seems to be assuming global, is localisation "re-namespaceable"?

[bill]

Good idea. I still don't see how dojo18 gets set to a *Date* object though.

[lee]

Apologies I should've explained better, it's not a date object. It's an object named date which is an instance of date/locale e.g.

dojo18
    Object { date={...}}
    date
        Object { locale={...}}
        locale Object { _getZone=function(), format=function(), regexp=function(), more...}
        _getDayOfYear function()
        _getGregorianBundle function()
        _getWeekOfYear function()
        _getZone function()
        _parseInfo function()
        addCustomFormats function()
        format function()
        getNames function()
        isWeekend function()
        parse function()
        regexpfunction()

[bill]

I think what's happening is that dojo18 is getting set to a hash that contains a key called date. So user code, instead of doing dojo.date._getDayOfYear(), it would call dojo18.date._getDayOfYear(). This is not so strange.

Also, are you sure dojo18 is a real global? Can you access it from the console?

[lee]

Yes it's on the window object (see the test) console.log(windowconsolestr + '5', window.dojo18); It's definitely because of dojo/date/locale (a dependency of CalendarLite?), I'm just struggling a bit to understand the lang.getProp method.

An empty object named "dojo18" is added in lang.getProp at: return obj && p ? (obj[p] = value) : undefined;

A date property is added at lang.getProp at: context = (p in context ? context[p] : (create ? context[p] = {} : undefined));

Then I think the locale property is set in lang.setObject at: return obj && p ? (obj[p] = value) : undefined;

[Rawld Gill]

I'm not sure exactly what the example was demonstrating, but some of the machinery used is deprecated. So rather than try to debug the example (which I greatly appreciate as a starting point!!), I've modified it to use current machinery...and to make it work. See attached. Note that I did not use the parser. I'm not sure how the parser handles mapped modules. If this is an issue, please reopen with a reduced case that shows the parser is failing.

Please have a look at ​http://trac.dojotoolkit.org/browser/dojo/dojo/trunk/tests/_base/loader/coolio for an explanation of old multi-version support...which is *highly* discouraged.

As of 1.8, AMD adopted bdLoad/dojo package mapping, albeit under the loader configuration variable "map". See ​https://github.com/amdjs/amdjs-api/wiki/Common-Config. packageMap is deprecated as of 1.8.

[Rawld Gill]

modified example

[lee]

Ok that's fine, it won't work with 1.7 though

This is a bit of a moot issue as once 1.9 is RC i'll be ignoring 1.7 but, _base/kernel for 1.7 expects packageMap whereas _base/kernel for 1.8 uses map.

Is your direction to use packageMap config for each 1.7 package if you are multi-versioning with 1.7, or is it better to pass in scope config to the parser e.g. parser.parse('dojo17node', {scope:'dojo17'});

I'd hope map config doesn't change for dojo 2.0 as personally I feel multi-version is problematic enough in all versions of dojo currently