Exactly, else you would attach/detach all the time..
I'm talking about the situation were several classes work "together"
and might also have something running not in a class (because it's
very site specific, like an fx chain) and all is triggered from a
click event in one of the classes. The abstracted class doesn't have a
busy state or something, because it doesn't "belong" to the class if
you look at it individually.
For example (trying to keep it short this time):
- Class 1 does basic thumnail stuff: It takes a container and creates
an internal list (array). It attaches a click event that sets the new
current thumbnail via a setCurrent method. Doing that it will add a
css class current to the element (which you might want to use),
currentIndex in Class 1 will change and the click event fires an event
back.
- myApp reacts on the fired click event from Class 1: It triggeres a
function chain that start some fx and somewhere in the chain it might
call a slideshow.show and at the end of the chain myApp is done and
not "busy" anymore.
- During the routine, Class 1 doesn't know what is happening in myApp
and you can still click thumbnails chaing the current. myApp might
prevent further actions because it's "busy" and won't trigger the
function chain, but internally Class 1 it will change the current. So
when myApp is finished for thumbnail 1, internally in Class 1 the
currentIndex might be 6.
How would you solve such a thing?
You would have to extend nearly every class that has user interaction
events (click, mouseenter, etc.) if you must introduce some "busy" or
"freeze" state. And myApp (or something outside Class 1 in this case
anyway) should reset that state within Class 1 (onChainComplete()
{ Class1.frozen = false; })
Currently I solve this issue (preventing clicks) by putting a
transparent container above "active" elements to prevent clicks on
elements below (using an e.stop() on that container during routines.
When a routine is done I move it away. Pretty simple, but it feels
like a wrong solution for the actual problem.
On Aug 23, 8:17 am, אריה גלזר <arieh.gla...@gmail.com> wrote:
> On Mon, Aug 23, 2010 at 5:19 AM, Ryan Florence <rpflore...@gmail.com> wrote:
>
> > It's usually a method called 'detach', if I'm following this conversation
> > correctly. (Just skimming!)
>
> > If I ever attach events, I always provide a way to detach them.
>
> no. he's talking about preventing an event from firing while an effect is
> ongoing, not a way to cancel the event attachment.
> --
> Arieh Glazer
> אריה גלזר
> 052-5348-561
> 5561
