Enable a collaborative experience for HTML forms

Use the WebSphere Communications Enabled Applications Feature Pack to create collaborative and dynamic HTML forms

With the Communications Enabled Applications (CEA) Feature Pack for the WebSphere® Application Server you can deliver a more collaborative web experience to your users. Integrate click-to-call functions directly on your web pages, and allow your customers to jointly browse and navigate your site. In this article, learn to create two-way HTML forms where your users can collaborate to complete and submit their information. Explore how to drastically improve user satisfaction and the accuracy of data they send your way.

Share:

Dustin Amrhein, Technical Evangelist, IBM

Author photoDustin Amrhein joined IBM as a member of the development team for the WebSphere Application Server. While in that position, Dustin worked primarily on web services infrastructure and web services programming models. In addition, Dustin worked on the development of a RESTful services framework for Java runtimes. In his current role Dustin is a WebSphere Client Technical Professional.


developerWorks Professional author
        level

Andrew Ivory, Software Engineer, Master Inventor, IBM

Photo of Andy IvoryAndy Ivory is an IBM advisory software engineer and architect for the Communications Enabled Applications Feature Pack. He received a Bachelor of Science degree in computer engineering from Pennsylvania State University in December 2002 and joined IBM in January 2003.



20 July 2010

Also available in Chinese Japanese

Introduction

Join the Web development group on My developerWorks

Discuss topics and share resources with other developers about Web development in the My developerWorks Web development group.

Not a member of My developerWorks? Join now!

If you're using the web to interact with customers, you're likely looking for ways to increase the satisfaction of your online users. Some common ways to increase user satisfaction are: increasing page responsiveness, producing intuitive and expressive interfaces, and creating a cohesive site layout. These are important to user satisfaction, but there are other things, such as communication and collaboration, that are worth considering. You can increase user satisfaction with your web site by enabling a more collaborative experience. Collaboration capabilities will let your users do such things as:

  • Co-browse your site with other users
  • Call a customer service representative with the click of a button embedded in a Web page
  • Work directly with a customer service representative to ensure the accuracy and completeness of Web forms before submission

This article assumes a general knowledge of the widgets in the WebSphere CEA Feature Pack. See "Extending widgets in the WebSphere Application Server Feature Pack for CEA" for more information.

You can provide this type of collaboration capability using the WebSphere Application Server Communications Enabled Feature Pack. The feature pack includes Dojo widgets you can use to embed click-to-call, co-browsing, and two-way form capability. The use cases for these functions are nearly unlimited.

In this article, explore a scenario that implements three widgets that enable a customer service rep to help a user who is trying to complete and submit an online form.


The scenario

Assume you're in charge of the web site for the fictional Acme Insurance Company. Acme wants to leverage the WebSphere Application Server CEA Feature Pack to quickly and effectively connect customer service reps with customers who are having problems filling out a new claim form.

If you want to make your site more collaborative, but don't currently have WebSphere Application Server, try the free trial.

This article guides you through the steps to create the solution using the WebSphere CEA Feature Pack. You will add the following capabilities to Acme's online claim creation process:

  • Click a button on the new claim form to call a customer service rep.
  • Click a button to start a session in which both the customer and customer service rep can view and interact with the claim form data.
  • Automatically copy data from the claim form a customer started filling out to the one being co-browsed by the customer and customer service rep.
  • Control what data can be seen and acted on when collaborating on a two-way form.

The next section looks at the initial claim creation form, and explains how to embed click-to-call capabilities directly on that form.


Adding click-to-call capability

For this scenario you will work from an existing form, claimform.html, which your customers use to submit new claims online.

Figure 1. claimform.html page
A form asking for info such as name, policy number, and accident info.

At this point, the form is very basic. Customers log in, complete the required claim information, and submit it to Acme for processing by clicking Submit Claim.

Suppose one of your customers has a question while filling out the claim form. Perhaps they forgot their policy number, or they want to know exactly what to include in the claim amount. Right now, they'd have to stop working online, look up the number to call for assistance, and then place the call. The customer has to spend time on those tasks, and might even have to start the claim creation process all over again. This could lead to customer dissatisfaction and ultimately be a detriment to customer retention. It would be easier, and save time, if the customer could place a call to a customer service rep without leaving the claim creation form.

