This is a follow-on question to Is publishing/subscribing to events after UI rendering a best practice regardless of framework? which I asked last month as we first went down the pub/sub path with a Javascript/ExtJS application. If you want to get to the meat of my question from a purely publish-subscribe standpoint, please see the first, emphasized, sentence of the next to last paragraph. First a bit of context:
We have a panel that contains a tab-panel whose cards hold a grid panel, and a panel that holds a form for filtering the grid data. In the beforechangetab event we add/remove a shared grid and publish GRID_TAB_TOGGLED message along with a flag indicating stocked or non-stocked, and the grid then reloads with the appropriate data.
As for the filters, the code I inherited relied on just one form, and combo box choices get modified based on the loaded stocked/non-stocked data, but now we are required to retain all of the filter state. My initial idea is to use a card layout for holding either stocked or non-stocked filters, and toggling between these in response to the same GRID_TAB_TOGGLED message.
The issue though is that both of these filter forms need to listen for other, numerous, identical events. I think I've determined a solution, and am seeking design validation.
My idea is for the different forms to be able to determine whether they are the "active" (stocked or non-stocked) filters, and if active, subscribe to all necessary messages, but if not active, unsubscribe from them all. This un-subscribing, re-subscribing then would occur whenever the GRID_TAB_TOGGLE message was received.
Does this seem like a reasonable design, from an ExtJS standpoint, but of more interest to me (since I have nearly 3 years ExtJS experience, but only 1.5 months implementing my own pub/sub based system), from a publish/subscribe paradigm standpoint? Perhaps this is even a pattern (or, though I hope not, an anti-pattern) for pub/sub based systems?