Hi Thomas, I hope you don't mind me following up again on this topic but after implementing onUnload to remove event handlers (which worked, of course) I realized that this approach is inappropriate for my application. The reason is that my application is basically modeless - meaning that I can remove a widget from the dom and hold onto the widget object via a reference, replace the widget in the dom with another widget and at some future time restore the widget that I removed.
Here's a use case for such a scenario: Composite A which is a singleton is created and once attached to the dom it will remain attached for the lifetime of the application. Composite A is a view of a list of data models and when the user selects a data model to edit from the list Composite A hides itself and then shows a sub view which is Composite B that allows editing of the data model's attributes. Composite B has numerous list box widgets that contain values that can be created from other Compsosite views in the application. At some point the user needs to select a value from one of these list boxes but the value doesn't exist so the user switches to a different view, Compsite Z, which replaces Composite A by removing it from the dom and inserting itself into the dom. While in Composite Z's view the user adds a new value. Once she saves the value Composite Z will fire off an event notifying that a new value now exists which Composite B handles even though at the time it handles the event it is not attached to the dom. The user then switches back to view Composite B which replaces Composite Z by removing it from the dom and adding itself back to the dom and in the list box the user now sees the new value which Composite B added to it when it handled the event that Composite Z had fired. As the above use case demonstrates, my application is extremely modeless and is very similar to a desktop application in that regard. In order to get onUnload to work for my use case required that Composite B check a boolen attribute which is only set to true when the user actually closes Composite B which sets the boolean to true and if true actually calls removeHandler. Do you think the current GWT implementation of MVP would be appropriate and be able to handle my use case of using modeless views as described above? Thanks in advance, Jeff On Tue, Dec 21, 2010 at 4:07 AM, Thomas Broyer <[email protected]> wrote: > Actually, because the EventHandler has a reference to the class that > created it (in most cases, and it's true in your case), then as long as it > is referenced by the EventBus, it won't be garbage collected, and neither > will be its "owner" class. There's no "dead event handler", only things that > you no longer use but haven't destroyed, so they're still there, listening > and handling events, without anyone to notice it (because your code no > longer has any reference on them). > You really should clean after yourself; onLoad/onUnload on widgets might be > a solution; but having a real lifecycle for your classes would be best (this > is where MVP shines through, e.g. the start/onCancel/onStop methods of > activities) > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- *Jeff Schwartz* -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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/google-web-toolkit?hl=en.
