Opened 12 years ago

Closed 7 years ago

#10799 closed defect (patchwelcome)

Using jsID in declarative objects doesn't cause the Object to delete it's variable when destoryed.

Reported by: Kitson Kelly Owned by: Kitson Kelly
Priority: high Milestone: 1.13
Component: Parser Version: 1.4.0
Keywords: dojo jsId declarative Cc:
Blocked By: Blocking:

Description (last modified by bill)

It would appear that when the 'jsId="somevar"' in a declarative dojo Object, dojo properly creates the variable, but when the Object is destroyed, for example a on a dijit.layout.ContentPane that is part of dijit.layout.TabContainer is closed, the Object is destroyed, but the global variable is not deleted, meaning that because not all references to the Object are removed, the Object is not removed from memory.

Redeclaring the same Object with the same ID and jsId does not cause any issues or errors, as well as doing a native js "delete somevar;" after destruction does remove the Object from the DOM.

There should be a mechanism so that Objects created with a jsId auto delete themselves when destroyed.

Change History (8)

comment:1 Changed 12 years ago by Kitson Kelly

For some further information, please see this StackOverflow Question.

comment:2 Changed 12 years ago by bill

Milestone: tbd1.6

That's correct, although it's tricky to fix since the parser is not involved in destroying widgets. I suppose the parser could dojo.connect() to the widget's destroy method to delete that global variable.

comment:3 Changed 12 years ago by dante

If we put jsId in dijit._Widget.prototype as a null value and then in destroy did something like:

this.jsId && delete[this.jsId]

would that "just work"? or we could make parser stub jsId location onto the instance as jsId when it is parsed, and just check if it was instantiated that way.

comment:4 Changed 12 years ago by bill

Description: modified (diff)

I think that will work, it's just hackish because it's mixing the parser's job and the Widget's job. (It seems like the parser should delete jsId since it created it.) But I suppose things are tangled up already since (as I said) the parser creates the widgets, but they are destroyed manually.

The other thing is that ItemFileReadStore (as mentioned in the ticket description) does not extend dijit._Widget.

Anyway, I'm not sure that we want to have anything built in to remove the variable, but I'll think about it some more. Maybe the parser should return some kind of destruction meta-data to the ContentPane so that it can remove all the globals.

comment:5 Changed 12 years ago by Kitson Kelly

Maybe the parser should return some kind of destruction meta-data to the ContentPane? so that it can remove all the globals.

Personally, I think that might work. That the parser would register any globals with a dijit._Container for it to clean up when it does a dijit._Container.destroyDescendants.

Also, the only reason I am using jsId is because it seems to be the only way to reference a datastore to a Widget in declarative mode.

comment:6 Changed 11 years ago by bill

Milestone: 1.6future

(sadly) punting seemingly abandoned ticket and meta tickets to future

comment:7 Changed 9 years ago by Kitson Kelly

Owner: changed from bill to Kitson Kelly
Status: newassigned

comment:8 Changed 7 years ago by dylan

Milestone: future1.12
Resolution: patchwelcome
Status: assignedclosed

If someone wants to revisit this, we would consider a pull request for 1.12 per our contribution guidelines ( ). Given the lack of activity over the past 6 years, it's not going to get fixed otherwise, so I'm closing as patchwelcome.

Note: See TracTickets for help on using tickets.