jQuery UI Widget Namespace Extensions

[cschneid]

I have two commits here. The first enables an underscore version of widget namespaces.

$(".tab").cb_tab();

It also enables $("#tab1").data("cb.tab") to get at the attached instance (in addition to the older key of just "tab"

The second commit builds on the first to enable a different syntax for reaching into the namespace, since I don't particularly like the underscore approach.

$(".tab").cb().tab();

Both of the approaches are backwards compatible, and maintain the bare widget name approach that uses the most recently defined widget.

Ping me on #freenode (cschneid), here, or my email (chris.schneider@citrusbyte.com) to discuss any revisions. I expect to revise these commits to use only one of the two methods, and flesh out tests a bit further based on your feedback.

Thank you,
Chris

[scottgonzalez]

There seem to be two things here. One is the ability to include multiple widgets with the same name. This seems extremely uncommon, and can already be done in a noConflict type rewrite, e.g., $.fn.ui_dialog = $.fn.dialog. See http://jsbin.com/umeja3/edit for an example.

The second is an attempt to actually add namespaces to jQuery which isn't something we want to do in the widget factory.

[cschneid]

Then why is there a namespace concept at all? Why do you define $.widget("ui.draggable"), and have the widget code parse out the namespace, and place the code in a different spot based on that namespace?

I figure half implemented code is not optimal, so I finished out the namespace support.

What is the motivation for the existing code that handles namespaces in widgets?

[scottgonzalez]

The namespaces are mostly for code organization and to provide an object for collecting utility methods in packages/libraries/whatever. jQuery doesn't support namespaces for methods and there's no clean way to implement them. Exposing namespaces breaks a key pattern that jQuery is built on.

[cschneid]

Sure, I can buy that fine (it does break chaining to some extent), it just bothers me that I had to write this in a blog post describing jQuery-ui widgets used for custom purposes.

Widgets strings all start with `ui.` in their names.  Don’t be fooled into thinking this is a namespace. 
It’s not. You’re required to use `ui.` there. I’m not sure of the design decision behind this, but you 
need to watch out for it.

It's not technically true, you're not required to use 'ui'. But it doesn't matter, it's still not a namespace. And if you don't define a namespace string, the widget doesn't work.

Perhaps instead of having the mostly-useless to the outside world namespace string, we could add a check to the beginning of $.widget() that provides a default namespace name (ui or whatever) that would allow me to define widgets like $.widget("tab", {}).

This is the code that always assumes a namespace is in the string:

$.widget = function( name, base, prototype ) {
    var namespace = name.split( "." )[ 0 ],
        fullName;
    name = name.split( "." )[ 1 ];
    fullName = namespace + "-" + name;

[scottgonzalez]

It definitely is a namespace. The fact that we don't use two namespaces ($.ui and $.fn.ui) doesn't invalidate the fact that we do use one namespace. Also, about what you wrote in your blog post, nobody should be using the ui namespace other than the jQuery UI team. The ui namespace is reserved for plugins that are officially part of jQuery UI.

[cschneid]

Thank you for the discussion here. I will be writing a followup blog post discussing the namespaces as implemented. I'll link it here when I'm done so you can review for accuracy if you'd like.

To sum up, it is:

• Don't use ui, that's for officially included widgets
• It's not for overlapping names
• It does get placed in different spots in the $.namespace.widget hierarchy.
• jQuery just doesn't support namespaces very well. (I feel that my implementation is about as close as you can get to it, but it is still flawed)

It does still rub me the wrong way to have namespaces that don't allow much separation after the definition (the widgets with the same name situation), but I understand that the complexity added to handle that would far outshadow the ease of the user just not doing that in the first place.

[scottgonzalez]

Thanks for taking the time to write a follow up post, what you've listed out is correct.