Opened 7 years ago

Closed 7 years ago

#15566 closed defect (invalid)

templated widgets don't initialize supporting widgets correctly

Reported by: Randy Hudson Owned by: Randy Hudson
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.7.3
Keywords: Cc: ben hockey
Blocked By: Blocking:

Description

Given 3 simple templated widgets: test.A, test.B, and test.C, with A's template being:

<div><H1>Widget A</H1><div dojoType='test.B'><div dojoType='test.C'></div></div></div>

When a widget A is destroyed, it should destroy all of the widgets created by its template. However, C is not destroyed. This makes no sense. If C is moved so that it is outside of B, it would get destroyed.

At least in the 1.6.2 code, _Templated calls this._supportingWidgets = dijit.findWidgets(node);. This is both expensive and incorrect. Instead, _supportingWidgets should be all the widgets just returned by the call to parse.

Change History (5)

comment:1 Changed 7 years ago by ben hockey

Cc: ben hockey added

comment:2 Changed 7 years ago by bill

AFAIK this is all working according to spec, but please attach a test case demonstrating the problem you are seeing.

Note though that widgets are responsible for destroying their own children, so it shouldn't be an issue for supportingWidgets to only list top level widgets.

comment:3 Changed 7 years ago by bill

Owner: changed from bill to Randy Hudson
Status: newpending

Probably your code isn't working because for some reason your custom widgets don't have a destroyRecursive() method; apparently they don't extend _WidgetBase.

It's also worth noting that this code has changed from 1.6 to trunk. The findWidgets() call is in destroy() now.

But in any case, you'll need to attach a test case to this and every ticket.

comment:4 Changed 7 years ago by Randy Hudson

Status: pendingnew

I found one problem in my test. Widget B didn't have a div marked as an attaachpoint=containerNode, so widget C was getting created a startup was called, but then widget C simply gets lost! After I fixed B, then A destroy's B, and B destroys C. So startup() is called by A, but destroy() is called by B.

Still, it seems like there are two remaining issues:

1) The parser constructs nested widgets (C inside of B) or content even though B doesn't accept content. An error should be thrown when you try to nest content or another widget inside a widget that doesn't have a containerNode.

2) Why are startup and destroy done differently? A widget is responsible for calling startup on ALL of the widgets created by its template, but only responsible for destroying some of those widgets (the top "layer")? Why not do startup the same way as destroy?

comment:5 Changed 7 years ago by bill

Resolution: invalid
Status: newclosed

OK, so it sounds like the original issue isn't an issue after all, so I'm going to close this ticket. To address your questions:

1) The parser constructs nested widgets (C inside of B) or content even though B doesn't accept content. An error should be thrown when you try to nest content or another widget inside a widget that doesn't have a containerNode.

I don't think I can do that as it would break widgets like DropDownButton, and also because containerNode is something specific to dijit whereas the parser is supposed to be more general. But in any case it sounds like a minor issue.

2) Why are startup and destroy done differently? A widget is responsible for calling startup on ALL of the widgets created by its template, but only responsible for destroying some of those widgets (the top "layer")? Why not do startup the same way as destroy?

They are done the same way, at least in trunk. Widgets are responsible for calling startup() and destroyRecursive() on their direct child widgets only.

Note: See TracTickets for help on using tickets.