ZK team plans to dispose of Composer EventQueues no longer in scope? [closed]

asked 2013-02-27 15:59:29 +0800

rickcr
704 ● 7

In a previous post I tried to articulate why I've opted to use a ViewModel for everything instead of a Composer, even if it means managing UI components in the ViewModel http://forum.zkoss.org/question/82683/why-im-using-a-viewmodel-and-not-a-composer-for-everything/

Some of that thread got hijacked so I'm starting a new one since I'm curious on the status of this situation?

I'm now working on a new application and I need to dynamically create some UI components based on a notification that comes from a ViewModel. If I simply use a ViewModel to listen for the global event (@GlobalCommand) and build everything in this ViewModel method, everything is fine. HOWEVER, if I try to be "pure" and use a Composer and subscribe to an EventQueue (@Subscribe) and listen for a broadcast event from a ViewModel, the issue is the Composer is not cleaned up properly when it goes out of scope.

For example imagine you were creating different pages to fill in a content area using Executions.createComponents (which is common.)

On your page you have a ViewModel bound, and part of your UI has a composer applied to it as well. Based on something happening in the the ViewModel, the VM needs to notify the Composer of something so that it could modify the UI components.

The issue is the Composer's subscribed queue listener is NOT removed when that page goes out of scope! ... that is when a new request calls clear() on the content area where the page is and a new call to Executions.createComponents is called and a new page is added to the content section. (I'd think ZK should handle cleaning up any of the listeners bound to pages that are no longer attached to the UI.)

If this new page has a ViewModel that broadcasts the same type of event and it has a UI component that has the same type of Composer applied to it, you'll end up with BOTH composer's queues firing. Every new page added, will add another one to the mix. This is very bad.

Yes, I've read up on potential ways to try to clean up queues that are listening, but it's a royal pain and clutters the code up. Why can't the behavior work the same as it does for ViewModels that have a @GlobalCommand defined? They seem to go out of scope just fine without having to clean them up?

So, until this issue is addressed, are there some technical reasons why I shouldn't use a ViewModel for also handling UI specific functions like building some UI components on the fly?