This scenario is perfect for the WebSphere CEA ClickToCall widget. You can embed the widget directly on the claimform.html page, thus allowing users to place a call to your customer service reps without leaving the page or stopping the claim creation process.

You need to make two small modifications to the HTML code. First, add the necessary import statements to import the JavaScript and CSS files provided by the WebSphere CEA Feature Pack for the ClickToCall widget, as shown in Listing 1.

Listing 1. Imports for the claimform.html page
<script type="text/javascript" src="ceadojo/dojo/dojo.js"
  djconfig="parseOnLoad: true, isDebug: false">
</script>
                
<style type="text/css">
      @import "ceadojo/dijit/themes/tundra/tundra.css";
      @import "ceadojo/dojo/resources/dojo.css";
      @import "ceadojo/cea/widget/ClickToCall/ClickToCall.css";
</style>

<script>
   ceadojo.require("dijit.form.TextBox");
   ceadojo.require("dijit.form.SimpleTextarea");

</script>

After the necessary CSS and JavaScript files are included, add the ClickToCall widget by adding another row in the form table with the HTML code in Listing 2.

Listing 2. HTML declaration for the ClickToCall widget
<tr>
   <td>
      <div ceadojoType="cea.widget.ClickToCall"      
           widgetNumber="sip:CSR@localhost">
      </div>
   </td>
</tr>

The example in Listing 2 declares the ClickToCall widget in the div element, and declares the destination Session Initiation Protocol (SIP) URI in the widgetNumber attribute as CSR@localhost. Adding the HTML and JavaScript code in Listings 1 and 2 updates the claimform.html page, as shown in Figure 2.

Figure 2. Updated claimform.html page
Same form as Fig. 1 with an added Call me button.

Now a user can initiate contact with a customer service rep by entering their number and clicking Call Me. The phone indicated by the SIP URI in the widgetNumber attribute of the ClickToCall widget will be notified and will place a call to the number entered by the user.


Adding co-browsing and a two-way form

Consider the situation where a user started filling out a claim form but could not locate their policy number. They could call a customer service rep using the new ClickToCall widget. After verifying the customer's identity, the rep could look up and relay the policy number to the user. It's simpler than it would have been before the ClickToCall widget, but it's still not ideal. The customer service rep has to read a long policy number over the phone, and the user has to listen and type that number into the form field. During this information relay there's a margin for error; the wrong data could end up in the policy number field.

It would be a much better experience if the user and customer service rep could jointly browse and interact with the new claim creation form. Then, the customer service rep could provide assistance directly in the HTML form and the information exchange does not take place over the phone. You can achieve this very thing with a few additional widgets.

The first step is to enable the ClickToCall widget, which you already embedded on the claimform.html page, to support co-browsing capabilities. You also need to update the CSS imports on the claimform.html page, as shown in Listing 3.

Listing 3. Updated imports for the claimform.html page
<style type="text/css">
    @import "ceadojo/dijit/themes/tundra/tundra.css";
    @import "ceadojo/dojo/resources/dojo.css";
    @import "ceadojo/cea/widget/ClickToCall/ClickToCall.css";
	@import "ceadojo/cea/widget/Cobrowse/Cobrowse.css";
	@import "ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
</style>

<script>
   ceadojo.require("dijit.form.TextBox");
   ceadojo.require("dijit.form.SimpleTextarea");
</script>

At this point, you add three new attributes to the existing ClickToCall widget declaration, as shown in Listing 4.

Listing 4. Updated ClickToCall widget
<tr>
   <td>
      <div ceadojoType="cea.widget.ClickToCall"      
           widgetNumber="sip:CSR@localhost" 
           enableCollaboration="true"  
           canControlCollaboration="true"           
           defaultCollaborationUri="collabform.html">
      </div>
   </td>
</tr>

The enableCollaboration attribute set to true indicates to include co-browsing capabilities as part of the ClickToCall widget. The canControlCollaboration attribute set to true means that the customer can control the co-browsing capabilities if the customer service rep chooses to give them control. Finally, the defaultCollaborationUri attribute value indicates the initial page that will be loaded in the co-browsing session.

