Setting a slider's value without triggering the change event

[Paul Bakaus]

Hey folks,

pretty nasty issue. Every time I've actually worked with our new slider implementation, I had to manually fork it. The reason
is that it's currently not possible (imo) to set the value of a slider without triggering a change event.

Here's the actual issue, as an example I'm using a video playback demo:

1. If you initialize a slider, you most often do it like that:

$('#slider').slider({
    change: function() {
        //Seek to current value in video
    }
});

2. And of course, you also want to update the slider's position based on the current playtime of the video:

$('#slider').slider('value', getCurrentPlayTime());

Here is where it gets problematic. You just want the slider to react in this case, not to be a trigger. Calling the second above
will result in the video seeking and seeking and seeking.

In the old slider implementation (and still in the values method, strangely), We exposed an optional third argument called
noPropagation, that if set to true, simply didn't propagate any events. I strongly suggest we add that one again, unless somebody
finds a better solution to the problem.


--
Paul Bakaus
UI Architect
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

[Scott González]

Why not just check for the original event?  If it exists, then the change was triggered by the user, if it doesn't it was scripted.

$('#slider').slider({
    change: function(event) {
        if (event.originalEvent) {

            //Seek to current value in video
        }
    }
});

[Paul Bakaus]

That's one possibility, but to me, it feels kind of hackish. We shouldn't promote the use of event.originalEvent in my opinion.

2009/3/17 Scott González <scott.g...@gmail.com>

[Scott González]

Why not?  If we're not going to promote it, then why even provide it?

This seems like a perfectly reasonable way to distinguish between user-initiated events and scripted events.

[Richard D. Worth]

Agreed. The spec is pretty clear on this:

http://wiki.jqueryui.com/Slider#specs
"change callback: triggers when the slider has stopped moving and has a new value (even if same as previous value), via mouse(mouseup) or keyboard(keyup) or value method/option"

To me this is exactly why we have event and event.originalEvent. The slidechange event should fire anytime the slider value changes (not only when the keyboard or mouse triggered that change), and event.originalEvent allows you to detect what triggered it.

- Richard

[Paul Bakaus]

On Tue, Mar 17, 2009 at 4:20 PM, Richard D. Worth <rdw...@gmail.com> wrote:

Agreed. The spec is pretty clear on this:

http://wiki.jqueryui.com/Slider#specs
"change callback: triggers when the slider has stopped moving and has a new value (even if same as previous value), via mouse(mouseup) or keyboard(keyup) or value method/option"

To me this is exactly why we have event and event.originalEvent. The slidechange event should fire anytime the slider value changes (not only when the keyboard or mouse triggered that change), and event.originalEvent allows you to detect what triggered it.

I disagree. event.originalEvent is a weak splot in the API. Scott, I agree that we shouldn't even provide it in the first place. The triggered event should have all event properties exposed that you need.

I think we need to find a better way to handle those situations.
 

[Jörn Zaefferer]

Do we have an usecase where its useful to trigger the change event
when setting the valie programmatically?

Jörn

[Richard D. Worth]

I don't see any reason to differentiate, and a big reason not to. The event communicates that the value changed. And anyone at all can listen for it, just as anyone at all could change the value. If a "programmatic" change to the value didn't trigger this event, and someone was listening for all changes to the slider value, that listener would have no way to be notified of the change to the value. They didn't subscribe to changes to the slider value made by the keyboard or mouse. They subscribed to changes to the slider value.

- Richard

[Scott Jehl]

Yes. It seems common to me for someone to utilize that change event
for updating other areas of a UI whenever a slider changes (regardless
of whether it was changed through user mouse events or
programatically ).
I know I've done this several times before in real apps.

One example off the top of my head:
Build a slider from a select menu. Keep that select menu updated
through the slider's change event.

[Scott González]

On Tue, Mar 17, 2009 at 11:32 AM, Paul Bakaus <paul....@googlemail.com> wrote:

I disagree. event.originalEvent is a weak splot in the API. Scott, I agree that we shouldn't even provide it in the first place. The triggered event should have all event properties exposed that you need.

