Opened 8 years ago

Closed 8 years ago

#14495 closed defect (fixed)

widget id is changed to undefined by _applyAttributes

Reported by: liucougar Owned by: bill
Priority: high Milestone: 1.8
Component: Dijit Version: 1.7.1
Keywords: Cc: cjolif, Douglas Hays
Blocked By: Blocking:

Description

before the change introduced in Ticket #14341, the following works fine:

new dijit.AnyWidget({id:undefined}); //in my real code, id is actually assigned a dict.not_set_key

the widget will receive a unique generated id.

however, after the change in Ticket #14341, this use case will lead to a widget with a generated unique id when buildRendering is called, and the id is registered in dijit.registry. However, after _applyAttributes is called, the id is reverted back to undefined

don't know whether this is considered as breaking backward compatibility. should _applyAttributes just ignore undefined values?

Change History (4)

comment:1 Changed 8 years ago by bill

Cc: cjolif Douglas Hays added

Hmm, well by "works fine" you mean that

new dijit.AnyWidget({id:undefined});

is equivalent to not specifying the id at all:

new dijit.AnyWidget({});

I'm a little worried about just ignoring widget parameters with undefined values, because maybe the user intended to pass in an undefined in order to override some default value, something like:

new dijit.form.NumberTextBox({required: true, missingMessage: undefined})

to make the widget *not* display a tooltip when the value is missing.

OTOH I can see how some application frameworks might pass in undefined for parameter values rather than just not specifying the parameters at all.

Not sure which is the better choice.

comment:2 Changed 8 years ago by cjolif

I think we are here in a similar scenario than with the CheckBox? value property that was causing trouble after that fix. Indeed at build time (in create function after postMixinProperties), if the id is undefined, an id is created while later on if you explicitly set id to undefined the id is actually set to undefined and not (re)created. And that's what happen in _applyAttributes.

Each time there is a discrepancy between the behavior at build time & run time we might fail into that kind of issues. However here we are in special case, I guess one does not expect ID of a Widget to be mutable? So we don't expect it to change at runtime. In this case maybe a solution would be to replace:

  if(!this.id){
    this.id = registry.getUniqueId(this.declaredClass.replace(/\./g,"_"));
  }

by

  if(!this.id){
    this.id = registry.getUniqueId(this.declaredClass.replace(/\./g,"_"));
    this.params.id = this.id;
  }

to deal with that special case? (i.e. keep the ability to set id: undefined in ctor but don't expect this to happen later on).

comment:3 Changed 8 years ago by bill

Milestone: tbd1.8
Owner: set to bill
Status: newassigned

OK, I'll checkin something like that.

comment:4 Changed 8 years ago by bill

Resolution: fixed
Status: assignedclosed

In [27583]:

Ignore {id: undefined} specified in widget constructor parameters, fixes #14495 !strict.

Note: See TracTickets for help on using tickets.