Opened 12 years ago

Closed 12 years ago

#7718 closed feature (fixed)

instantiating widget with option of type array

Reported by: sgruenholz Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.widget Version: 1.8.16
Keywords: Cc:
Blocked by: Blocking:

Description

I get an unexpected behavior when initializing a widget with an option of type array.

Example In a simple color picker we use an array of hex values. These define the default color swatches for the color picker.

$.widget("some.simple_color_picker", {
      // default color swatches
      options: { 
            colors: ['#000','#333','#666','#bbb','#ddd','#fff']
      },
      _create: function() {
            console.log("options.colors", this.options.colors);
      }
});

Instantiation When instantiating a color picker instance, I can then define my own custom set of color swatches to use for each one.

$('#some_elem').simple_color_picker({ colors: ['#FF0000', '#00FF00', '#0000FF'] });

But instead of replacing the default colors array with the new one (the expected behavior), it combines them. Logging the value of this.options.colors on _init() reveals:

['#FF0000', '#00FF00', '#0000FF', '#bbb', '#ddd', '#fff']

When options gets extended, it's treating our arrays like hashes and replacing values by index:

// default
{ 0: '#000', 1: '#333', 2: '#666', 3: '#bbb', 4: '#ddd', 5: '#fff' }

// instance
{ 0: '#FF0000', 1: '#00FF00', 2: '#0000FF' }

// extending these objects produces:
{ 0: '#FF0000', 1: '#00FF00', 2: '#0000FF', 3: '#bbb', 4: '#ddd', 5: '#fff' }

Workaround I've got a workaround where I use "options.default_colors" in the class and then instantiate with "options.colors", checking if the latter exists and using it instead. Or alternately we could use something like a delimited string of values and then parse them out... But, bottom line is the widget class exists to handle this for us in a friendly way.

Request Please consider "fixing" options to handle values of type array in the expected manner when a widget gets instantiated. Maybe this needs to get pushed up to the core method .extends() where the deep nesting stuff is happening...

Change History (1)

comment:1 Changed 12 years ago by Scott González

Resolution: fixed
Status: newclosed

This works properly in master. Probably from b9153258b0f0edbff49496ed16d2aa93bec07d95.

Note: See TracTickets for help on using tickets.