IBM connections 4.5 IWidget and OpenSocial Gadget hands-on

The historical development and new changes of iwidget/opensocial Gadget in connections

IBM Connections has a long-standing support for IWidget, which is mainly used in both the Home page (homepage) and community (Community) applications. Support for Google Gadget is relatively late, and can only be indirectly supported by other workarounds before IBM Connections 4.0 (by including a Gadget page with an iFrame in IWidget). This situation was finally improved after 4.0, and connections supported both Engine and IWidget OpenSocial by introducing the CRE (Common Render Gadget) container. However, IWidget and Gadget support in specific applications are still different, and in which the steps to develop and deploy IWidget and Gadget are different, let's see what the difference is.

IWidget's support environment

In IBM connections iWidget can be used in three applications: Home page (homepage), community (Community), personal files (profile).

Support Environment for OpenSocial Gadget

In IBM connections IWidget can be applied primarily to the homepage (homepage) and to the information flow (activity Stream) that is integrated into other applications.

Development Deployment IWidget

So what's the difference in developing deployment iWidget in IBM connections? Or what additional features does IBM connectons provide to iWidget developers to enhance functionality? Let's start by looking at the simplest features.

IWidget title and multi-instance support

Support for IWidget headers is not entirely a new feature, as the IWidget specification already contains the caption attribute for us to read and write, and this is mainly about the enhanced support provided by connections 4.5 for the IWidget title of multiple instances. We know that if you provide iWidget support to deploy multiple instances on the same page, their title defaults will be the same name, which can be confusing to users, and it's easy to tell which content each IWidget instance corresponds to. And in Connection 4.5, the solution to this problem is to provide a serial number for each iWidget that supports multiple instances, for example:

Helloworld.sequencenumber=hello World {0}

The "{0}" above corresponds to the Run-time serial number. Thus, when multiple instantiated iWidget are added to the same page, their headings will be "Hello World", "Hello World 2", "Hello World 3", and so on. Another advantage of doing this is that we can define the serial number anywhere in the title string, for example:

Helloworld.sequencenumber=hello World {0},bye!

This flexibility allows us to deal with complex situations and to be very handy when it comes to iWidget internationalization.

Figure 1. Multi-instance iWidget with serial number

So the new question is, how do we get the widget title with the serial number in the code? Since this is an extension of the title in the IWidget specification, we naturally cannot read the original method, connections 4.5 provides a new IWidget property "Computedwidgettitle", which we can read with the following code:

Icontext.getiwidgetattributes (). GetItemValue ("Computedwidgettitle")

This property stores the title after the IWidget container has been computed based on the current serial number. Defining a iWidget that supports serial numbers requires this to define its resource bundle file:

Helloworld=hello World
Helloworld.sequencenumber=hello World {0}
Helloworld.desc=descriptions for Hello World

The suffix of ". SequenceNumber" is added after the corresponding key. This way, if the current page has only one instance of this iWidget, the first title is used, and more than one instance automatically composes the title with the second string.
Register a third party resource bundle for IWidget

So, the new question is, where do these resource bundle be defined? We want to be able to automatically load these resource bundle in the widget panel of the connections community, especially for third party iWidget, so that connections can find iWidget resource to which these bundle belong It's more of a problem. In this respect, the approach proposed in connections 4.5 is to provide a centralized read for all resource bundle, whether it is a system-owned iWidget or a third-party-developed iWidget can place resource bundle in that path. Connections will read all resource bundle files under this path uniformly. The specific steps are as follows:

Place the required resource bundle file into the <connections_customization_path>/strings/directory. <CONNECTIONS_CUSTOMIZATION_PATH> is a connections variable defined in WebSphere, and the default path is/opt/ibm/connections/data/on the Linux platform Shared/customization.

Use Wsadmin to do the following:

./wsadmin.sh-lang jython-user <your wasadmin>-password <your password>

-port <SOAP_CONNECTOR_ADDRESS_PORT>

ExecFile ("connectionsconfig.py")

Lcconfigservice.checkoutconfig (<WORKING_DIRECTORY> <cell_name>)

The <working_directory> above is the directory where the output file is saved, and <cell_name> corresponds to the current connections cell name.

Modify the Lotusconnections-config.xml file in the previous step, adding the following definition:

<widgetbundle prefix= "Urumchi" name= "HelloWorld"/>

The "HelloWorld" here corresponds to the file name of the IWidget resource bundle. and "Urumchi" is the globally unique reference ID we gave to this resource bundle, and it's done in the next step by associating this ID with the corresponding iWidget.

After modifying the Lotusconnections-config.xml file, you also need to import it with wsadmin connections

Lcconfigservice.checkinconfig (<WORKING_DIRECTORY> <cell_name>)

After you complete the above modifications, you will need to restart Common.ear in the WebSphere Management console to allow the changes to take effect in the connections.

Register IWidget

OK, so far we have completed the resource bundle required to register a third party iWidget in connections. Let's take a look at how to register a third party IWidget for the connections community.

Use Wsadmin to do the following:

./wsadmin.sh-lang jython-user <your wasadmin>-password <your password>
-port <SOAP_CONNECTOR_ADDRESS_PORT>
ExecFile ("communitiesadmin.py")

Communitiesconfigservice.checkoutwidgetsconfig ("<working_directory>", "<cell_name>")