Widget method inconsistencies and generalization issues

["Cowboy" Ben Alman]

I'm running into some issues here, and figured I'd ask for help.

So let's say I want a generic handler for jQuery UI Tabs and Accordion
widgets (and maybe others), to convert a state object into actual
selected states for those widgets.

The example page I'm thinking of contains #my_accordion and #my_tabs
elements. The names would, in practice, be quite different, but for
the example's sake I'll keep it simple.

Ok, so given that, let's say that I have an object that represents the
selected state of all current page jQuery UI widgets: { my_accordion:
1, my_tabs: 2 } which means "the selected index of #my_accordion is 1
and #my_tabs is 2.

Now, let's say we somehow manage to reset the state of the widgets
(via page reload or the like) but then want to apply the states in our
state object to all relevant widgets. It would be ideal to be able to
do something like:

$.each( { my_accordion: 1, my_tabs: 2 }, function( id, idx ){
$( '#' + id ).setSelected( idx );
});

There seems no way to do this kind of thing. In fact, between Tabs and
Accordion, not only is the method for accessing the widget different,
but the method for setting "selected" index is inconsistent:

$('#my_accordion').accordion( 'activate', 1 );
$('#my_tabs').tabs( 'select', 2 );

It would be nice if there was just one consistent sub-method across
all jQuery UI, either "select" or "activate" - and it would be nice if
that consistency was shared across all "like" methods.

It would also be nice if there was some way to figure out which jQuery
UI widget a specific element is. Is that possible? $
('#my_accordion').data( 'ui-widget' ).type could return 'tabs' or
'accordion' so we'd know what method to call, for example. The state
for each widget shouldn't need to keep track of what type of widget it
is!

Either way, I'm having the hardest time creating any kind of
generalized code here. I've only mentioned setting state, I haven't
even gotten into the issues of binding and stopping events in order to
decouple the click event from the action in order to get hash
history / bookmarking to work in jQuery BBQ, which is unfortunately
very obtuse and inconsistent across widgets.

And in doing all this, I'm noticing that it's a lot harder than it
needs to be for users to customize jQuery UI widgets to meet their
needs. I don't even think I'm talking about edge-cases here, as event-
driven is the way the web is moving!

I'd be delighted to work with you guys on the API, just let me know
how I can help. I can definitely give you solid examples of how I'd
like to see things tweaked.. just let me know if you want to discuss
this.

Thanks!

- Ben

[Scott González]

On Fri, Nov 20, 2009 at 10:45 AM, "Cowboy" Ben Alman <rj3.c...@gmail.com> wrote:

Now, let's say we somehow manage to reset the state of the widgets
(via page reload or the like) but then want to apply the states in our
state object to all relevant widgets. It would be ideal to be able to
do something like:

$.each( { my_accordion: 1, my_tabs: 2 }, function( id, idx ){
 $( '#' + id ).setSelected( idx );
});

We will never implement an API like this because it would open the door for any plugin to expose an unlimited number of methods on the jQuery prototype. While we all agree that .pluginName('methodName') isn't the most ideal implementation, it's the only solution that doesn't take over the entire namespace.

There seems no way to do this kind of thing. In fact, between Tabs and
Accordion, not only is the method for accessing the widget different,
but the method for setting "selected" index is inconsistent:

$('#my_accordion').accordion( 'activate', 1 );
$('#my_tabs').tabs( 'select', 2 );

It would be nice if there was just one consistent sub-method across
all jQuery UI, either "select" or "activate" - and it would be nice if
that consistency was shared across all "like" methods.

This is an inconsistency that we need to take care of. Many of the existing plugins were written as individual plugins, not as a part of a suite. We're trying to go through and fix all inconsistencies. Feel free to open a ticket for this, we consider these inconsistencies to be bugs.

It would also be nice if there was some way to figure out which jQuery
UI widget a specific element is. Is that possible? $
('#my_accordion').data( 'ui-widget' ).type could return 'tabs' or
'accordion' so we'd know what method to call, for example. The state
for each widget shouldn't need to keep track of what type of widget it
is!

This is planned for the new widget factory which will either land in the 1.9 release or the 2.0 release. You will be able to do something like .data('widgets') to get an array of all plugins that have been initialized against the element.
 

And in doing all this, I'm noticing that it's a lot harder than it
needs to be for users to customize jQuery UI widgets to meet their
needs. I don't even think I'm talking about edge-cases here, as event-
driven is the way the web is moving!

Can you please provide specific examples so we can address them?

I'd be delighted to work with you guys on the API, just let me know
how I can help. I can definitely give you solid examples of how I'd
like to see things tweaked.. just let me know if you want to discuss
this.

We'd love to work with you. Feel free to bring up any issues/ideas on this group, preferably a separate thread for each issue.

Thanks.

["Cowboy" Ben Alman]

Thanks for the reply, Scott.

I wasn't really suggesting adding widget-specific methods directly to
the jQuery prototype, I was just getting at "please make it easier",
not really thinking about what my sample code implied. Having
consistent, predictable data returned under .data('widgets') and
standardized widget methods and properties for common functions like
"activate" would be huge for helping devs write generalized widget-
agnostic controller code.

I look forward to the upcoming releases!

- Ben

On Nov 20, 8:03 pm, Scott González <scott.gonza...@gmail.com> wrote:
> On Fri, Nov 20, 2009 at 10:45 AM, "Cowboy" Ben Alman

> <rj3.cow...@gmail.com>wrote: