#2340 closed bug (fixed)

Opened February 13, 2008 08:06PM UTC

Closed June 26, 2008 08:27AM UTC

Last modified January 17, 2010 06:01AM UTC

[UI] Dispatched Events

Reported by: scottgonzalez Owned by: scottgonzalez
Priority: blocker Milestone: 1.5.1
Component: ui.core Version: 1.5
Keywords: ui event Cc:
Blocked by: Blocking:
Description

There are currently three models being used for dispatching events in the UI plugins.

accordion:

$(el).triggerHandler('<action>.ui-<plugin>', [ui], callback);

dialog, draggable, droppable, resizable, selectable, slider, sortable

$(el).triggerHandler('<plugin><action>', [e, ui], callback);

tabs:

$(el).triggerHandler('<action>.ui-<plugin>', [ui]);

The accordion and tabs models are both missing the event object in the data parameter. The tabs model is also missing the callback.

However, it is unclear which event naming convention should be used. The more widely used "<plugin><action>" convention seems more likely to avoid collisions with other event names. However, the "<action>.ui-<plugin>" convention provides the convenience of having user-defined events be cleaned up if the plugin's destroy method is called.

Attachments (0)
Change History (14)

Changed February 13, 2008 08:13PM UTC by joern comment:1

Unless you actually need to provide a custom event object - for whatever reason - there is no point in passing one in.

Passing in the callback has now obvious drawbacks, that should be easy to fix for tabs.

Not sure about the namespace though.

Changed February 13, 2008 08:32PM UTC by scottgonzalez comment:2

You're right about not needing to pass in the event object. I forgot that the parameters passed to the event handler will still be (event, ui) regardless of whether the plugin passes an event object in the data. My concern was only that the user would have different parameters to work with depending on the plugin (apparently I didn't think it through far enough).

Changed February 20, 2008 11:10AM UTC by paul comment:3

Yes, we should definitely make sure we have one convention for naming the custom events. From a semantical view, I would prefer <plugin><action>.

However, I right now tend to go with the dot, since it feels more like it was intended.

Changed February 20, 2008 11:10AM UTC by paul comment:4

status: new → assigned

Changed February 21, 2008 03:57PM UTC by scottgonzalez comment:5

Recent thoughts on why <plugin><action> might be better than <action>.ui-<plugin>:

1) Event names may overlap with real events. For instance, "slidechange" would become "change.ui-slider" which could end up being triggered from some other change event.

2) If someone develops widgets that rely on jQuery UI plugins, they may want to hook into the events and use their own namespace (to make cleanup easier). This will only be possible if the triggered events are not namespaced.

Changed March 14, 2008 06:31PM UTC by paul comment:6

owner: paul → scott.gonzalez
status: assigned → new

Scott, I vote for <plugin><action>. I've assigned it to you - could you work on this later on in every plugin?

Changed March 14, 2008 08:23PM UTC by scottgonzalez comment:7

status: new → assigned

Accordion is fixed in [4912].

Changed March 15, 2008 02:26PM UTC by scottgonzalez comment:8

Tabs updated in [4956] - Thanks Klaus.

Changed April 11, 2008 02:42AM UTC by scottgonzalez comment:9

resolution: → fixed
status: assigned → closed

datepicker currently has no events

Changed May 24, 2008 03:39AM UTC by comment:10

milestone: 1.2.4

Milestone 1.2.4 deleted

Changed June 25, 2008 06:34PM UTC by scottgonzalez comment:11

milestone: → 1.5.1
priority: major → critical
resolution: fixed
status: closed → reopened
version: 1.2.3 → 1.5b4

Not all plugins pass the ui parameter as the second parameter in the callback.

Changed June 25, 2008 09:59PM UTC by rdworth comment:12

priority: critical → blocker

Changed June 26, 2008 08:27AM UTC by scottgonzalez comment:13

resolution: → fixed
status: reopened → closed

Fixed in [342].

Tabs should be reviewed to see if there are meaningful events that can be passed instead of null. Accordion should be reviewed to determine if a fake event should be passed instead of null.

Changed June 27, 2008 10:27AM UTC by rdworth comment:14

version: 1.5b4 → 1.5