Opened 10 years ago

Closed 10 years ago

#15993 closed defect (wontfix)

Dijit needs to ensure that widget startup() is being called

Reported by: Randy Hudson Owned by: bill
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.8.0
Keywords: Cc:
Blocked By: Blocking:


The architecture and design of dijit makes it way too easy for consumers of widgets to forget to call startup() on widgets constructed programmatically. As a result, consumers of widgets complain when a widget they previously using changes in a way that it now requires its startup function to be called.

Of course, it's perfectly valid for a widget to assume that consumers are using it properly, and that startup() is called at some point after the widget's DOM is part of the document.

But consumers rarely use widgets properly due to multiple architectural issues in Dijit. Dijit can be improved in two ways:

1) Dijit should help by calling startup() for you more often. One way would be to provide API for adding (and removing) a constructed widget into another widget's DOM. If that widget is already started, call startup, otherwise keep track of it so that it can be started recursively later. Clients should NOT have to do two steps: 1 - dom insertion, 2- call startup(). Often, the second step isn't even an option because the enclosing widget might still be detached from the document. I realize that if the widget is a _Container and addChild is used, things sort of work. But there are plenty of widgets that are containers yet don't inherit from _Container (for example, dijit.Dialog).

2) The number of widgets that rely on startup() is relatively small, which allows consumers to get away with being lazy too often. Dijit should punish incorrect use more often by increasing the number of things which don't happen until startup() is called. For example, maybe hooking DOM event listeners (e.g., when parsing a widgets template) doesn't make sense unless a widget's DOM has been attached to the document.

Change History (3)

comment:1 Changed 10 years ago by bill

I'm pretty sure that Dialog.startup() and anything else extending ContentPane will automatically call startup on its children. Have you seen different results?

comment:2 Changed 10 years ago by ben hockey

fwiw, i typically have one call to startup in my whole app when programmatically creating widgets. dijit does a very good job of calling startup on contained widgets.

as for point 2... i'm concerned that this could penalize performance. if you consider my case where i have one call to startup, there are potentially 100's of widgets all being started at that point. even though DOM event listeners aren't useful until a widget is attached to a document, it makes sense to do them as soon as they have their DOM available so that this processing load can potentially be distributed during times when i might possibly be waiting on the DOM to be ready or for files to finish loading - this is as close as we get to parallel processing in the browser. if any more of these actions are deferred until startup is called then i'd expect we will likely see performance degrade. i already perceive startup as a bottle neck with all the layout operations that happen during that time - the last thing i'd like to see is even more interaction with the DOM.

that being said, if i'm wrong about performance degrading then i'd be in favor of deferring more to startup but i just don't see that being the case.

comment:3 Changed 10 years ago by bill

Resolution: wontfix
Status: newclosed

I tend to agree with @neonstalwart. I agree it's easy to forget to call startup(), but it seems like the cost of protecting against that is too great. So marking as wontfix for now.

Note: See TracTickets for help on using tickets.