The XML configuration file for the above application is shown in Annexure-2. 

 
The “containerConfiguration” element shows the basic container configuration with attributes for the container’s class and plug-in interface definitions. It also shows the plug-in components added to the container as child element “pluginComponent”.

To deploy an individual component to the container, it’s first required to implement the plug-in interface being exposed by the container. In the present case its mx.core.IUIComponent, so any Flex UI component can be plugged into the present container. Let’s consider the case of View3 and see how it has plugged into the container, initialized and hooked on to the View1 for graphing support during runtime, without changing any line of code or recompiling. The basic code listing for View3 is shown below.

<mx:Canvas>
<mx:Script>
<![CDATA[
public function initStatData(series:ArrayCollection,length:int):void
{//logic to come up with stats data from passed in ones
}
public function raiseGraphEvent():void{
  //raise the GRAPH EVT here
  dispatchEvent(new GrapphEvent("draw",dataProvider));
}
]]>
</mx:Script>
<mx:DataGrid >
  <mx:dataProvider>
    <mx:ArrayCollection id="dataProvider" />
  </mx:dataProvider>
  <mx:columns>
  <mx:DataGridColumn headerText="Sum" dataField="col1"/>
    …..
  </mx:columns>
</mx:DataGrid>
<mx:Label text="Stats for:Object"/>
<mx:Button label="GraphIt" click="raiseGraphEvent()"/>
</mx:Canvas>
 
The component shown above is pretty simple. It shows the basic mathematical operations on each row of the data series being represented by object-1. The function initStatData(..) is responsible for initializing the component, whereas the raiseGraphEvent() function raises an event having the new mathematical data series as the new data to draw a graph.

 <pluginComponent id="333345678" name="View3">
    <property name="label">
        <value><![CDATA[Stats View]]></value>
    </property>
    <moduleURL>/an/external/module/url-view3</moduleURL>
    <initParam type="funcHookup" bindToContainerProperty="editingObject">
        <selfFunction name="initStatsData">
            <arg name="param1">
               <objectRef srcObject="editingObject">
                    <evaluate expr="dataSeries"/>
               </objectRef>
            </arg>
            <arg name="param2">
               <objectRef srcObject="editingObject">
                <evaluate expr="dataSeries.processLength"/>
               </objectRef>
            </arg>                           
        </selfFunction>
    </initParam>               
</pluginComponent>

The listing above shows the configuration for the View3 plug-in component. The moduleURL is the location of the external module that contains the component plug-in. The component is initialized using the function hookup, calling the function “initStatData” with correct parameters being evaluated from the container’s editing object. As this component just raises an event of type GraphEvent and doesn't listen to any event by itself, there is no msgMap element required in the configuration. But this event will be tied in the View1 msgMap so that when this event is raised as a result of the “GraphIt” button click, the View1 can be refreshed with the graph drawing the mathematical result series. Let’s see the msgMap configuration of View1 to see how is that accomplished.

The msgMap configuration of View1 shows that it’s mapping View3 (referenced using the pluginCompid) GraphEvent with id “draw” to map to a handler for an event called “SomeEvent”.

<msgMap id="123456789" handler="event">
<srcExtentionPoint>
        <srcMsg id="draw" pluginCompid="333345678" type="somepkg::GraphEvent"/>
    </srcExtentionPoint>
    <destHandler>
        <destMsg id="graphIt" type="some.pkg::SomeEvent">
            <object clazz="some.pkg::SomeEvent">
                <property name="any">
                    <objectRef srcObject="srcEvent">
                        <evaluate expr="an.exp.to.get.req.data"/>
                    </objectRef>
                </property>
            </object>
        </destMsg>
    </destHandler>
</msgMap>

As in View3 the event raised was a different type ”GraphEvent”; it is needed to map that event to “SomeEvent” before propagating so that the handler function can handle it accordingly. It’s also possible to map the View3 GraphEvent to directly map to a handler in the View1 handler function; this can be achieved via the following msgMap configuration setting of View1.

 <msgMap id="123456789" handler="function">
<srcExtentionPoint>
        <srcMsg id="draw" pluginCompid="333345678" type="somepkg::GraphEvent"/>
    </srcExtentionPoint>
    <destHandler>
        <destHandlerFunc name="graphIthandlerFunc">
            <arg name="param1">
                <object clazz="some.pkg::SomeEvent">
                    <property name="any">
                       <objectRef srcObject="srcEvent">
                        <evaluate expr="an.exp.to.get.req.data"/>
                       </objectRef>
                    </property>
                </object>                       
            </arg>                   
        </destHandlerFunc>
    </destHandler>
</msgMap>

To come up with the msgMap setting, it’s required to go through the API documentation of both the components (View1 and View3). The configuration setting it just an easy way to integrate the functionality exposed by both components to come up with new features. The above example just shows the flexibility of the system when the Plug-in Integrator Pattern is used and the configuration is loaded externally and can be built and maintained with ease.

The concept of “initParam” to initialize a component based on a container variable to execute any component function to initialize state provides an efficient and easy way to glue components as plug-ins to the container. Also the msgMap to map any message or function callback from a source component to a message or function handler in the destination component provides the ultimate flexibility and integration points to build enterprise-ready products just by assembling already released and tested components at runtime.

This article is just an overview of the concepts being used in the Plug-in Integrator Pattern. The implementation of the pattern is already being done in Flex but needs some dedicated papers in that subject to explain.

Conclusion
The Plug-in Integrator Pattern discussed here is good for big projects being executed by enterprises where there are several groups working on separate projects of their own, but it becomes a breeze to integrate components from these already-released and tested projects to build new applications. It also provides a new dimension to Flex programming where the components being written once can be integrated in different projects without any change, thus promoting the “write once, deploy anywhere” concept. This pattern can readily be used in other platforms and programming languages to build flexible robust systems in no time. It also differs from the methodology used in already successful plug-in projects such as Eclipse and Firefox where the plug-ins are build on compile-time dependencies; this approach provides a way to build a plug-in based application with runtime aggregation.