jQuery Forum

I'm not sure what you're talking about. The widget factory does a deep extend. In fact, we have plugins that have nested options.

Hi Scott,

Let me illustrate (again) with a practical example:  Open the following page and issue any of the following commands (below) in Firebug http://jqueryui.com/demos/button/icons.html

Lurkers: the button widget has a nested-object option for icons.

I'm doing this (below) with resetting options because it's easy but we have the same problem upon _create() if we want to provide default options having nested objects and expect our users to interact with that.

It's not an " option " if you have to specify it. In the case of nested options, you can't just specify one aspect of the nest, you need to spec the whole nest to preserve some aspects of its initial (default) state. That's the problem.

That's because you DON'T do a deep extend on the options. You do a simple extend of options on options with a tip-o-the-hat to the metadata plugin along the way.  That is not a deep extend.

In all cases below, using the button widget for example, I would expect options.icons.primary to remain unchanged.

1. // expect no change in options.icons.primary.  Observe: icon changed to ui-icon-trash
   $("button").eq(0).button("option", "icons",{"secondary": "ui-icon-trash"})
   
   // Ditto
   $("button").eq(1).button("option", "icons",{"secondary": "ui-icon-trash"})
   
   // Expecting to still have two icons. Observe: just one, the second one only, is ui-icon-trash.
   // icons.primary is gone.
   $("button").eq(2).button("option", "icons",{"secondary": "ui-icon-trash"})
   
   // Ditto
   $("button").eq(3).button("option", "icons",{"secondary": "ui-icon-trash"})

Again I emphasize: we have the same problem upon create where the options contain a nested-object option.

I would agree with you on this: button option.icons is a trivial case, suck-it-up, spec both.

But my development case isn't trivial: I have a half-dozen objects that I would like to nest in a single option and I cannot do that because the end-user will be forced to re-spec the whole tree to change just one branch.

What we need, I reckon, is an _optionSet() method, native to the widget factory, wherein we can extend option branches on option branches prior to doing the simple extend the widget factory does now, buried in a non-extensible way (currently), in the _createWidget() method. 

That same an _optionSet() method would, of course, be called upon subsequent option resets.

Clear now?

**--**  Steve

Looking at the widget factory, you are correct, the default implentation of _setOption does replace the entire "icons" option with the plain object.  However, you can correct this by overriding _setOption in your widget to handle the special case when key is "icons", and not call back to $.Widget.prototype._setOption:

1. _setOption: function(key, value) {
2.       var self = this;
3. 
   
4.       if (key == "icons") {
5.             $.each(value, function(key, value) {
6.                   self.options.icons[key] = value;
   
7.             });
   
8.       } else {
9.             $.Widget.prototype._setOption.apply(this, arguments);
   
10.       }
    
11. }

Granted, however, there might be a way to work this functionality into the widget factory to make it simpler.  Also, I did notice a small issue in the widget factory that isn't addressed by this.  In the option method:

1. if (arguments.length === 0) {
2.       // don't return a reference to the internal hash
3.       return $.extend( {}, self.options);
   
4. }

Should be using a deep copy as well, otherwise objects within options will still be affected by changes to the returned hash.

Brant