I never said that we shouldn't provide it in the first place.  I was trying to make the point that it's provided because it's useful and that's why we should promote it.  This isn't even a question about how jQuery UI works, this is core jQuery functionality that you're saying shouldn't exist, and I disagree.

[Paul Bakaus]

I think we should expand this argument to the jquery-dev list, I feel it's important this gets resolved.
 

[Ariel Flesler]

I agree with Paul. I PERSONALLY don't like originalEvent and never
relied on it.
Our event object is supposed to be a wrapper, not a carrier.

I'm not sure whether or not to rely on it. It's not going to disappear
anywhere soon and jQuery UI is supposed to be "closer" to the core
than regular code.
By closer I mean that it could use its internal, it's not just another
set of plugins.

So... if you wanna rely on it, it is a safe feature but ugly IMO.

Cheers

On Mar 17, 12:32 pm, Paul Bakaus <paul.bak...@googlemail.com> wrote:

> On Tue, Mar 17, 2009 at 4:20 PM, Richard D. Worth <rdwo...@gmail.com> wrote:
>
> > Agreed. The spec is pretty clear on this:
>
> >http://wiki.jqueryui.com/Slider#specs
> > "change callback: triggers when the slider has stopped moving and has a new
> > value (even if same as previous value), via mouse(mouseup) or
> > keyboard(keyup) or value method/option"
>
> > To me this is exactly why we have event and event.originalEvent. The
> > slidechange event should fire anytime the slider value changes (not only
> > when the keyboard or mouse triggered that change), and event.originalEvent
> > allows you to detect what triggered it.
>
> I disagree. event.originalEvent is a weak splot in the API. Scott, I agree
> that we shouldn't even provide it in the first place. The triggered event
> should have all event properties exposed that you need.
>
> I think we need to find a better way to handle those situations.
>
>
>
>
>
> > - Richard
>

> > 2009/3/17 Scott González <scott.gonza...@gmail.com>

>
> >> Why not?  If we're not going to promote it, then why even provide it?
>
> >> This seems like a perfectly reasonable way to distinguish between
> >> user-initiated events and scripted events.
>

> >> On Tue, Mar 17, 2009 at 10:32 AM, Paul Bakaus <paul.bak...@googlemail.com

> >> > wrote:
>
> >>> That's one possibility, but to me, it feels kind of hackish. We shouldn't
> >>> promote the use of event.originalEvent in my opinion.
>

> >>> 2009/3/17 Scott González <scott.gonza...@gmail.com>

[Richard D. Worth]

How does it work as a wrapper if our custom event has a type of 'slidechange' but was triggered by an event with a type of 'keypress' or 'mousemove'? Where would you get that original event type?

- Richard

[Paul Bakaus]

On Thu, Apr 2, 2009 at 9:15 AM, Richard D. Worth <rdw...@gmail.com> wrote:

How does it work as a wrapper if our custom event has a type of 'slidechange' but was triggered by an event with a type of 'keypress' or 'mousemove'? Where would you get that original event type?

Why do you need the original event type? It should be sufficient to have access to the event properties - having to check what the original event of a custom event was is a broken way of handling things to me.
 

[alexander farkas]

Hi,

I think the change-event should always fire, also, if the event is
triggered programmaticly. there could be bound a lot of listeners (and
not just 1 wich don´t want to listen).
I suggest an option, that will extend the ui-event-object or the jquery
´s event-wrapper object

Let me explain this with the following code:


function carouselUpdatesSlider(e, ui){
if(ui.triggeredFrom != 'fromSlider'){
$('div.slider')
.slider('moveTo', ui.value, 'fromCarousel');
}
}
function sliderUpdatesCarousel(e, ui){
if(ui.triggeredFrom != 'fromCarousel'){
$('div.carousel')
.carousel('moveTo', ui.value, 'fromSlider');
}
}
$('div.carousel')
.bind('carouselchange', carouselUpdatesSlider);
$('div.slider')
.bind('sliderchange', sliderUpdatesCarousel);

