#5309 closed defect (invalid)
Dialog setContent doesn't trigger the parseOnLoad step
Reported by: | guest | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Dijit | Version: | 1.0 |
Keywords: | Dialog | Cc: | [email protected]…; [email protected]… |
Blocked By: | Blocking: |
Description
When I using the setContent() method to refresh the content of a Dialog, I found the widgets of the content will not be parse normally. But if I use the setHref method, it works properly. It might be the design problem, cause I found the Dialog widget do something before and after the setContent method so that only the _downloadExtralContent() could work but the setContent method not.
Please fix this problem so that user can load the content by himself using specific program.
Attachments (3)
Change History (12)
comment:1 Changed 13 years ago by
Changed 13 years ago by
Attachment: | testcases.rar added |
---|
comment:3 Changed 13 years ago by
I'd attached a testcase in the attachment.
The 2 examples are having different problem to ComboBox? widget. test1.htm shows that widgets inside a form will not be rendered normally in an inner ContentPane? (in fact I'd tested with other form widget, they are not rendered either, you can have a try yourself). test2.htm shows that when you load an widget in a ContentPane? inside another ContentPane? widget, it would be disappear once it's loaded.
Please help to solve the problems, thanks.
comment:4 Changed 13 years ago by
Looks to me like it's working, and just that you don't include tundra.css so the display is all messed up. I tried adding that and it worked fine for me, at least on FF.
PS: not to be picky but in the future please attach things as zip files, because rar support isn't built in to PC's or Mac's. Thanks!
comment:5 Changed 13 years ago by
OK, I'll be caution about the attachment's type next time.
I'll give you my test environment: IE 6.0.2900.2180.xpsp_sp2_gdr.070227-2254 FireFox? 2.0.0.7 dojo release 1.0.1
For I.E. ===================================================================== In LoadTest1.htm,when I pressed the submit button, the combobox changed into a normal select item like the attachment pic1.jpg.
In LoadTest2.htm,pic2.jpg shows that once the inner pane is loaded, the ComboBox? will disappear.
For FF ==================================================================== In LoadTest1.htm, pic3.jpg tells that once the submit is pressed, the ComboBox? even disappear. LoadTest2.htm testcase can be run normally in FF.
Could you try another time following my steps? By the way, the test pages should be put at the root folder where puts the dojo tools.
Changed 13 years ago by
Attachment: | errors.zip added |
---|
comment:6 Changed 13 years ago by
Milestone: | → 1.1 |
---|
Hi.
LoadTest1.htm: Looks like pressing the button is submitting the form and reloading the page so that's why the content is disappearing on FF. IE is doing something stranger, but still, it's because the page is reloading. You can notice the reload easily on firefox because the URL bar changes a little.
IE/LoadTest2.htm: yup, I just reproduced this on IE6. It's fixed in trunk with the conversion of input widgets to use <div> rather than <table> in their templates.
comment:7 Changed 13 years ago by
Thanks to your improvement.
I do know it'd been refreshed, but it's very odd looking in IE for the view before submitting is a beautiful combo box, but after submitting it becomes to the original select box.
This would only happen when you try to reload a ContentPane? or its children within another ContentPane?. I'd changed the code from submitting a form to just change the view by a direct link, it also happened.
comment:8 Changed 13 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Looks like a test error to me. I uncommented your code for submitForm(). It does a
dijit.byId("innerDiv").setContent("... dojoType=innerDiv ...");
which fails because you can't have two widgets with the same ID.
I'm attaching the corrected files which seem to work fine on IE and FF.
Changed 13 years ago by
Attachment: | working.zip added |
---|
this example fixes the duplicate widget id problem and works on IE and FF
comment:9 Changed 13 years ago by
Oh, that's it!! Sorry for my mistake and making so much trouble to you.
I could tell something more about this bug now.
I found if the content of a ContentPane? like widget content another ContentPane? like object ,the child(ren)'s widget won't be parsed.
I hope this could help you fix this bug more easier, and I have tested all the ContentPane? and its subclass widgets they all have the same problem. The priority to this bug might need to be upgraded to a higher level I think.