Before discussing the collabform.html page, there's something important to know about using the ClickToCall widget in conjunction with co-browsing capabilities. To start a co-browsing session with the customer, a page accessible by the customer service rep must have a way to listen for incoming calls and initiate such sessions. The CEA Feature Pack's CallNotification widget provides this capability.

A separate page, csrhome.html, with the CallNotification widget listens for calls from the customer and provides the capability to co-browse the claim creation form with the customer. Similar to the widgets used previously, Listing 5 shows how to import the necessary CSS files.

Listing 5. Imports for the CallNotification widget
<script type="text/javascript" src="ceadojo/dojo/dojo.js"
	djconfig="parseOnLoad: true, isDebug: false">
</script>

<style type="text/css">
      @import "ceadojo/dijit/themes/tundra/tundra.css";
      @import "ceadojo/cea/widget/CallNotification/CallNotification.css";
      @import "ceadojo/cea/widget/Cobrowse/Cobrowse.css";
      @import "ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
</style>

With the imports in place, you declare a CallNotification widget within a table on the page, as shown in Listing 6.

Listing 6. CallNotification widget declaration
<table cellspacing="25" cellpadding="25" class="formContent">
   <tr><th style="font-weight:bold;font-size:large">Acme Insurance Claim 
        Hotline
       </th>
   </tr>
   <tr>
      <td><div ceadojoType="cea.widget.CallNotification" 
               widgetNumber="sip:CSR@localhost"   
               enableCollaboration="true" 
               canControlCollaboration="true" 
               defaultCollaborationUri="collabform.html"></div>
      </td>
   </tr>
</table>

The CallNotification widget attributes are identical to those of the ClickToCall widget on the claimform.html page. In this case, the widgetNumber attribute value indicates the number at which the widget will listen for calls. Incoming calls to the sip:CSR@localhost phone, which occur when a customer uses the ClickToCall widget, result in the notification of this CallNotification widget. Again, the necessary collaboration attributes are defined, and the defaultCollaborationUri is set to the same value as is set in the ClickToCall widget on the claimform.html page. The new csrhome.html page should now display the widget, as shown in Figure 3.

Figure 3. CallNotification widget on the claimform.html page
Section showing icons for a phone, two people, and disconnect.

Before starting the CallNotification widget so that it's actively listening for incoming calls, you need to create the collabform.html page that both the ClickToCall and CallNotification widgets reference in their defaultCollaborationUri attributes.

The new collabform.html page will contain a form that is a field-by-field copy of the original form on the original claimform.html page. On the new page, instead of using a regular HTML form you'll use the TwoWayForm widget. Again, the first step is to import the necessary CSS and JavaScript files for the page.

Listing 7. Imports for the collabform.html page
<script type="text/javascript" src="ceadojo/dojo/dojo.js"
	djconfig="parseOnLoad: true, isDebug: false"></script>

<style type="text/css">
      @import "ceadojo/dijit/themes/tundra/tundra.css";
      @import "ceadojo/dojo/resources/dojo.css";
      @import "ceadojo/cea/widget/TwoWayForm/TwoWayForm.css";
</style>

<script>
   ceadojo.require("dijit.form.TextBox");
   ceadojo.require("dijit.form.SimpleTextarea");
</script>

Copy the HTML in the body section of the claimform.html page into the body section of the collabform.html page. Alter the form element and specify a ceadojoType attribute with a value of cea.widget.TwoWayForm, as shown in Listing 8.

Listing 8. Declaring the TwoWayForm widget
<form id="claimReqForm" ceadojoType="cea.widget.TwoWayForm"  
      style="background-color:rgb(223,223,223)">

Other than that small change, the only change to make to the copied HTML is to remove the ClickToCall widget. For this example, though, it won't be necessary because we'll only use this particular page in the context of a co-browsing session. If you were to view the collabform.html page, you'd see exactly the same output as shown in Figure 1.

You're almost ready to test the initial calling and co-browsing flow for the claim request form. Before doing so, you need to configure the necessary telephony components to conduct the application testing. For this example, you can get instructions from the Info Center for the CEA Feature Pack. The example in this article registers one phone at sip:CSR@localhost and the other at sip:Customer@localhost.


