Opened 10 years ago

Closed 10 years ago

#9050 closed feature (invalid)

Problem with new option() behavior, cannot see what nested property changed

Reported by: dbarnes Owned by: dbarnes
Priority: minor Milestone: none
Component: ui.widget Version: 1.10.0
Keywords: Cc:
Blocked by: Blocking:


As of jQuery 1.9, the option() method (and it's "sibling" methods) changed to work with nested options. This is a great change, but now I can't seem to access the specific nested property that was changed in any of the option methods.

For example: $().widget("options", "buttons.cancel", true)

In option(), I'm passed the exact arguments obviously, but that doesn't seem to be the intended place to place state-updating logic, and this method appears to mutate the options when dealing with nested options. (which seems contrary to the later methods that should be the ones changing the actual options object)

In _setOptions(), only the hash from option() is provided, and not much is done there.

In _setOption(), where I originally wrote my state-update logic, the arguments passed are "buttons" and { cancel: true, + all other keys on this options object ... }. With that, I can't determine which of those sub-options has changed.

It would appear that the best way to write this is to have the logic that mutates nested properties in the _setOption() method call. This way, a widget author can still detect which key is being changed, call _superApply() to mutate the options object and proceed to update the state of the widget itself from there.

I would be willing to take a crack at writing this up in a PR, unless I'm completely missing something and will surely be corrected soon. :P

Change History (3)

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

Owner: set to dbarnes
Status: newpending

This of course complicates the option setting for everyone, as you would now need to parse the incoming option name. Do you have a suggestion for not increasing the amount of work necessary?

comment:2 Changed 10 years ago by Scott González

Type: bugfeature

comment:3 Changed 10 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Note: See TracTickets for help on using tickets.