Pass event data

[Mike Frawley]

I added a spec and implemented being able to pass data when triggering
events. Example:

$('.beats').concrete({
onplay: function (event, data) {
this.play(data.track);
},
…
});

$('.beats').trigger('play', {track: 'drum&bass!'});


Before data was always undefined, but now useful data can be passed
along. I'll be using this in my flippy card game :)


It was a simple fix, not really sure what `originalevent` was supposed
to be doing. None of the other handlers proxies were using it.

commit:
http://github.com/ratbeard/jquery.concrete/commit/9183633aeb35acce66611eebc81939e5c43776ea

[hamish]

On Oct 22, 8:18 am, Mike Frawley <frawl...@gmail.com> wrote:
> I added a spec and implemented being able to pass data when triggering
> events.  

Thanks for the specs. This is a valuable feature, and I suspect other
people will expect events to work this way. I'll integrate the specs
and get this working.

> It was a simple fix, not really sure what `originalevent` was supposed
> to be doing.  None of the other handlers proxies were using it.

Unfortunately it is used. To be able to delegate onsubmit, we bind an
onsubmit to every form node, which then trigger a 'delegated_submit'
event on the document node with the original onsubmit event as the
data. Check the delegate_submit function at the bottom of
jquery.concrete.events.js

I see a couple of ways around this:

Create build_onsubmit_proxy which is the same as build_proxy is now.
We can then remove the originalevent stuff from build_proxy. It'll
mean you can't pass data when you trigger onsubmit, which is a weird
edge case, but probably not a problem in practise.

Change delegate_submit to create an event object to pass as the first
argument of the triggerHandler call instead of just a string, and
attach the originalevent as a property to the event.

I think the second way's the best. Feel free to do this if you like,
or I'll try and tackle it over the weekend.

Hamish Friedlander

[Michael Frawley]

On Wed, Oct 21, 2009 at 3:33 PM, hamish <ham...@silverstripe.com> wrote:

On Oct 22, 8:18 am, Mike Frawley <frawl...@gmail.com> wrote:
> I added a spec and implemented being able to pass data when triggering
> events.  

Thanks for the specs. This is a valuable feature, and I suspect other
people will expect events to work this way. I'll integrate the specs
and get this working.

Expect to see more specs from me - I'm using JSpec on a big project and love it :)

 

> It was a simple fix, not really sure what `originalevent` was supposed
> to be doing.  None of the other handlers proxies were using it.

Unfortunately it is used. To be able to delegate onsubmit, we bind an
onsubmit to every form node, which then trigger a 'delegated_submit'
event on the document node with the original onsubmit event as the
data. Check the delegate_submit function at the bottom of
jquery.concrete.events.js

I see a couple of ways around this:

Create build_onsubmit_proxy which is the same as build_proxy is now.
We can then remove the originalevent stuff from build_proxy. It'll
mean you can't pass data when you trigger onsubmit, which is a weird
edge case, but probably not a problem in practise.

Change delegate_submit to create an event object to pass as the first
argument of the triggerHandler call instead of just a string, and
attach the originalevent as a property to the event.

I think the second way's the best. Feel free to do this if you like,
or I'll try and tackle it over the weekend.

Hamish Friedlander

 

I like that second option too.  I'm interested in what it says at the bottom of:

http://docs.jquery.com/Events/jQuery.Event 

about creating event objects.   I'll try playing around with it tonight.

Mike

[Mike Frawley]

Wasn't able to figure out a great solution, or understand enough about
custom event objects to get it working. I did add some more specs
though, and I handle the submit event case now by checking for a
_replace_event property and the event data object that is passed, and
replace `e` with that object if it exists. I set that property only
when submit is triggered. A temporary hack solution :)

http://github.com/ratbeard/jquery.concrete

I also found a strange bug, that when I have 2 specs that are testing
form.submit, and have concrete handlers bound to that return false to
stop the propogation, the second spec does not stop it and I need to
have an additional

$('form').submit(function () { return false;})

to not make it submit. I added a comment in about this

I still don't have a complete understanding of jquery events, and
concrete's event handling, but it looks like concrete's handling is
reimplementing some of the jquery event handlers, and maybe by
building a custom event object that knows about concrete's delegation
we could avoid that?

˙∆˚ Mike

[hamish]

On Oct 26, 8:34 am, Mike Frawley <frawl...@gmail.com> wrote:
> I set that property only
> when submit is triggered.  A temporary hack solution :)
>
> http://github.com/ratbeard/jquery.concrete

I've pulled your changes, and updated the onsubmit delegation stuff to
use custom event object passing rather than data object hacking (as
well as a bunch of other tweaks).

> I also found a strange bug, that when I have 2 specs that are testing
> form.submit, and have concrete handlers bound to that return false to
> stop the propogation, the second spec does not stop it and I need to
> have an additional
>
> $('form').submit(function () { return false;})
>
> to not make it submit.

There were a couple of issues:

You were attaching the forms to body, rather than #dom_test, so the
forms weren't getting removed between tests

I wasn't unbinding the event handlers on $.concrete.clear_all_rules,
so old submission handlers were getting triggered

These both should be fixed. I've also made all the spec forms have
action="javascript:undefined" so that even if there is a bug in the
event handling code, we won't get that annoying continual-refresh bug.

> I still don't have a complete understanding of jquery events, and
> concrete's event handling, but it looks like concrete's handling is
> reimplementing some of the jquery event handlers, and maybe by
> building a custom event object that knows about concrete's delegation
> we could avoid that?

Concrete does sort of duplicate jQuery live, but unfortunately their
call semantics are too different to let me wrap live - I tried, and it
just resulted in lots of weird bugs.

By itself jQuery live doesn't handle onsubmit or onchange or
mouseenter / leave or any of the other events that concrete needs
custom handlers for anyway, which is the bulk of the code.

Hamish Friedlander

[Mike Frawley]

Doh, I missed this response in my inbox, and was coming on to ask if
you'd pull in my hack. I'll take a look at your changes you put up
this week. Glad you could figure out that form submitting issue. I
still got a ways to go to understanding jQuery's event system but this
helps.

Mike