Opened 15 years ago

Closed 14 years ago

#1655 closed defect (fixed)

debugAtAllCosts eliminating need to call writeIncludes()

Reported by: jkuhnert Owned by: James Burke
Priority: high Milestone: 1.0
Component: Loader Version: 0.4
Keywords: Cc:
Blocked By: Blocking:


Since setting debugAtAllCosts presumably loads a special debug js file into the system I propose that that file override the relevant function(s) in dojo.hostenv_browser to automatically load everything into <head><script></script></head> blocks automatically instead of making you call dojo.hostenv.writeIncludes().

The ability to set this config option is actually "awesome" to have, but the requirement for manually calling writeIncludes feels a little dirty. It also becomes unwieldy on large dojo based applications where extraneous dojo.require() statements on widget code not often used bogs the whole system down.

Change History (8)

comment:1 Changed 15 years ago by James Burke

My understanding of this is the following: writeIncludes is needed because Dojo needs to know when you are done doing dojo.requires() and start to write out the script tags. The script tags need to be written out before the document loads so that the script tags execute in the order they are written.

We cannot just write out the script tag as soon as they do a require, because most modules depend on other files (specified by dojo.require() calls in the module), and those dependencies need to be loaded before the resource for the module is loaded.

If we don't have writeIncludes as a trigger to do the final output of all the script tags sorted by degree of dependency, then the only other trigger I can think of is waiting for document load (or DOMContentLoaded, as used by dojo's addOnLoad() mechanism).

The problem with document load is that you can't use document.write, but have to do head.appendChild() instead. However, with that approach, you are not guaranteed across browsers that the scripts will execute in the order that they were added to head.

Perhaps now that we use DOMContentLoaded, we could still document.write() out the tags instead of having to use head.appendChild(), but I am doubtful that will work. To me, "DOMContentLoaded" means that the DOM is ready to go and if you do a document.write() it would likely wipe out the current DOM. But something to try, since I can't say for sure and have not tried it.

Another option would be to use an xdomain build: it uses script tags to load packages, and it has smarts to deal with the head.appendChild() load order issue. Unfortunately, it has this smarts because during the build process, the resource files are modified so that they do not execute the module definitions right when they load, but register with the xd loading system. The xd loading system figures out the dependency graph, and executes functions that define the modules in the correct order. So, the end result means you would have to do a custom build each time you want to test, which is not the best development experience.

So, I don't see a good way around writeIncludes(). But I could be missing something. The nice thing about it is that it only has to appear once, after the last dojo.require() statement in the top level page, and it is a no-op if debugAtAllCosts is false.

Also, I vote that this bug be pushed to 0.5 at the earliest. This seems like more of an enhancement than a bug fix.

comment:2 Changed 15 years ago by jkuhnert

Hmmmm good points. I'll have to think about this some more. I'm not against it being a 0.5 / whatever goal. I just wanted to be sure I remembered to log this before I forgot.

The biggest secondary problem with this is that widgets loaded subsequently to the original page load that weren't dojo.require'd don't get the benefit of having writeIncludes() used. See what I mean? What if the original page doesn't have a require for every possible file being used? I have actually done a bit of document head script loading in other projects so have a dim understanding of the problems you outline, but not enough to provide anymore insight without really digging in and playing with things..

P.S. I'm not sure why this got auto-assigned to Alex. That must be torture for the poor guy at this point ;) (now that I'm getting a taste of the very bottom of the os proj hectic schedule effect I can't imagine what it must be like for those at the top. bleh =p )

comment:3 Changed 15 years ago by James Burke

Thinking more about it, maybe it would work if for each require, the dependencies were found right away and the script tags get document.write() out right at that point. Maybe that would work for normal, explicit dojo.require() statements.

But I don't think that will help the situation you described, when widgets are parsed out of the page and get auto-required as they are found. This step happens during DOMContentLoaded. Probably worth trying the document.write() to see if it will work, but I expect it will not.

comment:4 Changed 15 years ago by jkuhnert

Owner: changed from alex to James Burke

I'm going to re-assign to you as you seem like the more obvious taker for this. (Though of course feel free to re-assign to whoever if you don't agree).

I may be being ignorant of more subtle things going on but I use this method currently to include external js dependencies.. It's actually pretty obviously "fragile" and I intend to replace it with something better in the next couple weeks with something more deterministic.

Either way, I think if a solution can be found that works a good 90% of the time or so we might be able to "call it good" since it's implied fragileness with the whole "debugAtAllCosts" right? (one of those costs being potentially broken/fragile use cases ;) ? )

comment:5 Changed 15 years ago by bill


comment:6 Changed 15 years ago by James Burke

Tom brought up on the contributor mailing list that debugAtAllCosts does not work with requireIf. Part of the issue is that some modules, like Chart, use dojorequireIf? syntax instead of using the normal dojo.requireIf syntax. This is done to get around a build system deficiency, but browser_debug.js should be improved to recognize the alternate syntax.

comment:7 Changed 15 years ago by James Burke

Another issue Tom ran across was requireIf not seeming to work with Opera 9.

comment:8 Changed 14 years ago by James Burke

Resolution: fixed
Status: newclosed

This should be fixed with the revision(s) in #3583. It should work with Opera since it uses the xdomain loader. There is some additional xdomain loader change to support sophisticated dojo.requireIf() usage, but that is being tracked in #4462.

Note: See TracTickets for help on using tickets.