Just bumping this to see if I can get any more info on the potential  
problems in the event chain. Perhaps I'll try to explain it a  
different way.

I use custom events to control flow in my application.

Some events are - for lack of a better term - local. They are not  
deferred. For instance when a user clicks a button and a certain  
condition is met a dialog (which is part of the DOM not a browser  
dialog like alert()) is shown.

The buttons in that dialog signal an event that determines what  
happens next. As long as this custom event chain does not involved  
deferred's, everything works well.

But if somewhere in the event chain a deferred runs (with it's own  
callbacks), any custom events connected after the deferred runs are  
not executed.

Why does that happen?

The solution is to connect all 'local' events first, because they  
will be executed in order and run the deferred at the very end. This  
workaround is ok, so as long as you only have ONE deferred to worry  
about.

My app has grown a bit and it's hard to post code here. It's also  
really hard for me to explain, because I'm grappling with the  
terminology.

But if you would like to take a look-see Bob, I'd be more than happy  
to point you to a link where you can see what I've got. I'll even  
call you and walk through it with you. Just let me know.

It's perfectly possible that I need to change my design, but first  
I'd like to know if a deferred that firing it's callbacks is supposed  
to nix all other pending events.

Thanks,
Juergen








On Sep 26, 2006, at 12:04 PM, Juergen Schreck wrote:

>
> So, I'm using custom non-DOM events. Works nice. Today, I discovered
> a problem:
>
> var controller = {
>
>       clickHandler: function(e) {
>               disconnectAll(controller, 'onsave', 'ondiscard');
>               connect(controller, 'onsave', bind('hideConfirm', view ));
>               connect(controller, 'onsave', bind('changePage',controller, 
> data));
>               view.showConfirm();
>       },
>
>       changePage: function(data) {
>               //do stuff, triggers subsequent XHR with callbacks
>       }
> }
>
> var view = {
>       showConfirm: function() {
>               // shows modal dialog
>       },
>
>       hideConfirm: function() {
>               // hides modal dialog
>       }
> }
>
>
> connect ('someelement', 'onclick', controller.clickHandler);
>
>
> The order of events in the clickHandler function seems to be of
> significance. If I define the hideConfirm() event AFTER the changePage
> () event, it never gets executed. If I defined it BEFORE (as shown
> above) both get executed.
>
> I've tracked it down to one key difference in what the functions do.
> The hideConfirm() function simply hides the dialog which triggers no
> additional events.
>
> The changePage() function causes a XHR to be executed which has it's
> own callbacks of course. So I have to assume that definition of a
> callBack on that subsequent XHR interrupts the current event chain,
> causing hideConfirm to never fire.
>
> Is that a bug? Or is there some plausible explanation for it?
>
> It's ok for me to reorder the events right now, but ultimately I'd
> like the dialog to be closed after or 'while' the XHR is executing.
>
> >
>


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~----------~----~----~----~------~----~------~--~---

Reply via email to