Opened 10 years ago

Last modified 10 years ago

#10061 closed defect

ContentPane: non _Container widgets loaded via href get two startup events — at Version 5

Reported by: CABurt Owned by: bill
Priority: high Milestone: 1.4
Component: Dijit Version: 1.3.2
Keywords: ContentPane TitlePane Cc:
Blocked By: Blocking:

Description (last modified by bill)

With Dojo 1.3 or greater simple widgets like dojo.form.Button in a ContentPane? or a TitlePane? receive two startup events. In Dojo 1.2 they only received one.

I have a page where some of the wigets sometimes need to launch some code after startup. I've been using the startup event to launch the code, so with Dojo 1.3 and 1.3.2 the code gets run twice - which is unacceptable. I got around the issue by having the code use the Title attribute of the widjet to see if it had already been run or not.

Sample file attached. I apologize for using a local Dojo store but I can't get those !%#$@ CDN's to work right.

Change History (8)

Changed 10 years ago by CABurt

Attachment: Default.html added

ContentPane/TitlePane? startup events

comment:1 Changed 10 years ago by bill

Resolution: invalid
Status: newclosed

This test case doesn't even create any widgets, because it's missing dojo.require("dojo.parser");.

This line is also incorrect:

<script type="method" event="startup">

I think you wanted to say type="dojo/method", otherwise the alert won't fire at all. But that's also bad because you aren't allowed to override the startup method. dojo/connect is correct.

After changing both of those things, the test case works fine. No double startups.

I'll attach a corrected version of the test case.

Changed 10 years ago by bill

Attachment: Default.2.html added

corrected errors in test case

comment:2 Changed 10 years ago by CABurt

Thank-You! I clearly have much to learn! For others like me who are hazy on when to use dojo/method or dojo/connect there is an excellent article at:
http://docs.dojocampus.org/quickstart/events#overriding-vs-connecting

Changed 10 years ago by CABurt

Attachment: href Loading.zip added

href startup events

comment:3 Changed 10 years ago by CABurt

Resolution: invalid
Status: closedreopened

dojo/connect works great - except when a ContentPane? is loaded via an href. Href loaded widjets receive two startup events.

sample code included (href Loading.zip)

comment:4 Changed 10 years ago by bill

Component: EventsDijit
Milestone: tbd1.4
Owner: changed from sjmiles to bill
Status: reopenednew
Summary: ContentPane and TitlePane widjets get two startup eventsContentPane: widgets loaded via href get two startup events

Ah good point, looks like the parser called when the href is loaded (via ContentPane --> html.js) is doing one startup() call, and then ContentPane itself is doing another since it's acting as a container widget.

I'll remove one of them.

comment:5 Changed 10 years ago by bill

Description: modified (diff)
Summary: ContentPane: widgets loaded via href get two startup eventsContentPane: non _Container widgets loaded via href get two startup events

The problem is actually limited to non-_Contained widgets (ie, widgets w/out a getParent() method).

Notes to self:

  • I'd like to pass in a flag to the parser to not call startup() on any of the widgets, deferring that job to ContentPane, but that might cause problems for popup widgets like Menu and Dialog that reposition themselves outside of the ContentPane.
  • Alternately, it would be nice to disable the startup() calling code in ContentPane when the parser is turned on (ie, when parseOnLoad == true), but then would need to modify the parser's behavior to call startup() even on widget's whose parent is the ContentPane.
  • Performance: there's a lot of inefficiency in startup processing. The parser ends up calling getParent() for each widget w/a startup() method (which is all widgets, since startup() is defined in _Widget.js now) and a getParent() method, even though the parser could easily keep track of the parent-child relationship of all widgets if it did top down processing instead of calling dojo.query(). And each layout widgets calls getParent() again to decide whether startup() should call resize() or whether it should wait for a resize() call from it's parent widget.
Note: See TracTickets for help on using tickets.