How to derive a custom widget from jquery-ui dialog

Question

I want to build a jquery-ui widget and I am unsure of the best way to approach this.

The widget will manage the sate of some data that is hosted inside of a jquery-ui dialog.

Should I build a custom widget, in the widget create function add some elements to the widget target and then call the dialog widget on my widgets target.

Or

Is there a way to inherit from the jquery-ui dialog and just override the content part of it?

Answer 1

There is a way to extend other widgets:

$.widget("ui.customwidget", $.ui.dialog, {
    options: {
        // your options
    },

    _create: function() {
        $.ui.dialog.prototype._create.apply(this);
        // constructor
    },

    destroy: function() {
        // destructor
        $.ui.dialog.prototype.destroy.apply(this);
    },

    _setOption: function(key, value) {
        $.ui.dialog.prototype._setOption.apply(this, arguments);
        // process the setting of options
    }
    // other methods
});

But I'd not encourage using it on a dialog, slider etc. because e.g. buttonset relies on the existence of the button widget and will (and can) not recognize if the element is an instance of a widget that extended button. Therefore it just creates new pure button widgets, what leads to a messed up layout and DOM. Overriding parts of a widget is also critical: The extending mechanism for widgets was introduced not so long ago, when some widgets already existed. The developers of them did not have this feature in mind, so there may still be issues with this. I aggregate my widgets (your first option): Just extend the $.Widget and make the element a dialog too. Then add event listeners for the properties that need to be synchronized between the dialog and your custom widget.

$.widget("ui.customwidget", $.Widget, {
    // ...
    _create: function() {
        $.Widget.prototype._create.apply(this);
        this.element.dialog();
    }
    // ...
});

This way more robust than extending other widgets (except you built the parent and know what you are doing), but it has it's disadvantages too. E.g. do you accept setting options of the aggregated widget too, or just parts of it? Or do you do none of these and force the user to call the dialog for everything that is not handled in your custom widget? I prefer the second option: It's at least honest, because your widget does't promise things it can't hold, but it's ugly too, because you may once call one, then the other widget.

I'm still not that happy with my solution, but extending widgets put me in front of a whole load of new problems whose solutions would have been either to patch the jQuery UI source or to write an ugly hack.

(I just noticed that this question is about a year old, and the asker may not have this problem anymore. But I'd written all the stuff above already and think it's not that bad to not be posted.)