A reply from Aaron Newton which I got:
------
[...] It sounds to me like your design is inverted. You have the
controller attached to the UI controls instead of the other way
around. Right now, it's as if your grid view has a slideshow, instead
of the slideshow having a gridview. It seems to me that you should
have a slideshow class (perhaps an extension of Ryan's work) and your
extension has this thumbnail manager as a component. That manager
doesn't do anything to the UI; it just knows which one got clicked
last and it has functions to disable and enable its click listener
(you should be using event delegation for this, btw). When the user
clicks an image, the grid fires its event. Your controller tells the
grid to become disabled and it adds a selected css class to the thumb
and then invokes the slideshow control. When the slideshow fires its
complete event or whatever, you re-enable the grid view. [...]
------
Basically he is attaching/detaching (with delegation) the events in
the thumbnail class, Class 1.
In my case I don't think I have it in the wrong way; i've extended
Ryan's slideshow to my needs and I have a thumbnail manager which is a
seperated class that triggers the extended SlideShow class among other
things (so therefore, the thumbnail class isn't integrated or directly
linked to the SlideShow).
I guess working with a seperate controller class (myApp = new events()
or something) would be the best solution to either disable events or
set some "frozen" variable in a class (I don't know what will use the
most memory, introducing a frozen var and check against it, or
attaching/detaching events all the time with delegation).
On Aug 23, 10:18 am, Rolf -nl <plentyofr...@gmail.com> wrote:
> 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
