Opened 13 years ago
Closed 13 years ago
#10061 closed defect (fixed)
ContentPane: non _Container widgets loaded via href get two startup events
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 )
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 !%#[email protected] CDN's to work right.
Attachments (3)
Change History (9)
Changed 13 years ago by
Attachment: | Default.html added |
---|
comment:1 Changed 13 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
comment:2 Changed 13 years ago by
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
comment:3 Changed 13 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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 13 years ago by
Component: | Events → Dijit |
---|---|
Milestone: | tbd → 1.4 |
Owner: | changed from sjmiles to bill |
Status: | reopened → new |
Summary: | ContentPane and TitlePane widjets get two startup events → ContentPane: 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 13 years ago by
Description: | modified (diff) |
---|---|
Summary: | ContentPane: widgets loaded via href get two startup events → ContentPane: 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.
comment:6 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
ContentPane/TitlePane? startup events