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.
-
// 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