Search and Top Navigation
#9050 closed feature (invalid)
Opened February 02, 2013 05:16PM UTC
Closed February 17, 2013 08:46AM UTC
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: |
Description
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
Attachments (0)
Change History (3)
Changed February 02, 2013 08:35PM UTC by comment:1
owner: | → dbarnes |
---|---|
status: | new → pending |
Changed February 02, 2013 08:37PM UTC by comment:2
type: | bug → feature |
---|
Changed February 17, 2013 08:46AM UTC by comment:3
resolution: | → invalid |
---|---|
status: | pending → closed |
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!
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?