Ticket #429 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

Initial value selection-control ignored by setWireValue

Reported by: idbr Owned by: mpo
Priority: major Milestone: 0.4
Component: modules/kauri-forms Version:
Keywords: Cc:

Description

The initial value of a selection control is ignored when performing a setWireValue on a form, and if no value is specified for the selection control (in r1804).

In the selection-control-sample, the default value for the first selection is "yes", although the initial value is "maybe".
By removing the line with setWireValue, the correct initial value is selected.

Attachments

patch.txt (1.7 KB) - added by anonymous 2 years ago.
Patch based on pointers given by Mark
patch.2.txt (1.7 KB) - added by idbr 2 years ago.

Change History

comment:1 Changed 2 years ago by idbr

I've made a fix, but I'm not sure it's free of side effects. Could someone verify?

Basically, I just overrode the setWireValue-method for SelectionControl?, and checked the given value for being undefined, at which point the initial value is used.

SelectionControl.prototype.setWireValue = function(value, noValidation){
  if (value == undefined && this.initial.value !== undefined)
    this.setWireValue(this.initial.value, true);
  else
    this["<super.call>"]("setWireValue", [value, noValidation]);
}

Changed 2 years ago by anonymous

Patch based on pointers given by Mark

comment:2 Changed 2 years ago by mpo

Ives,

I just gave this a quick look, but I have the impression we're still missing out on the following case:

What if the initial-value is also not in the list? In other words I think you'll also need to trim that value etc etc..

wdyt?

comment:3 Changed 2 years ago by idbr

You're right! I've made a new patch with an extra check that the trimmed initial value isn't undefined.

Changed 2 years ago by idbr

comment:4 Changed 2 years ago by mpo

  • Status changed from new to closed
  • Resolution set to fixed

Applied (a slightly modified version of) this patch in r1833.

(Adding for future reference, since some of this dicussion happened off-line)
Note though that this does not change our position on 'sparse' arguments to setValue or setWireValue: those members not present in those value-arguments will result in a set to undefined/null - and will not yield a reset().

Sparse/inidividual setting or resetting on control level still should be organized by manual findControl() lookups en detailed calls to individual controls.

In the case of the selection control we however acknowledged that the normalization which is essential for proper syncing between the user-facing component and the internal value can logically be enhanced with this extra intermedia-fallback-check. (assigning a higher likelyness value to the configured initial-value of the control then to simply the first option in the list)

Note: See TracTickets for help on using tickets.