Lazy-loadable dojox.mobile.Opener

[ykami]

The Opener widget can be used to pop up a widget such as Calendar, SpinWheel, ColorPalette, etc. Those content widgets, however, have to be loaded up front regardless of whether the user really uses them or not. Lazy-loading technique, which IconContainer already supports, should improve the start up performance by not loading the content widgets until they are opened by the user.

[ykami]

Doug, what do you think?

[Douglas Hays]

Thoughts...

• can this.lazy and this.requires be combined into a single attribute?
  
• if show() is called then lazy is not set to false until the when function fires, but maybe that should go before when() to prevent multiple when() calls
  
• I thought the dojo parser would search out and instantiate the dojoType widgets at load time even if they were children of another widget. How is this being avoided?
• I'd like to see a programmatic example in the tests to make sure that works

[ykami]

Thank you for the comments.

Replying to doughays:

• can this.lazy and this.requires be combined into a single attribute?
  

IconItem has this API since dojo-1.5. I don't think we should change this unless there is some particular reason. Note that requires is seldom used in practice. It is used only when you want to load specific modules that are not in the widgets' deps chain.

• if show() is called then lazy is not set to false until the when function fires, but maybe that should go before when() to prevent multiple when() calls
  

If we do so, obviously the second show() fails since the content is not ready yet. Multiple when() calls is harmless and safer I think.

• I thought the dojo parser would search out and instantiate the dojoType widgets at load time even if they were children of another widget. How is this being avoided?

Quite simple. Temporarily rewriting dojoTypes.

• I'd like to see a programmatic example in the tests to make sure that works

You could do like this:

var opener = new Opener({onHide:getDate2, onShow:setDate2, lazy:true}, "calPicker");
domConstruct.create("div", {dojoType:"dijit.CalendarLite"}, opener.domNode);

[Douglas Hays]

When lazy=true, then requires is truthy and when lazy=false, then requires is !truthy. My point is that you could do away with lazy (you wouldn't even need to deprecate it) and no one would be regressed and the API would be simpler.

[ykami]

Well, sorry perhaps my explanation was insufficient. Almost all the cases, users use only the lazy="true" option. lazyLoadUtils knows what modules to load by looking at dojoType. 'requires' is basically unnecessary in usual use cases. Exception is when you need to load missing _base modules. That could happen, at least in older dojo, when you do customBase build and widgets have no explicit deps list for the _base modules. This may not happen with newer dojo even in the sync loader mode any longer, but users may have old widgets or want to use it for other purposes, which I don't know.

[Douglas Hays]

OK, that makes sense. I don't have any objections, except I'd like to see the programmatic example in the test file.

[ykami]

In [27854]:

Fixes #14733 !strict Added lazy-load feature to Opener and its test cases.

[ykami]

doughays, regarding the multiple when() calls, after doing some tests, I realized you were absolutely correct, and I was wrong. I fixed the patch as you suggested. Thank you.