widget event names should use namespaced events

[Danny]

In 1.6rc5, _trigger creates a custom event with the name
this.widgetEventPrefix + type

Is there a reason it's not
type + '.' + this.widgetEventPrefix

to use namespaced events (http://docs.jquery.com/Namespaced_Events)?

That would be consistent with the purpose of namespaced events, and
would allow destroy (or the user) to do
this.element.unbind('.'+this.widgetEventPrefix) to clean up any
leftover event handlers.

This would also be consistent with the actual UI widgets, all of which
use things like unbind('.sortable') and
.bind("mouseleave.accordion").

To be completely consistent, the widget constructor should also use
.bind('setData.' + this.widgetEventPrefix) rather than .bind
('setData.' + name)
but I don't think anyone uses widgetEventPrefix anyway. Just drop it!

Danny

[Richard D. Worth]

widgetEventPrefix is used so we can have nice event names like

dragstart
drag
dragstop

instead of

draggablestart
draggabledrag
draggablestop

See for example

http://jquery-ui.googlecode.com/svn/trunk/ui/ui.draggable.js
...
$.extend($.ui.draggable, {
    version: "@VERSION",
    eventPrefix: "drag",
...

- Richard

[Scott González]

Hi Danny,

On Tue, Jan 27, 2009 at 9:30 PM, Danny <d.wa...@prodigy.net> wrote:

In 1.6rc5, _trigger creates a custom event with the name
this.widgetEventPrefix + type

Yup, it's been this way since 1.5.
 

Is there a reason it's not
type + '.' + this.widgetEventPrefix

The reason we don't use namespaced events is because that greatly reduces flexibility for the user.  User's should have the ability to bind handlers to the UI events while using whatever namespace they want.  This is especially useful if you're building modules that add extra functionality to existing widgets.  For example, you can create a module that adds certain functionality to all draggables by binding to the various drag events.  If you do this using your own namespace, you can easily cleanup all of your handlers.
 

to use namespaced events (http://docs.jquery.com/Namespaced_Events)?

That would be consistent with the purpose of namespaced events, and
would allow destroy (or the user) to do
this.element.unbind('.'+this.widgetEventPrefix) to clean up any
leftover event handlers.

I don't think it's the responsibility of the widget to clean up the user's event handlers, but I'm willing to discuss this topic.  Removing the event prefix would also open up the possibility for event name collision, e.g., change.slider.

This would also be consistent with the actual UI widgets, all of which
use things like unbind('.sortable') and
.bind("mouseleave.accordion").

I don't think this adds any consistency because I don't see any inconsistency right now.  There's a pretty big difference between binding an event handler and triggering an event.  We use namespacing for all event bindings to make it easy to clean up on destroy, but there's nothing for us to clean up from triggering events.

To be completely consistent, the widget constructor should also use
.bind('setData.' +  this.widgetEventPrefix) rather than  .bind
('setData.' + name)
but I don't think anyone uses widgetEventPrefix anyway. Just drop it!

The widgetEventPrefix serves a totally different purpose and is used in quite a few widgets as Richard has explained.

I hope all of this makes sense.  Let us know if you've still got any questions or concerns.

[Danny]

That's cool. I guess I'm thinking of namespaced events in a different
way, as the way for the triggering code to control events. As you
point out, you are making it the responsibility of the binding code,
so trigger('event.namespace') in library code isn't really using it in
the intended fashion.

Danny

[Scott González]

On Tue, Jan 27, 2009 at 10:35 PM, Danny <d.wa...@prodigy.net> wrote:

That's cool. I guess I'm thinking of namespaced events in a different
way, as the way for the triggering code to control events. As you
point out, you are making it the responsibility of the binding code,
so trigger('event.namespace') in library code isn't really using it in
the intended fashion.

Yeah, we went through the same exact thought process as you during 1.5.  We actually spent quite a while discussing it, here's the ticket: http://ui.jquery.com/bugs/ticket/2340