Testing co-browsing capability

After the telephony infrastructure is in place, you load the csrhome.html page and activate the CallNotification widget by clicking the Start call notification icon. As shown in Figure 4, the status changes to indicate the CallNotification widget is available and waiting for incoming calls.

Figure 4. Starting the CallNotification widget
Window showing phone icons with Available in the box below the phone icon.

The example opens a separate browser. (The CEA Feature Pack uses cookies to store session state, so it must be a separate browser—not a separate window in the same browser.) The next step is to open the claimform.html page. Assume the user starts the claim creation process by entering a name, but then decides they need help. They enter sip:Customer@localhost as the customer's number and click Call Me. This initiates a call to the sip:CSR@localhost phone, which, when answered, initiates a call back to the sip:Customer@localhost phone. When the phones connect you see an update to the ClickToCall widget's status on the claimform.html page, as shown in Figure 5.

Figure 5. Connected status for ClickToCall widget
Screen showing connection to sip:Customer@localhost and disconnect and cobrowse icons.

Open the csrhome.html page and you'll see a similar update to the status for the CallNotifcation widget, as shown in Figure 6.

Figure 6. Connected status for CallNotification widget
Screen showing connection to sip:CSR@localhost and disconnect and cobrowse icons.

To start the co-browsing sessions, click the co-browse icon on both the ClickToCall and CallNotification widgets. In each browser, a modal window opens and the collabform.html page appears in the pane.

Figure 7. Modal window for co-browsing session
Screen with the accident info fields to be filled in.

To begin the session, the customer service rep, who opened the co-browsing session from the CallNotification widget, has control of the session. You can test the two-way form capabilities by entering a value in the Policy number field in the customer service rep's window. You should see the same value show up in the same field of the customer's co-browsing session.

Figure 8. Two-way form data transfer
Partial screen with accident fields and a policy number entered in the highlighted field.

Now that the policy number is correct, the customer can go back to entering the claim data. As shown in Figure 8, the data entered by the customer shows up highlighted in the customer service rep's window. The two users can simultaneously collaborate on the data in the form without having to grant control back and forth.


Preserving confidentiality in a two-way form

Many online forms contain confidential information, such as a social security number, a credit card number, or a home address. You might create a two-way form that contains data to which only one user in the interaction should be privy. In the example claim creation form, to maintain privacy it's probably not wise for the customer service rep to see the name of the other party in the accident. You can use two special attributes for elements in the TwoWayForm widget to ensure that only the customer can supply and read the name of the other party in the accident.

Open the collabform.html page in an HTML editor and locate the input field for the field labeled "Name of other party." You can see the original declaration in Listing 9.

Listing 9. Original declaration for name of other party input
<input type="text" ceadojoType="dijit.form.TextBox" id="otherName"   
           name="otherName"></input>

To ensure that only the customer can edit the value of this input element and the masking of the value in the customer service rep's window, use the ceaCollabWriteAccess and ceaCollabFilter attributes.

Listing 10. Controlling write and read ability
<input type="text" ceaCollabWriteAccess="reader" 
       ceaCollabFilter="default" ceadojoType="dijit.form.TextBox" 
       id="otherName" name="otherName"></input>

Setting the ceaCollabWriteAccess attribute to reader indicates only the reader in the session can edit the value of the input element. In this case, the customer is the reader. The customer service rep, who initiated the session, is the writer. The default value in the ceaCollabFilter attribute causes the masking of the input value in the window of the writer (in this case, the customer service rep). Figure 9 shows the result.

Figure 9. Masked value in the customer service rep's window
Accident form with Name of other party highlighted field showing asterisks.

The default value of the ceaCollabFilter attribute indicates that you want to use the default masking function, which, as shown in Figure 9, replaces the content of the input element with a string of * characters. If needed, you could supply your own custom masking function. To do that, you'd specify the name of a function as the value of the ceaCollabFilter attribute. This function accepts a string as an argument (the original value of the field), and returns a masked version of the value.


Transferring data to the co-browsing forms