I hope it´s clear, what i mean.

regards
alex


On 2 Apr., 07:24, Paul Bakaus <paul.bak...@googlemail.com> wrote:

> On Thu, Apr 2, 2009 at 9:15 AM, Richard D. Worth <rdwo...@gmail.com> wrote:
>
> > How does it work as a wrapper if our custom event has a type of
> > 'slidechange' but was triggered by an event with a type of 'keypress' or
> > 'mousemove'? Where would you get that original event type?
>
> Why do you need the original event type? It should be sufficient to have
> access to the event properties - having to check what the original event of
> a custom event was is a broken way of handling things to me.
>
>
>
>
>
> > - Richard
>

[Paul Bakaus]

On Thu, Apr 2, 2009 at 7:32 PM, alexander farkas <a.farkas.pm@googlemail.com> wrote:

Hi,

I think the change-event should always fire, also, if the event is
triggered programmaticly. there could be bound a lot of listeners (and
not just 1 wich don´t want to listen).
I suggest an option, that will extend the ui-event-object or the jquery
´s event-wrapper object

Let me explain this with the following code:


function carouselUpdatesSlider(e, ui){
       if(ui.triggeredFrom != 'fromSlider'){
               $('div.slider')
                       .slider('moveTo', ui.value, 'fromCarousel');
       }
}
function sliderUpdatesCarousel(e, ui){
       if(ui.triggeredFrom != 'fromCarousel'){
               $('div.carousel')
                       .carousel('moveTo', ui.value, 'fromSlider');
       }
}
$('div.carousel')
       .bind('carouselchange', carouselUpdatesSlider);
$('div.slider')
       .bind('sliderchange', sliderUpdatesCarousel);

I hope it´s clear, what i mean.

I agree. I already successfully implemented that solution in other plugins, notably the selectables in the dev branch (that come with keyboard selection).

In there, it was important to provide information wether a selection was triggered through  the lasso selection or by clicking/keyboard, so the ui event has a very simple boolean 'lasso', so you check for ui.lasso == true/false. This worked out really well in all tests and demos and felt very simple and clean.

I guess I changed my opinion about reintroducing the param to not fire the event again. I therefore vote for integrating this functionality - find a smart boolean and provide it through the ui object - this, after all, is *the* place to provide extra information about the event.
 

[Richard D. Worth]

On Thu, Apr 2, 2009 at 12:24 AM, Paul Bakaus <paul....@googlemail.com> wrote:

On Thu, Apr 2, 2009 at 9:15 AM, Richard D. Worth <rdw...@gmail.com> wrote:

How does it work as a wrapper if our custom event has a type of 'slidechange' but was triggered by an event with a type of 'keypress' or 'mousemove'? Where would you get that original event type?

Why do you need the original event type?

To know whether it was a keypress event, a mouse event, or no event. So you know why it is sliding (in this example). Is it because the user is using the keyboard, or the mouse, or is it programmatic.
 

It should be sufficient to have access to the event properties - having to check what the original event of a custom event was is a broken way of handling things to me.

