Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#6722 closed enhancement (wontfix)

Provide data-widgetName-options way to pass in options

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


With the introduction of the data- attributes, it would be nice to have a standard way of setting options on the element, similar to how the metadata plugin does it.

I have written the following into my jQuery UI based plugins (first line inside _create method), but thought it might be nice to have included within the widget factory so it would be done automatically for all jQuery UI plugins (even official ones).

this.options = $.extend(true,this.options,"-options")); // extend options with data-widgetName-options attribute

Change History (5)

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

Resolution: wontfix
Status: newclosed

Defining entire option hashes in attributes is pretty ugly (I would actually like to drop support for the metadata plugin). I did, however, create the _getCreateOptions() method specifically to handle this. Check out the base widget I created for jQuery Mobile to see how to properly read in data- attributes. You could easily modify the base widget's implementation to do this immediately after loading jQuery UI and then this would work for all widgets. The problem is that this is really slow.

comment:2 Changed 12 years ago by aaronbarker

When you say "Defining entire option hashes in attributes is pretty ugly" are you saying visually, or performance wise?

If visually, my intention is not to set "entire option hashes" in the attributes, but to override one or two options specific to that instance. For example a bunch of datepickers that I set a number of options on in the normal ondomload fashion, but having the ability to override the date format for a single instance inline would be handy. Sure people COULD do entire option hashes, but why penalize the people that want to use it for the powers of good? ;)

If performance, aren't the data- attributes already in data already as of 1.4.3? So there should be no additional hit there.

Not trying to be argumentative, just trying to be educated :)

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

It's visually ugly and users are likely to do it wrong (you have to deal with two levels of quotes right off the bat). This is what I mean by entire option hashes, even with a single value, specifying a hash via JSON inside an attribute is ugly. This is why jQuery Mobile uses a separate attribute for each option, it's much cleaner but has much more overhead.

comment:4 Changed 12 years ago by aaronbarker

Thank you for the clarification.

comment:5 Changed 12 years ago by sash

Perhaps this is what you're looking for?

Note: See TracTickets for help on using tickets.