Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#15539 closed defect (fixed)

DOJO multiversion support. 1.7 with older versions

Reported by: lee Owned by: bill
Priority: undecided Milestone: 1.8.1
Component: Parser Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:

Description

I've asked this question on #dojo a few times and posted on dojo-interest but I don't think I have confirmation what I'm doing is both safe and supported. We have a Portal/CMS environment (typical for multiversion questions), unfortunately the existing site is stuck on 1.3 but we MAY want to cater for 1.7 portlets and progressively migrate. I've been told I'd need to "move" legacy dojo out of the way e.g. dojo13Type etc however that has a huge cost to our company.

I have a working test case where I've moved 1.7 out of the way which only required package configuration for 1.7 and passing parser configuration. This seems to work well however I don't see documentation for this or anyone on IRC agreeing this is safe.

The use case: An existing page with standard legacy dojo included also needs to use 1.7 without changing legacy code

The important points I see is appropriate package configuration for 1.7 to namespace correctly for require/define and extra parser configuration (for 1.7).

Overview: My test case configures and includes legacy first and then configures 1.7 with noGlobals:true and package configuration to namespace 1.7 for the AMD loader. When I dojo.parse 1.7 I also need to pass configuration (both scope and parserScope are needed) e.g.

parser17.parse(container, {"scope":"dojo17","parserScope":"dojo17"});

I haven't seen this documented and only discovered it through debugging.

DOJO 1.7 configuration looks like:

var dojoConfig= {isDebug: true, async: true, noGlobals:true, parseOnLoad: false,
    base: '/dojosrc/dojo-release-1.7.2-src/dojo/',
    baseUrl: '/dojosrc/dojo-release-1.7.2-src/dojo/',
    packages:[{name: 'dojo17',location: '/dojosrc/dojo-release-1.7.2-src/dojo',
            packageMap: {dojo: 'dojo17',dijit: 'dijit17',dojox: 'dojox17'}
        },
        {name: 'dijit17',location: '/dojosrc/dojo-release-1.7.2-src/dijit',
            packageMap: {dojo: 'dojo17'}
        },
        {name: 'dojox17',location: '/dojosrc/dojo-release-1.7.2-src/dojox',
            packageMap: {dojo: 'dojo17',dijit: 'dijit17',dojox: 'dojox17'}
        },
        {name: 'sl17',location: '/dojosrc/dojo-release-1.7.2-src/sl',
            packageMap: {dojo: 'dojo17',dijit: 'dijit17',dojox: 'dojox17'}
        }
    ]
};

I've attached a test case (dijitmultiversiontest.html) using dijit and the parser, obviously you'll need to change where dojo is included e.g. /dojosrc/dojo-release-1.7.2-src/. The legacy version it's using is 1.4 however it's exactly the same on 1.3.

Can the loader guru's confirm this is expected usage and safe to use, if not can you explain the issues I may face.

Thanks

Attachments (5)

dijitmultiversiontest.html (8.2 KB) - added by lee 7 years ago.
test file for multiversion support in 1.7 without namespacing legacy global dojo
dijitmultiversiontest270712_a.html (8.9 KB) - added by lee 7 years ago.
successful dojox18/dojox dojox.form.BusyButton?
dijitmultiversiontest280712_a.html (8.5 KB) - added by lee 7 years ago.
dijitmultiversiontest230812_fail.html (8.9 KB) - added by lee 7 years ago.
parse failure using slash notation in dojo-data-type for dgauge using slash notation
require.html (4.0 KB) - added by bill 7 years ago.
simplified test case for data-dojo-type with MID problem

Download all attachments as: .zip

Change History (24)

Changed 7 years ago by lee

Attachment: dijitmultiversiontest.html added

test file for multiversion support in 1.7 without namespacing legacy global dojo

comment:1 Changed 7 years ago by ben hockey

a cursory look at this seems to look ok to me.

comment:2 Changed 7 years ago by lee

I spotted a problem tonight just as I left work. I hadn't used dojox in the test case and dojox is currently undefined using a dojox class. I'll do some more debugging but was able to temporarily fix it by noGlobals:false

comment:3 Changed 7 years ago by Rawld Gill

Resolution: worksforme
Status: newclosed

Hi bod,

First, your use case is exactly one of the problems the mapping machinery in the new loader is designed to solve. So rest assured you are doing something reasonable. Just looking at it, your config looks good to me. That said, my skill set is much better at design than visual validation of code :). The proof is in the pudding. Test it and when you run up against a specific problem, please open a new, specific ticket to that problem.

Lastly, we've tried hard to make sure that dojo and dijit are "pure amd" and, therefore, relocatable with the loader mapping function. dojox support is more variable. Some projects are fully modern and will work perfectly; others, not so much.

I'm closing this ticket because I don't see a specific issue to fix.

comment:4 Changed 7 years ago by lee

Please don't close the issue rcgill. I've not had much time to get back debugging this but the use case I have above does not work. Once I started using dojox it all went to hell.

What I've done in the meantime is inform my company multiversion with pre amd dojos isnt possible, therefore one dojo per page Please reopen and I'll post the exact problems I'm seeing in dojox within the next week

comment:5 Changed 7 years ago by bill

Resolution: worksforme
Status: closedreopened