That would be fine if the event had a property like originalEventType. But then there are other properties that go with it, like keyCode, pageX, pageY. There are two events here (if it wasn't programmatic): the browser event, and the custom event, each with their own properties. Why are we trying to cram them all into one event object?

- Richard
 

[Richard D. Worth]

On Thu, Apr 2, 2009 at 5:39 AM, Paul Bakaus <paul....@googlemail.com> wrote:

On Thu, Apr 2, 2009 at 7:32 PM, alexander farkas <a.farkas.pm@googlemail.com> wrote:

Hi,

I think the change-event should always fire, also, if the event is
triggered programmaticly. there could be bound a lot of listeners (and
not just 1 wich don´t want to listen).
I suggest an option, that will extend the ui-event-object or the jquery
´s event-wrapper object

Let me explain this with the following code:


function carouselUpdatesSlider(e, ui){
       if(ui.triggeredFrom != 'fromSlider'){
               $('div.slider')
                       .slider('moveTo', ui.value, 'fromCarousel');
       }
}
function sliderUpdatesCarousel(e, ui){
       if(ui.triggeredFrom != 'fromCarousel'){
               $('div.carousel')
                       .carousel('moveTo', ui.value, 'fromSlider');
       }
}
$('div.carousel')
       .bind('carouselchange', carouselUpdatesSlider);
$('div.slider')
       .bind('sliderchange', sliderUpdatesCarousel);

I hope it´s clear, what i mean.

I agree. I already successfully implemented that solution in other plugins, notably the selectables in the dev branch (that come with keyboard selection).

In there, it was important to provide information wether a selection was triggered through  the lasso selection or by clicking/keyboard, so the ui event has a very simple boolean 'lasso', so you check for ui.lasso == true/false. This worked out really well in all tests and demos and felt very simple and clean.

That will have to be done differently for each plugin, for each event, and for each thing that might be significant based on how it was originally triggered. And if we didn't forsee a need, the user would be out of luck. Plus, if I saw the parameter ui.lasso I wouldn't assume it was a boolean at all. It looks just like ui.draggable or ui.helper. So I'd assume it's a jQuery object that holds the lasso element, or the DOMElement itself.

I guess I changed my opinion about reintroducing the param to not fire the event again.

Ok.
 

I therefore vote for integrating this functionality - find a smart boolean and provide it through the ui object - this, after all, is *the* place to provide extra information about the event.

We don't need extra information about the event in this case. The original event information will do. The original event type tells you whether it's a keyboard event or a mouse event. Why throw that information away and translate only a piece of it to some custom property on ui? It is part of our event API that our custom events can be triggered by one or more browser events. For example:

dragstart <= mousedown
drag <= mousemove
dragstop <= mouseup

Provide those two pieces of information in each callback (plus any other event properties that go with, like target, key code, modifier keys, mouse position, etc.) and be done with it. If someday we add a capability of dragging with the keyboard, and someone needs to distinguish between the two, they inspect the original event type. Or if there's no event behind it, it's undefined.

While we're on slider, here's a very real example you can use today. If you start dragging a handle by mousedown over the handle, the first slide event's original event type is mousemove. The mousedown triggered slidestart, then the mousemove triggers slide. However if you click on the slider first where the handle isn't, that mousedown event will cause the handle to slide over to be underneath the mouse. In that case the first slide event's original event type is mousedown. The target is the slider, not the handle. All subsequent slide event's original event type's are mousemove. Do you care? Maybe not. But someone might someday. Someday someone might want to know whether a slider handle jumped a huge distance because the mouse went down over the slider far away from the handle, as opposed to the slide starting on the handle. Perhaps they want to prevent that behavior. They could do that:

$("#slider").slider({
  slide: function(event) {
    return (event.originalEvent.Type != 'mousedown')
  }
});

There. No need to build in a feature, or add an option, or an additional property to ui. This is just one example, with one event, in one plugin. The point is, we don't need to worry about whether or not anyone will ever need this information, nor how to present it. It's there. And they can use it.

- Richard
 

[Scott González]

On Thu, Apr 2, 2009 at 8:41 AM, Richard D. Worth <rdw...@gmail.com> wrote:

No need to build in a feature, or add an option, or an additional property to ui. This is just one example, with one event, in one plugin. The point is, we don't need to worry about whether or not anyone will ever need this information, nor how to present it. It's there. And they can use it.

I completely agree with Richard's entire post, but I think this final paragraph really highlights why I think event.originalEvent is so useful.  We've got two developers in this thread already giving examples where they've needed this functionality and I've seen plenty of requests for this on the jquery-ui group.  We already have this functionality built into all our plugins in one consistent way, I don't see any reason to add special cases for each individual plugin and then have even code to implement, test, document and support.

[Paul Bakaus]

2009/4/2 Scott González <scott.g...@gmail.com>

On Thu, Apr 2, 2009 at 8:41 AM, Richard D. Worth <rdw...@gmail.com> wrote:

No need to build in a feature, or add an option, or an additional property to ui. This is just one example, with one event, in one plugin. The point is, we don't need to worry about whether or not anyone will ever need this information, nor how to present it. It's there. And they can use it.

I completely agree with Richard's entire post, but I think this final paragraph really highlights why I think event.originalEvent is so useful.  We've got two developers in this thread already giving examples where they've needed this functionality and I've seen plenty of requests for this on the jquery-ui group.  We already have this functionality built into all our plugins in one consistent way, I don't see any reason to add special cases for each individual plugin and then have even code to implement, test, document and support.

Except that this destroys the whole concept of custom events. Why are we firing custom events? Because we want to provide a simple, unified event to our users when an interaction in the slider happened. Now wether we're suggesting the user should then *split* this information within this event into multiple events, or wether we just forget about the whole concept of custom events - it's exactly the same result. We're back at pure, vanilla JavaScript (ok ok, jQuery).

Again - we provide custom events because users need a reliable, jquerish way to be notified when an interaction happens or has happened. While the events are related to real events, and should share key information of the original event (i.e. mouse position, keyCode etc), they should never be meant to be *containers* of other events as part of our official API.

I therefore 100% disagree with you or Richard (except for the 'lasso' property part - indeed, people could confuse it with a dom element. Not saying this is the best term for it).
 

[Scott González]

On Thu, Apr 2, 2009 at 11:55 AM, Paul Bakaus <paul....@googlemail.com> wrote:

Except that this destroys the whole concept of custom events. Why are we firing custom events? Because we want to provide a simple, unified event to our users when an interaction in the slider happened. Now wether we're suggesting the user should then *split* this information within this event into multiple events, or wether we just forget about the whole concept of custom events - it's exactly the same result. We're back at pure, vanilla JavaScript (ok ok, jQuery).

How does it destroy the concept of custom events?  Events are triggered to indicate that a specific action occured.  Custom events are used because we're adding new functionality so we need new event types.  Nobody has even come close to suggesting that we get rid of custom events, so I don't know why you're even trying to bring that up.  We're also not telling the user to split any information, just that there's one piece of information that's useful in the event which comes from a previous event (the type).
 

Again - we provide custom events because users need a reliable, jquerish way to be notified when an interaction happens or has happened. While the events are related to real events, and should share key information of the original event (i.e. mouse position, keyCode etc), they should never be meant to be *containers* of other events as part of our official API.

Anybody that wants the original information will only be able to get it through the original event, which can only be accessed if the new event is a container.  Think about someone building an app for a specific browser and they need to get at information that isn't standard.  This information will not be copied over to the new event and therefore must be accessed through the original event (actually the original event's original event).

