http://jsfiddle.net/8n7hk/7/

Like Sandford says, you'll have to removeEvents either way. Since you're 
working with a Class that contains your element, you can add a destroy 
method to trigger the removeEvent for you.

On Saturday, March 2, 2013 1:23:13 PM UTC-8, Sanford Whiteman wrote:
>
> I assume I cannot simply destroy the view elements and their references, 
> but also manually detach any events. What I'm curious about is if there is 
> an automated way, or, perhaps a listener I'm not familiar with for the 
> view's main element (for instance, if the view's element is destroyed in 
> another manner, like parent.empty(), can I also destruct the view class 
> appropriately?).
>
> I don't think there's anything built in to Moo that is automatically going 
> to detect the dependencies in your model and remove the event.  So 
> basically you should call context.mediator.removeEvents('fire') or put a 
> backlink to the Mediator in each Box and then call mediator.removeEvents() 
> (the latter breaks the encapsulation I think you're building).
>
> No matter which, you have to removeEvents, because what you are seeing is 
> a core refcount/closure feature of JS.  You've got an open "handle" to the 
> function, so you can't `delete` it.  And even if you did refactor to be 
> able to `delete` it (hanging the real event listener off the window and 
> wrapping the call in another function, for example) you'd just get errors 
> when it got called, which isn't clean. 
>
> -- S.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"MooTools Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mootools-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to