Suppose a customer encounters a problem after they've started filling in data on the claim creation form. They then solicit help, using click-to-call and co-browsing, from a customer service rep. As it works now, form data entered by the user on the claimform.html page will not automatically transfer to the form on the collabform.html page at the start of the co-browsing session. The customer would have to re-enter information on the claim form in the co-browsing session. Obviously, this is a significant inconvenience. Luckily, you can avoid inconvenience to your users by extending the behavior of a couple of the widgets to make sure information is copied from the original claim creation form over to the two-way form in the co-browsing session.

If you aren't familiar with extending Dojo widgets in general, or WebSphere CEA widgets specifically, you might want to go to the previously mentioned tutorial. It shows how to create, package, and leverage extended WebSphere CEA widgets in your application.

To provide the function needed to copy over form data at the beginning of a claim creation co-browsing session:

  1. Create a new module.

    Create a new folder structure to hold the extended artifacts in the application.

  2. Modify the ClickToCall widget template.

    Modify the template of the ClickToCall widget to include an attribute that indicates the name of the form from which to copy elements.

  3. Modify the ClickToCall widget's JavaScript

    Modify the JavaScript of the widget to reflect its new package name and to refer to the new CollaborationDialog widget.

    Provide function to gather all the form elements, and their values, on the claimform.html page and make these available to the CollaborationDialog widget.

  4. Modify the CollaborationDialog widget's JavaScript.

    Add a function to set the value of the elements for the claim creation form on the collabform.html page in both the customer and customer service rep's co-browsing session. The values come from the elements copied and passed to the CollaborationDialog widget by the extended ClickToCall widget.

  5. Update the claimform.html page.

    Update the claimform.html page to use the newly extended widgets.

Creating a new module

First, you want to extend the ClickToCall widget to gather all of the elements and their values from the form on the claimform.html page. Create a new folder structure within the application, and copy to it the three JavaScript files you are modifying:

  • ceadojo/cea/widget/CollaborationDialog.js
  • ceadojo/cea/widget/ClickToCall.js
  • ceadojo/cea/widget/ClickToCall/ClickToCall.html

The new folder structure has a root folder of acme, and the subdirectory layout mocks that of the cea module provided by the WebSphere CEA Feature Pack. See Figure 10.

Figure 10. Extended folder structure
Screen showing directory structure of ceadojo

Modifying the ClickToCall widget template

In the interest of maximum reuse and flexibility, you want to declare the name of the source form (the form from which you will copy elements) in the HTML declaration of the ClickToCall widget. Add the sourceForm attribute to the ClickToCall widget's template and make the value of that available to the ClickToCall widget. In the ceadojo/acme/widget/ClickToCall/ClickToCall.html file you will see an element whose dojoAttachPoint is collaborationDialog. The element contains attribute definitions, such as enableCollaboration and canControlCollaboration, which are available to both the ClickToCall and CollaborationDialog widget. Add the new sourceForm attribute, as shown in Listing 11.

Listing 11. Updating the template for the ClickToCall widget
<div
    dojoAttachPoint="collaborationDialog" 
dojoType="acme.widget.CollaborationDialog" sourceForm="${sourceForm}"
canControlCollaboration="${canControlCollaboration}"
defaultCollaborationUri="${defaultCollaborationUri}"
highlightElementList="${highlightElementList}"
isHighlightableCallback="${isHighlightableCallback}"
isClickableCallback="${isClickableCallback}"
sendPageUrlRewriteCallback="${sendPageUrlRewriteCallback}">
</div>

In addition to defining the new sourceFrom attribute, notice that the code also changed the dojoType to refer to the acme.widget.CollaborationDialog widget. This will be the name of the extended CollaborationDialog widget when you're done with the modifications, so go ahead and make the update now to ensure the extended ClickToCall widget leverages the new functions. These are the only two changes you need to make to the ClickToCall widget's template. The next step is to modify the JavaScript for the widget.

Modifying the ClickToCall widget JavaScript

In the source of the ceadojo/acme/widget/ClickToCall.js you'll change the declaration statements and a require statement. Update the declarations to declare acme.widget.ClickToCall in place of cea.widget.ClickToCall, and update the require statement for the CollaborationDialog to reference acme.widget.CollaborationDialog, as shown in Listing 12.