The most common use case is simply going to be determining if the event was triggered programmatically or via a user action.  This is handled just by checking if event.originalEvent exists - this is true for all events in jQuery, not just those specific to jQuery UI.

[Ariel Flesler]

Maybe that's the problem. I'm not 100% up-to-date with your code (ui) but the event object we provide on the core, it's always a fixed version of an event (aka a wrapper).
Maybe you shouldn't even expose the event that triggered this custom event, they're just different events.

I don't agree with the "why not expose it" kind of approach. Encapsulation is indeed a good thing and in most cases, there's a way around that doesn't require to give out any existing data to the user.

If the slider changed its value, then why does it matter how (externally) ?

--
Ariel Flesler
http://flesler.blogspot.com

[Richard D. Worth]

On Thu, Apr 2, 2009 at 3:28 PM, Ariel Flesler <afle...@gmail.com> wrote:

Maybe that's the problem. I'm not 100% up-to-date with your code (ui) but the event object we provide on the core, it's always a fixed version of an event (aka a wrapper).
Maybe you shouldn't even expose the event that triggered this custom event, they're just different events.

I don't agree with the "why not expose it" kind of approach. Encapsulation is indeed a good thing and in most cases, there's a way around that doesn't require to give out any existing data to the user.

If the slider changed its value, then why does it matter how (externally) ?

