Modules communication

Topics: CAB & Smart Client Software Factory
May 4, 2006 at 10:13 PM
originally posted by: activeperception

Dear friends,

I am taking a look at CAB to develop a standalone windows application. It will be based on plug-ins/modules and we want to use MVC/MVP.

So CAB seems to be the perfect solution. Although I saw the hands on labs and some tutorial there is something missing: how modules can communicates?

At least in the examples I saw 'commands, states and events' seem to be used withiin the same module. How can I for example share a state between two indipendent modules that is stored in a workitem belonging to a third module? at what about events and commands?

Moreover I have probably a stupid question, what is a rootWorkItem? It is a 'dummy' workitem to which all other workitems belong (also the workitems in modules)?

Thanks a lot,
Raffaele
May 5, 2006 at 5:29 AM
originally posted by: ChrisHolmes

"It is a 'dummy' workitem to which all other workitems belong (also the workitems in modules)? "

It's a real WorkItem. It is just the WorkItem at the top of the hierarchy. In most cases this not a subclassed WorkItem, which is why you aren't seeing any extra code for it anywhere in the samples.

"how modules can communicates? "

EventBroker. And event fired from WorkItemA in ModuleA can be received by WorkItemB in ModuleB. When you create an Event for use with EventBroker you decorate it with an attribute and that attribute takes some parameters, namely a string that uniquely identifies that event and a scope (workItem, global, etc.). So you can set the scope on an EventBroker event to Global and any WorkItem anywhere that knows the string name of that event can catch it and do some work.


"How can I for example share a state between two indipendent modules that is stored in a workitem belonging to a third module? at what about events and commands?"

You wouldn't share state between two independent modules, because that would identify a shared dependecy. Then they are no longer independent modules. They would need a reference to that third module and that's a dependency you probably don't want. (It is possible in the CAB to declare a module to have a dependency on another module.)

What you're more likely to do with WorkItems that are truly independent - totally unaware of each other - is inject their WorkItems with a Service of some kind that allows them to subscribe to the same data.

Keep in mind too, modules are physical storage of code, nothing more. They are .dll files. WorkItems are the logical Use Cases, where State is managed and Services are injected. A module can contain many WorkItems. If they're all doing similiar work, and need access to shared State and have the ability to create each other, then they probably should be contained in the same Module.

Finally, Commands work similiar to EventBroker events. When a UIElement is added somewhere and a Command is attached to it, the commandName (a string) is registered with it. If a WorkItem knows the name of the Command it can respond to that UIElement's Click() event. So it's possible for a ToolStripMenuItem to fire a Command that several WorkItems in independent Modules receive.