Listing 12. Updated declaration statements for ClickToCall widget
dojo.provide("acme.widget.ClickToCall");
dojo.require("acme.widget.CollaborationDialog");
dojo.declare("acme.widget.ClickToCall", [ cea.widget.ClickToCall ],

In the dojo.declare statement, the example changes the base widget value to cea.widget.ClickToCall. You can remove many of the other require statements because you're extending from this base widget.

You need to make some changes to the variables in the ClickToCall JavaScript source. The goal is to make sure the new widget is pointing to the modified template you created in the previous step. Add a variable for the sourceForm attribute.

Listing 13. Modifying the ClickToCall widget variables
dojo.declare("acme.widget.ClickToCall", [ cea.widget.ClickToCall ],
{
   templateString : null,
   templatePath: dojo.moduleUrl("acme.widget",               
                                "ClickToCall/ClickToCall.html"),
   sourceForm: "",

To point to the new template, set the templateString value to null and declare a templatePath variable that refers to the modified HTML template file. The code also creates a sourceForm variable to hold the value of the sourceForm attribute you defined in the new template.

The final modifications to ClickToCall widget's source are to gather the elements from the specified form and make them available to the CollaborationDialog widget instance. Add a new function called getSourceFormElements to retrieve the elements from the form indicated by the sourceForm attribute, and set them on the CollaborationDialog widget instance. After that, modify the ClickToCall widget's existing cobrowse function to call this new function. The complete source for the newly extended ClickToCall widget is shown in Listing 14.

Listing 14. Source for the modified ClickToCall widget
dojo.provide("acme.widget.ClickToCall");
dojo.require("acme.widget.CollaborationDialog");
dojo.declare("acme.widget.ClickToCall", [ cea.widget.ClickToCall ],
	{
		templateString : null,
		templatePath: dojo.moduleUrl("acme.widget", 
                "ClickToCall/ClickToCall.html"),
		sourceForm: "",
		getSourceFormElements : function() {
	         var sourceFormObj = dojo.byId(this.sourceForm);
		   this.collaborationDialog.sourceFormElements = 
               sourceFormObj.elements;
	      },
		cobrowse : function() {
	         this.getSourceFormElements();
		   this.collaborationDialog.openCollaborationDialog();
		}
       }
);

The rest of the function declarations are removed because you can simply inherit them from the base cea.widget.ClickToCall widget.

Modifying the CollaborationDialog widget JavaScript

After you've completed the modifications to the ClickToCall widget, you can make the necessary changes to the JavaScript of the CollaborationDialog widget. As with the extended ClickToCall widget above, start by making changes to the declaration and variables section of the source. Modify the name of the widget you are declaring to be acme.widget.CollaborationDialog, and change the base widget list to simply contain cea.widget.CollaborationDialog.

Declare the sourceFormElements and sourceForm variables. The extended ClickToCall widget references the sourceFormElements; you'll use the sourceForm variable later. As with the CallNotification widget, the initial value of the sourceForm variable comes from the value of the sourceForm attribute when a user declares the ClickToCall widget using HTML.

Listing 15. Declarations for extended CollaborationDialog widget
dojo.provide("acme.widget.CollaborationDialog");
dojo.declare("acme.widget.CollaborationDialog",           
[cea.widget.CollaborationDialog ],
{
sourceFormElements : null,
sourceForm : “”,

Add a new method called setTargetFormElements that contains the logic to copy the values from the original form on the claimform.html page to the two-way form on the collabform.html.

Listing 16. Transferring values to the target form
setTargetFormElements : function() {
   dojo.withDoc(this.collaborationDialogContentPane.domNode.contentWindow.document, 
      function() {
         if(this.sourceFormElements != null) {
            var matchedCount = 0;
	        for(ct=0; ct < this.sourceFormElements.length; ct++) {
		var sourceElement = this.sourceFormElements[ct];
		var currElement = dojo.byId(sourceElement.id);
		if(currElement != null) {
		    if(currElement.options && sourceElement.options) {
			for(optCt=0; optCt < sourceElement.options.length; optCt++) {
			    if(sourceElement.options[optCt].selected) {
			        currElement.options[optCt].selected = true;
				window.top._ceaTwoWayForm._widgetHandlers
				[currElement.id]._changedByUser = true;
				window.top._ceaTwoWayForm._widgetHandlers
				[currElement.id]._handleOnChange(currElement.value);
				matchedCount++;
				break;
			    }
			}
		     }
		     else if(sourceElement.value != ""){
		        console.log(sourceElement);
			currElement.value = sourceElement.value;
			window.top._ceaTwoWayForm._widgetHandlers[currElement.id].
			_changedByUser = true;
			window.top._ceaTwoWayForm._widgetHandlers[currElement.id].
			_handleOnChange(currElement.value);
										
		     }
		 }
	  }
	}
    }, this);
},

The setTargetFormElements makes use of the dojo.withDoc function to be able to interact with the DOM contained in the window of the co-browsing session. Hence, the function in the example is able to interact with elements on the collabform.html page. The setTargetFormElements function loops over all the elements in the sourceFormElements array and, for each one, attempts to find an element on the current document (the collabform.html page) with a matching ID. After it finds the appropriate value, the code triggers a change event using the widget handlers for the TwoWayForm widget instance.

All you need to do now is make sure to call the new function before the form appears in the customer's co-browsing session. You can insert a call in the existing openCollaborationDialog function, as shown in Listing 17.

Listing 17. Updated openCollaborationDialog method
openCollaborationDialog : function() {
   this.setTargetFormElements();
   this.inherited(arguments);
}

The other methods are removed, because the extended widget inherits them from the cea.widget.CollaborationDialog base widget.

Make updates to the claimform.html page to include the new ClickToCall widget and, by association, the new CollaborationDialog widget. This is achieved by simply updating the dojo require statements and CSS imports, as shown in Listing 18.

Listing 18. Updated imports for claimform.html
 <style type="text/css">
@import "ceadojo/dijit/themes/tundra/tundra.css";
@import "ceadojo/dojo/resources/dojo.css";
@import "ceadojo/cea/widget/ClickToCall/ClickToCall.css";
@import "ceadojo/cea/widget/Cobrowse/Cobrowse.css";
@import "ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
</style>

<script>
ceadojo.registerModulePath("acme","../acme");
ceadojo.require("dijit.form.TextBox");
ceadojo.require("dijit.form.SimpleTextarea");
ceadojo.require("dijit.form.ComboBox");
ceadojo.require("acme.widget.ClickToCall");
</script>

After you package these changes and redeploy the application, you can verify the new function. Starting on the claimform.html page, enter a claimant name, accident date and time, police report number, and a few more bits of information, as shown in Figure 11.

Figure 11. Customer claim creation form
Screen showing accident information with completed fields.

Assume that you need help from a customer service rep at this point, so you click the Call button. After you're connected, the rep decides it would be best to enter a co-browsing session to solve the problem. When the co-browsing window is opened, you see that the information you entered on the claimform.html page automatically transfers to the collabform.html page in the co-browsing session.

Figure 12. Populated claim creation form in co-browsing session
Screen showing accident information with completed fields.

Because the code in Listing 16 manually fires the onChange event, the information from the initial form transfers to both the customer and customer service rep's co-browsing window with no additional modifications.


Summary

The Dojo widgets of the WebSphere CEA Feature Pack provide the capability to significantly enhance the communication and collaboration capabilities of your online applications. Right out of the box, you can embed these widgets in your existing and new applications to enable click-to-call, co-browsing, and two-way form interactions. If the out-of-the-box functions don't quite provide what you need, you can use Dojo basics for the customization functions your application requires. Check out the WebSphere CEA Feature Pack if you think your Web applications can benefit from enhanced communication and collaboration.


Download

DescriptionNameSize
Sample code for this articlesamplecode.zip24 KB

Resources

Learn

Get products and technologies

  • Download the WebSphere Application Server V7 Feature Pack for CEA.
  • Innovate your next open source development project with IBM trial software, available for download or on DVD.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Web development on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Web development, WebSphere
ArticleID=501244
ArticleTitle=Enable a collaborative experience for HTML forms
publish-date=07202010