How to get custom widget from jquery-ui dialog

I want to create a jquery-ui widget, and I don’t know how best to approach this.

The widget will manage the contents of some data placed inside the jquery-u dialog box.

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

or

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

+6
jquery-ui widget
source share
1 answer

There is a way to expand 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 would not recommend using it in a dialog, slider, etc., for example, for example. buttonet relies on the existence of a button widget and will (and may) not recognize whether this element is an instance of the widget that extended the button. Therefore, it simply creates new clean button widgets, which leads to a damaged layout and DOM. Overriding widget parts is also extremely important: the widget extension mechanism was introduced not so long ago when some widgets already existed. The developers of them did not take this feature into account, so there may be problems with this. I am merging my widgets (your first option): just $.Widget and make the element interactive. Then add event listeners for the properties you want to synchronize between the dialog and your custom widgets.

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

This method is more reliable than expanding other widgets (except that you created a parent and know what you are doing), but it also has drawbacks. For example. Do you agree with the settings for the aggregated widget or just parts of it? Or do you do nothing and force the user to call a dialog for everything that is not processed in the user widget? I prefer the second option: it is at least honest, because your widget does not promise that it cannot hold, but it is also ugly, because you can call it once, and then another widget.

I'm still not very happy with my solution, but the extension of the widget confronts me with a whole host of new problems, the solutions of which would be to fix the jQuery UI source code or write an ugly hack.

(I just noticed that this question was about a year ago, and the aiser may not have this problem anymore, but I already wrote all of the above and think that it’s not so bad that it is not published.)

+6
source share

All Articles