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

[askohen]

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/

[askohen]

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

[Scott González]

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.

[askohen]

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.

[Scott González]

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.