Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#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: justicejiang@…; freemanlong@…
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)

testcases.rar (1.3 KB) - added by guest 12 years ago.
errors.zip (59.4 KB) - added by guest 12 years ago.
working.zip (1.6 KB) - added by bill 12 years ago.
this example fixes the duplicate widget id problem and works on IE and FF

Download all attachments as: .zip

Change History (12)

comment:1 Changed 12 years ago by guest

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.

comment:2 Changed 12 years ago by bill

Please attach testcase using the "attach file" button.

Changed 12 years ago by guest

Attachment: testcases.rar added

comment:3 Changed 12 years ago by guest

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 12 years ago by bill

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 12 years ago by guest

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 12 years ago by guest

Attachment: errors.zip added

comment:6 Changed 12 years ago by bill

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 12 years ago by guest

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 12 years ago by bill

Resolution: invalid
Status: newclosed

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 12 years ago by bill

Attachment: working.zip added

this example fixes the duplicate widget id problem and works on IE and FF

comment:9 Changed 12 years ago by guest

Oh, that's it!! Sorry for my mistake and making so much trouble to you.

Note: See TracTickets for help on using tickets.