#7699 closed enhancement (wontfix)

Opened September 06, 2011 04:52PM UTC

Closed September 09, 2011 11:34AM UTC

Derived Widgets Don't Inherit "Static Methods" From Base Widget

Reported by: askohen Owned by: askohen
Priority: minor Milestone: 1.9.0
Component: ui.widget Version: 1.8.16
Keywords: Cc:
Blocked by: Blocking:
Description

I have a need to attach a few methods to all widgets, but I need to call the methods without calling the widget on the element first. This calls for using "static methods", or in JavaScript simulating static methods by adding a method as a property of the widget. Like so:

jQuery.widget( "ui.mywidget", {
   // widget code
});

// Now attach "static method
jQuery.ui.mywidget.staticmethod = function(){
   // etc.
}

I want to attach that method, however, in a base widget, and have all my widgets inherit that "static method". It seems that the widget factory doesn't account for this, and does not allow inheriting of "static methods". See: http://jsfiddle.net/aaroncohen/85H5L/

Attachments (0)
Change History (4)

Changed September 06, 2011 04:53PM UTC by askohen comment:1

I would add that I am willing to provide a patch.

Changed September 06, 2011 05:32PM UTC by scottgonzalez comment:2

owner: → askohen
status: new → pending

It seems like you're trying to make widgets match the classical inheritance model. I'm not really sure that we should add this. What's your actual use case?

Also, FWIW, in master, you can just do $.ui.derivedwidget = $.ui.basewidget before $.widget( "ui.derivedwidget", ... ) to get the behavior you want.

Changed September 09, 2011 03:44AM UTC by askohen comment:3

status: pending → new

Hi, thanks for taking a look. The use case is that we have a library on top of jQuery UI, which extends UI, and allows widgets to be rendered on the page declaratively without using JavaScript. You just mark up elements with a certain class and it renders as a widget.

For example, putting a class of "accordion" on a div whose children are marked up according to the accordion pattern. Our framework scans the page for "div.accordion"--that's a simplified example, but you get the idea.\\

There are times when the users of the library might need to know the selector that our framework uses for accordions. To get that selector you'd call $.ui.accordion.getSelector(); and it would return "div.accordion".

It makes sense in this case to store that method as a property of the function, not as a method called like:

$('#my-accordion').accordion('getSelector');

since the developer might not have an id to work with.

Regardless of my mental model, it makes sense to store that method in a way that doesn't require the "instantiation" of the widget first. And it makes sense if you extend a widget, properties set on the function itself would be inherited. On the other hand, I can understand that this is a very edge case and wouldn't warrant further action on UI's part. Thanks for taking a look. Close if you wish.

Changed September 09, 2011 11:34AM UTC by scottgonzalez comment:4

resolution: → wontfix
status: new → closed

Yeah, this is a classical inheritance model. You could build the equivalent by having a single method that accepts the name of the widget, or you can do the cloning before or after if you want to keep the model you have.