Opened 14 years ago
Closed 13 years ago
#2468 closed defect (wontfix)
Change build an loader behavior for dojo.requireIf() vs. dojo.requireAfterIf()
| Reported by: | James Burke | Owned by: | James Burke |
|---|---|---|---|
| Priority: | high | Milestone: | 1.0 |
| Component: | Loader | Version: | 0.4.1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
Technically, dojo.requireIf includes should put the module resource from the requireIf directly in the place of the dojo.requireIf() call, where dojo.requireAfterIf() should load the module resource after the current module resource.
Currently in the build system, loader_xd.js and in browser_debug.js, requireIf is treated like requireAfterIf(). It might be difficult to solve this for browser_debug.js, but look at possibilities for the build system and loader_xd.js.
It would mean in the xdomain case, splitting the top resource into two different calls to the dojo.hostenv.packageLoaded(). This might be weird though because that means two different scopes, where in the source file, it would have assumed one scope, so make sure to set the scope correctly.
Change History (2)
comment:1 Changed 13 years ago by
| Milestone: | 0.9 → 1.0 |
|---|
comment:2 Changed 13 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
I'm closing this as as a wontfix. The xdomain loader is already chunky, and this seems to be a practically non-existent use case in the real world.
This is a very technical edge case I'm trying to patch here. In practice, treating dojo.requireIf calls like dojo.requireAfterIf calls seem to be fine for the normal uses of requireIf. And I don't like how much possible code change this could be Pushing to 1.0, but may even punt it for that release.