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

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

rickcr gravatar image 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?

delete flag offensive retag edit

The question has been closed for the following reason "the question is answered, right answer was accepted" by rickcr
close date 2013-03-01 04:36:22

1 Answer

Sort by ยป oldest newest most voted

answered 2013-02-28 04:01:46 +0800

rdgrimes gravatar image rdgrimes
735 7

updated 2013-02-28 04:16:28 +0800

Have you tried using the autoUnsubscribe option when you set up the @Subscribe? See link. It's been available since 6.5.1. Theoretically, you shouldn't have to specify it, since its default is true. So, maybe it's just a matter of upgrading your project to 6.5.1.

See also bug fix here. Note by Dennis indicates its been fixed since 11/21

link publish delete flag offensive edit


Wow awesome! I was having that issue right around that October time period and didn't catch that it was fixed in November! Excellent news because that was driving me crazy. Now I can go back to having a better separation of concerns (composers with view specific data, and my view models clean.)

rickcr ( 2013-02-28 19:17:11 +0800 )edit

Question tools




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

Seen: 23 times

Last updated: Feb 28 '13

Support Options
  • Email Support
  • Training
  • Consulting
  • Outsourcing
Learn More