Opened 13 years ago
Closed 10 years ago
#8465 closed defect (fixed)
Auto-register custom modules prefixes for xdomain builds inside of dojo.xd.js
Reported by: | Mina R Waheeb | Owned by: | Rawld Gill |
---|---|---|---|
Priority: | low | Milestone: | 1.7 |
Component: | BuildSystem | Version: | 1.2.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
When build custom dojo xdomain with param xdDojoPath the module dijit, dojo and dojox auto registered. Why not also auto-register the custom modules prefixes in the build profile.
dependencies = { layers: [ { name: "dojo.js", dependencies: [ "my.layout.TabContainer" ] } ], prefixes: [ [ "dijit", "../dijit" ], [ "dojo", "../../dojo" ], [ "dojox", "../dojox" ], [ "my", "../my"] ] }
For the above profile "my" module should be register in dojo.xd.js by the build system.
In the current trunk build system the compiled dojo.xd.js throws "Access to restricted URI denied" code: "1012" exception while loading the embedded my.layout.TabContainer? class, Also i have to note the my.layout.TabContainer? class extends dijit.layout.TabContainer? class
Change History (3)
comment:1 Changed 13 years ago by
Milestone: | tbd → future |
---|
comment:2 Changed 10 years ago by
Owner: | changed from James Burke to Rawld Gill |
---|
Bulk update to assign BuildSystem? tickets to Rawld. Many of these are probably already fixed in 1.7.
comment:3 Changed 10 years ago by
Milestone: | future → 1.7 |
---|---|
Priority: | high → low |
Resolution: | → fixed |
Status: | new → closed |
with amd this is a moot point. closing as fixed in 1.7.
if there's any disagreement, leave a comment for me to reopen the ticket or create a new one.
There are times when you want to build the xdomain dojo but actually serve your custom modules from a different path than dojo/dijit/dojox: I do this regularly where I want to use Dojo from one of the CDNs but load my code modules from another domain.
So I am not sure automatically doing it with the xdDojoPath value makes sense. It may still be possible to override it in the case I use it with a different path via djConfig.modulePaths, so maybe it works out.