Opened 13 years ago

Closed 11 years ago

#10137 closed enhancement (wontfix)

_Widget should have a method for creating "threads"

Reported by: Phil DeJarnett Owned by: bill
Priority: low Milestone: future
Component: Dijit Version: 1.3.2
Keywords: Cc:
Blocked By: Blocking:


I frequently need to execute small blacks of code after the current execution block (like parsing) is completed. I liken these to threads, because they help reduce the amount of time the browser is locked up executing code without a visual update.

The scope of this code is almost always a widget.

It would be very handy to have a simple method (I was thinking called queue(method, timeout), but there may be a better term) that defaults to executing 100ms later, but can be longer. The function passed in executes in the same scope as the widget.

For example:

_Widget.prototype.queue = function(method, timeout) {
    // compare with undefined to allow 0ms timeouts
    if(timeout === undefined) {
        timeout = 100;
    return setTimeout(dojo.hitch(this, method), timeout);

Then the usage would be:

startup: function() {
    // handle start up like normal
    // ...
    // queue remaining startup
    this.queue(function() {

In this example, the download should be started after everything is loaded. I like the cleaner format because it reminds me of GrandCentral? threading. It also prevents creating temporary objects to represent this. For comparison, the current method would usually look like this:

    setTimeout(dojo.hitch(this, function() {
    }), 100);

Where it really pays off in readability is simple methods like this:

this.queue(this.updateCheck, this.updateRate);
// vs:
setTimeout(dojo.hitch(this, this.updateCheck), this.updateRate);

Note that this.queue has the same number of characters as setTimeout, so there are no extra characters added even compared to the simplest of delayed execution calls.

The reason it makes sense in _Widget is that there are a lot of _Widgets that have heavy processing during initialization, but might be better to put off until after startup is complete. It also will reduce some of the 86 setTimeouts throughout the dijit codebase, and what appears to be over a hundred more in dojox.

This method could possibly even be useful as a core dojo extension, taking the parameters (scope, method, timeout). I'm currently experimenting with using it, and it has a lot of benefit when used like:

dojo.queue(obj, obj.method);

Change History (3)

comment:1 Changed 13 years ago by bill

Milestone: tbd1.5
Owner: set to bill

Let me think about / look into this for 1.5. As you said, maybe it would simplify the existing dijit code.

comment:2 Changed 12 years ago by bill

Milestone: 1.5future

comment:3 Changed 11 years ago by bill

Resolution: wontfix
Status: newclosed

Closing this for now, because I haven't heard other requests for it and I don't see it being used within dijit itself.

Note: See TracTickets for help on using tickets.