Skip to main content

Search and Top Navigation

#6722 closed enhancement (wontfix)

Opened December 06, 2010 05:26PM UTC

Closed December 06, 2010 05:30PM UTC

Last modified February 18, 2011 06:43PM UTC

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
Attachments (0)
Change History (5)

Changed December 06, 2010 05:30PM UTC by scottgonzalez comment:1

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.

Changed December 06, 2010 06:08PM UTC by aaronbarker comment:2

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 :)

Changed December 06, 2010 06:17PM UTC by scottgonzalez comment:3

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.

Changed December 06, 2010 06:24PM UTC by aaronbarker comment:4

Thank you for the clarification.

Changed February 18, 2011 06:43PM UTC by sash comment:5

Perhaps this is what you're looking for?