Marking as pending so bod can reopen if he has a test case. Although sounds like it's not a loader issue.

comment:6 Changed 7 years ago by bill

Owner: changed from Rawld Gill to lee
Status: reopenedpending

comment:7 Changed 7 years ago by lee

Status: pendingnew

Sorry rcgill and thanks, I never knew this had been reopened and assigned to me. I'll get the test cases with dojox in the next couple of days.

comment:8 Changed 7 years ago by lee

Just updating I've still not had time to write a proper test case yet Will do within 7 days otherwise please close

Version 0, edited 7 years ago by lee (next)

comment:9 Changed 7 years ago by bill

Status: newpending

Changed 7 years ago by lee

successful dojox18/dojox dojox.form.BusyButton?

comment:10 Changed 7 years ago by lee

Status: pendingnew

Attachment (dijitmultiversiontest270712_a.html) added by ticket reporter.

comment:11 Changed 7 years ago by lee

Apologies adding successful test cases but I want to make sure I have this properly recorded, I'm using a framework environment (portal/cms) and have reverted to static test cases so I'd like to record the steps to reproduce dijitmultiversiontest270712_a.html is a successful "dojox.form.BusyButton?" 1.4/1.8 test

comment:12 Changed 7 years ago by lee

I've cleaned up the previous test case (dijitmultiversiontest280712_a.html), what's interesting is that the 1.4 widget is being parsed properly with data-dojo-props='busyLabel:' and busyLabel:'' even though it should be data-dojo18-props

<button dojoType="dojox.form.BusyButton?" data-dojo-props="busyLabel:'Sending data...'">Send data</button>

<button dojoType="dojox.form.BusyButton?" busyLabel:'Sending data...'>Send data</button>

Last edited 7 years ago by lee (previous) (diff)

Changed 7 years ago by lee

comment:13 Changed 7 years ago by bill

Owner: changed from lee to Rawld Gill
Status: newassigned

comment:14 Changed 7 years ago by lee

I think I've eventually narrowed down the problem and you're probably right it's nothing to do with the loader. I've tried various dojox classes and all function as expected, however I think this is a dojo-data-type question. I'm on holiday from work atm plus I wanted to prove with a static test case, so I'm slightly hazy on the code where I saw this problem. I remembered using 1.8 guages where this occurred, so I used a simple declarative example from the ref guide for dojox/dgauges.

When I use data-dojo-type="dojox/dgauges/components/default/CircularLinearGauge" the failures occur, if I revert to data-dojo-type="dojox.dgauges.components.default.CircularLinearGauge?" it works.

In the provided test, clicking anywhere in the region of the guage throws an error in 1.4 dijit for the mouseDownListener event.

All my 1.8 widgets are declared using dot notation, however if I change them all to slash notation parsing fails completely. I'm more than certain this is the error I saw at work, the 1.3 version we use is actually a modified version of DOJO though I think this is unrelated.

I haven't seen any specific documentation that says slash notation should be used with 1.7+

Changed 7 years ago by lee

parse failure using slash notation in dojo-data-type for dgauge using slash notation

comment:15 Changed 7 years ago by bill

Component: LoaderParser
Milestone: tbd1.8.1
Owner: changed from Rawld Gill to bill

Complicated stuff, huh. Looks like it's just that the parser is calling the global require() when it should be calling the local one, provided by define(). I'll check in that fix. A few other modules need it too.

I don't see what this has to do with 1.7 though, since MID notation for data-dojo-type started in 1.8.

BTW since your 1.4 and 1.8 widgets are segregated into different sections (in your case, the <div id="widgets14"> and <div id="widgets18">), you could probably get away without the scope and parserScope mapping. But that's neither here nor there.

comment:16 Changed 7 years ago by bill

Resolution: fixed
Status: assignedclosed

In [29541]:

Fix for multiversion support for parser, etc. Use local require() method provided by define(), not global one. Also addresses AMD-loader compatibility, since not all AMD loaders are guaranteed to have a global require() method. Fixes #15539 on trunk !strict.

comment:17 Changed 7 years ago by bill

In [29542]:

Fix for multiversion support for parser, etc. Use local require() method provided by define(), not global one. Also addresses AMD-loader compatibility, since not all AMD loaders are guaranteed to have a global require() method. Fixes #15539 on 1.8 branch !strict.

Changed 7 years ago by bill

Attachment: require.html added

simplified test case for data-dojo-type with MID problem

comment:18 Changed 7 years ago by lee

Thanks for the fix Bill, not sure the sarcasm is warranted though. Re 1.7, this started on 1.7 but I moved to 1.8 rc1/2 as soon as I could. So you're right, this is nothing to do with 1.8 and MID notation, at least it found some type of problem though

And like I said, I'm guessing the problems I saw at work bore the same errors I saw with the static case, I'll do some digging again when I get back using trunk to make sure it's the same problem. Thanks

comment:19 Changed 7 years ago by bill

I wasn't being sarcastic, multi-version and package mapping is complicated, and things are further complicated by the scope variable for the parser. But also this ticket was confusing because IIUC it started as a question about the loader in 1.7, and then switched to a bug report about the parser in 1.8.

About data-dojo-props, it's always called data-dojo-props even when using the scope variable. It's never called data-dojo18-props.

Note: See TracTickets for help on using tickets.