Trying to understand Event.Target's fire method

I'm working on a subclass of Widget which publishes a custom event. When the Widget fires it's custom event I would like the subscriber of that event to get two additional arguments. This seems straight forward but I ran into problems:

Code:

this.fire( E_REQUEST_OP, node.get('name'), this.get(ID) );

where E_REQUEST_OP is coming through with the correct Widget.NAME prefix (bundle:requestOp), node.get('name') = start, this.get(ID) = 123. Effectively:

Code:

this.fire( 'bundle:requestOp', 'start', 123 );

My Widget instance looks something like this:

Code:

var OSGiBundle = new Y.Bundle(data);
OSGiBundle.on('requestOp', function(e, args){
   Y.log(arguments);
});
OSGiBundle.render('#container');

What was odd, is that the log of the subscriber callback function's arguments didn't contain 'start', but did contain 123. This seems odd to me...

I took a deep drive through the code, Widget, Base, Event.Target, and nothing really stood out besides the Widget Class seemingly having this same issue. In the render method of Widget, a render event is fired like this:

Code:

this.fire(RENDER, null, parentNode);

Notice, null as the second parameter??? I was able to get around this issue in my code as well:

Code:

this.fire( E_REQUEST_OP, null, node.get('name'), this.get(ID) );

But I don't understand why I have to do this, or what the deal is the fire method, since according the to documentation, my first approach (without null) should work fine.

BTW, I tested this on 3.0.0pr2 and yui3-568 on GitHub

So what's the deal guys? Is there something wrong here, or something I'm missing about the fire method?

The first parameter can be a data object that is applied to the event facade that is returned to the subscribers for events configured to emit event facades (which is the case for all of the events in the widget infrastructure). This has some effect on the subscriber signature, and this probably needs to be adjusted. See the following bug report: http://yuilibrary.com/projects/yui3/ticket/2151030, and please add any additional you might have.

Another related comment:

I'm not totally sure why custom events which I have my widget instances publish can't be subscribed from outside the event host. For example, Say I have code which instantiates a bunch of WidgetX instances which publish a custom event. Instead of subscribing to each widgets custom event, I just want to subscribe to the event type and have a generic handler deal with it. Even with setting the bubbles and broadcast options explicitly it seems to have to effect on custom events published by a widget.

I don't want to create a bunch of similar listeners, I want my WidgetX custom events to bubble up and handle them in on listener. I don't want my publisher to know or have reference to my subscriber as in the code example: http://developer.yahoo.com/yui/3/exampl ... nt-ce.html

Is there something I'm missing here?

This is something that Y.on is supposed to support, but it doesn't yet -- I am planning to fix this soon.

Adam,

Great to hear. If you remember would you post back here after the commit that has the change is posted on GitHub?

Also adding reference to enhancment request for event "prefix" configuration support in Event.Target, per Adam's request: http://yuilibrary.com/projects/yui3/ticket/2526049

Eric, I added an additional bug for the specific feature you need (which is related to, but not precisely the same as the one Satyen added). This bug will be updated once the feature is available on GitHub:

http://yuilibrary.com/projects/yui3/ticket/2526051

I neglected to mention that the YUI instance is itself an event target. Therefore it should be possible to do what you want by doing something like:

Code:

eventtargetref.addTarget(Y);

Then...

Code:

Y.on('prefix:event', fn);

...should execute the listener every time any target configured this way fires the event.

Code:

eventtargetref.fire('prefix:event');

The purpose of the bug report is to bake this into the broadcast config.

I added myself to be CCed on the bug report. In the meantime I'll give your suggestion a try if I run up against this again. Thanks Adam.

Hello Eric, Adam,
it seems I have a very similar problem, that is not solved with your suggestion.

1.) I want a normal a-tag to trigger a form-submit.
2.) different code wants to listen for this submit-event and do something (and maybe even preventDefault).

I came up with
- registering Y.on('click', onButtonClick, '.formbutton a',null, Y);
- in onButtonClick(..) I do myForm.submit();
- a different js-file contains something like Y.on('submit', onFormSubmit, '#myForm');

But the Listener on form-submit never gets informed. Yes, the two Y instances are different ones.
What can I do?

(I already tried to fire custom events on Y instances, but that did not help)

Thanks for your hints; I cannot believe that it is not possible to fire events across Y instances....

Forums

Eric Ferraiuolo

YUI Developer