The Inter Module Communication Feature in DNN
The Inter Module Communication (IMC) is a very versatile and pointed way to transfer data within modules in your portal. Although IMC can do many things for you, the name is misleading and this section will attempt to organize its merits as well as improper uses.
In 2.0.1 beta DNN, the IMC was enhanced to allow four new properties in the interface. In the original version carried over from IBuySpy to DotNetNuke 1.x series, there was one property: [TEXT], and you could pass a string from a sender module to a receiver module. However there was no way to determine the Sender or Target, or the Type of message, and there was no way to pass an Object. This was remedied and properties were added to facilitate this required functionality. However, the enhancements spent about 6 months in limbo while 2.0 was being compiled, and as it works out, this is a fortunate thing.
A last minute change resolved the dependency of IMC on caching and isolates it from the skinning functionality resolving the interface to be a base function, and IMC in 2.0.1 beta DNN works as desired. Now, the question is, what do I use IMC for, and what do I NOT use it for?
This section will showcase several modules that use IMC currently, and how they implement it. As well it will show circumstances that IMC will not be functional in, even though it “seems” like an appropriate use.
How It Works
Inter Module Communications provides a simple, direct one way communication to other modules within your portal. The nature of this communication is through a raised event I will call iTalk, which is raised to the next postback of that page (tab) and is raised somewhere during PageInit. I say somewhere, because the actual event is raised within the control and event tree, so these will vary depending on the arrangement of your tab. The values in this event are made accessible to all modules existing within that tab and they can listen for chatter that is aimed at the module type, target, and sender values, I call this iListen.
The ModuleCommunicator class is inherited into your module.
Then ModuleCommunication event is raised within the iTalk module that carries your chatter to the next pageInit, where the OnModuleCommunication Sub in your iListen module can intercept and utilize the values.
Public Interface IModuleCommunicator
Event ModuleCommunication As ModuleCommunicationEventHandler
End Interface 'IModuleCommunicator
_
Public Interface IModuleListener
Sub OnModuleCommunication(ByVal s As Object, ByVal e As
ModuleCommunicationEventArgs)
End Interface 'IModuleListener
How Not to Use It
The most common assumption of IMC is that it will enable you to pass objects between modules. Although this is true, the value will only persist for a single postback. When the page is refreshed the IMC will become nothing. This is easily maintained by the use of Session or viewstate variables that are declared within your modules that look for IMC and store it for that module, user, etc. If the data needs to be intercepted and stored in the database, or used in another concurrent postback, you would implement a custom Listener to attach to that data and process it accordingly.
In no case will the IMC string persist beyond the initial post without programmatic help. The IMC is often mistaken for a medium to transfer data without the use of a database. In some cases this is correct, but to use IMC in this way and access the data beyond the next postback or request requires a more robust layer, including session or database.
How to Use It
In all cases the IMC is meant to be used within modules on a single tab, or in modules that redirect to another tab and that tab has a module on it that can receive the IMC objects.
The beauty is that you can efficiently pass objects between modules, or cast them to an interim listening device.
1. Step One: Determine the [SENDER]: Here you give your modules the ability to attach to only IMC object sets from a certain Sender. This is usually the ModuleName of the sending module, as set in the module definitions. If a Sender is included in the IMC object set, and a Listener module is configured to Receive from the Sender, then it will only attach to an IMC object set for that Sender.
2. Step Two: Determine the [TARGET]: Here you give your modules the ability to attach to only IMC object sets aimed at a certain Target. This is usually the ModuleName of the receiving module, as set in the module definitions. If a Module is configured to listen to only the Target of MyModule then it will only attach to an IMC object set for that target.
3. Step Three: Determine the [TYPE]:: a configurable property where you set the type in the Talker and then the Listener looks for that type. If a Module is configured to Listen to only the Type of MyModule then it will only attach to a IMC object set of that type.
4. Step Four: Determine the [VALUE]: This is the only Object property in IMC, and you can pass any complex object between modules. This includes a dataset, a control within state, or any other thing you can imagine. The requirement is for a listener to know what to do with the Object and its state.
5. Step Five: Determine the [TEXT]: this is a relatively straightforward answer... a simple text string. In the original IMC, this was the only property.
