Extending the Cobrowse widget

I'm still looking at and experimenting with the WebSphere CEA Feature Pack widgets. In my last two posts I took a look at scenarios that lead to extending the WebSphere CEA ClickToCall widget. In my latest project, I took a look at the Cobrowse and CollaborationDialog widgets.

It's clear that there are many scenarios where users would want to employ and maybe even extend these two widgets. For instance, check out the demonstration below for one such scenario.



There are a few things to note about the sample as far as the extensions go. First of all, I did a very simple extension to the ClickToCall widget along the same lines of my previous posts, so I won't go into much detail about that particular piece.

Other than the ClickToCall extension, I extended both the Cobrowse (cea.widget.Cobrowse) and CollaborationDialog (cea.widget.CollaborationDialog) widgets to provide the function you see in the sample. With the Cobrowse widget, I added functionality such that when the customer service representative creates the collaboration link, a resource representing that link and the customer it is intended for is created on the backend. That was easy to do by overriding the Cobrowse widget's _convertToWaitingState method and providing custom function to create the necessary resource.

When a customer logs into the Insurance Company's home page, JavaScript running on the page checks the backend for any resources that would indicate a customer service representative has invited that particular customer to a collaboration session. In the sample video, this is shown when the customers logs into the Insurance Company's site.

Next, I needed to extend the CollaborationDialog widget in a couple of ways. First, I added the Send Policy Data button to the dialog's toolbar. All that was required to add the button was a small update to the widget's JavaScript. No HTML or CSS changes were necessary.

After that, I added a function that allows the customer service representative to send the retrieved policy information from his window to the customer's window. This was done by piggy-backing on the ability of the CollaborationDialog widget to send data back and forth between the collaboration participants. There was a nifty Dojo function that came into play when implementing this capability. Once the data was received by the CollaborationDialog instance on the customer side, the contents of the content pane in the CollaborationDialog needed to be updated. This was done by using dojo.withDoc as seen below:

dojo.withDoc(iframeDoc,
function() {
          var data = this.receivedPolicyData;
          dojo.style(dojo.byId("policyTable"), "display", "block");
          dojo.byId("policyNumText").innerHTML = data['policyNum'];
          dojo.byId("policyHolderText").innerHTML = data['policyHolder'];
          dojo.byId("policyTypeText").innerHTML = data['policyType'];
          dojo.byId("policyAmountText").innerHTML = data['policyAmount'];
          dojo.byId("policyPremiumText").innerHTML = data['policyPremium'];
          dojo.byId("policyPaymentScheduleText").innerHTML =                                                   
                     data['policyPaymentSchedule'];
          dojo.byId("policyDeductibleText").innerHTML =
                     data['policyDeductible'];
          },
          this
);

The dojo.withDoc method allowed me to update the DOM of the source HTML page for the content pane, and in this case it was extremely helpful.

The required changes to implement these widget extensions were fairly minimal considering the capabilities that were added. In fact, the backend data services for the various resources used by this sample took most of my time. If you are interested in seeing more of the code for the sample above just drop a reply to this blog post. I'd be happy to share more of the extension implementation.