See the first message in this thread.

- Richard
 

[Ariel Flesler]

Hi Richard

The first post doesn't mention originalEvent, sorry if I don't fully get this things, Scott asked to chime in and I'm doing my best :)

As for the value changing problem. I'd add another method, one that changes the value and another that calls the first one AND propagates events.

[Richard D. Worth]

On Thu, Apr 2, 2009 at 3:38 PM, Ariel Flesler <afle...@gmail.com> wrote:

Hi Richard

The first post doesn't mention originalEvent, sorry if I don't fully get this things, Scott asked to chime in and I'm doing my best :)

The first post doesn't mention originalEvent, you're right. But it points at just one example of why you might want to know how the change was triggered. I pointed out another here

http://groups.google.com/group/jquery-ui-dev/msg/35142ed7cc188ad7

There are countless others. A dialog closing because the close method was called vs. the user clicked the 'X' with the mouse vs. they pressed the ESC key, is just one more.
 

As for the value changing problem. I'd add another method, one that changes the value and another that calls the first one AND propagates events.

There are multiple ways a slider value can change:

- keypress (UP, DOWN, LEFT, RIGHT, HOME, END)
- mouseup
- value option (or values option)
- value method (or values method)

Regardless of how it changes (the original source of the trigger), there need only be one event: change. This event fires any time the value changes. There's no propogation here. You shouldn't be able to change the value without this event firing. Because anyone listening to this event is interested in knowing whenever the value is changed. Only that listener knows whether they care about why or how it was changed, not the party triggering the change (whether programmatic or otherwise). That's why there should only be one event, and it's why it's a custom event. The type of that event is 'slidechange', meaning "the value of the slider changed". Inside that event callback, which has been passed the 'slidechange' event as the first parameter, it's quite useful to know what browser event (if any) originially triggered this custom event. Not only to know the type, but to actually have the event, along with all its properties, which is a different set of properties than the 'slidechange' event.

- Richard
 

[Paul Bakaus]

On Fri, Apr 3, 2009 at 5:18 AM, Richard D. Worth <rdw...@gmail.com> wrote:

On Thu, Apr 2, 2009 at 3:38 PM, Ariel Flesler <afle...@gmail.com> wrote:

Hi Richard

The first post doesn't mention originalEvent, sorry if I don't fully get this things, Scott asked to chime in and I'm doing my best :)

The first post doesn't mention originalEvent, you're right. But it points at just one example of why you might want to know how the change was triggered. I pointed out another here

http://groups.google.com/group/jquery-ui-dev/msg/35142ed7cc188ad7

There are countless others. A dialog closing because the close method was called vs. the user clicked the 'X' with the mouse vs. they pressed the ESC key, is just one more.
 

As for the value changing problem. I'd add another method, one that changes the value and another that calls the first one AND propagates events.

There are multiple ways a slider value can change:

- keypress (UP, DOWN, LEFT, RIGHT, HOME, END)
- mouseup
- value option (or values option)
- value method (or values method)

Regardless of how it changes (the original source of the trigger), there need only be one event: change. This event fires any time the value changes. There's no propogation here. You shouldn't be able to change the value without this event firing. Because anyone listening to this event is interested in knowing whenever the value is changed. Only that listener knows whether they care about why or how it was changed, not the party triggering the change (whether programmatic or otherwise). That's why there should only be one event, and it's why it's a custom event. The type of that event is 'slidechange', meaning "the value of the slider changed". Inside that event callback, which has been passed the 'slidechange' event as the first parameter, it's quite useful to know what browser event (if any) originially triggered this custom event. Not only to know the type, but to actually have the event, along with all its properties, which is a different set of properties than the 'slidechange' event.

Just a note to that last sentence - that's not entirely true. It's not a very different event, since we already make sure the properties of the original event are copied over to the custom event. We once decided that this custom event should be the one that's designed for the widgets, and people should use - it should, by default, come with all properties someone could possibly need (with the extension of the ui object).