I'm just now listening to the podcast about managing listeners. It seems to me that the best way to handle this consistently is to stick to the same model used with listeners in the first place: "Merely" overload the basic addListener methods to allow a second parameter which would be the "Listener-Cleanup Listener." Every time the listener is called, the listener-cleanup listener is also called to determine if the listener should be removed, replaced, or even added to. I understand that this may require quite a lot of deep subclassing to override the appropriate methods in some of the most basic classes in javax.swing. But it would be just as clean and flexible as the current listener model once fully implemented.
Now, I believe one of the panelists mentioned something like this. Another panelist also mentioned using some kind of grand framework which would be able to track listener activity. It is possible to do both. Simply create a separate "ListenerManager" class which the listener-cleanup listeners communicate with. Why do I think it is better to add a second parameter to the addListener methods than simply add statements to your listeners? Because you want to keep your event handling separate from your listener management. Adding listener management statements to your event listener classes or methods means you will need yet another listener for each and every combination of event-handling behavior and listener-management behavior. Yeah. Not the best plan. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
