Although component models for creating widgets typically support portability across container implementations, sometimes widgets lose their ability to be portable for various reasons. This topic provides tips for making sure that widgets, including both iWidgets and OpenSocial gadgets, remain portable across container implementations.
Confirm available resources
Confirm that the following resources are available:
Extended container services
Specifications do not always guarantee that extended container services will be available. Examples of extended container services include Apache Shindig's pubsub support and some of the advanced services included with IBM Mashup Center, such as multipart encoding when fetching multiple resources.Libraries
Your environment often loads certain libraries, but other containers might not load those libraries. The most common example of such a library within IBM is the Dojo toolkit. Utilities
A common example is the set of utilities that an IBM Connections page loads. In order for widgets to be portable outside of the Connections environment, consider the following best practices. First, you can configure the widgets not to depend on the utilities. For example, if the utilities are not available, your widget can fall back to another option so that users do not encounter errors when your widget runs. Second, if utilities are required for your widget, you can declare a dependency so that other environments can load the required utilities.Cascading style sheets
Widgets that depend on CSS rules to dictate how the widget displays and interacts should declare a dependency on loading those rules. Without declaring a dependency, the widget is not portable.
CSS rules cascade throughout the browser environment, including iFrames. Therefore, rules that apply to a particular section of a widget's content should be very specific so that they do not interfere with how the content of other widgets display on the page. See the following suggestions for using CSS rules:
- Use CSS classes that are effectively namespaced to the widget, for example by incorporating the name of the widget into the class name.
- Use a root element, such as a div element, to wrap the entire contents of the widget and place a very specific class name on this element. All widget-specific rules then match this element/class within their overall selector to target only elements within the content of the widget.
Identify the loading server
Most individual products load their pages and widgets from the same server, but this loading behavior changes in environments where multiple products are integrated. In order to be portable in integrated environments, widgets must refer back to their host using methods provided by their component model, for example iContext.io.rewriteURI()
for iWidgets and gadgets.io.getProxyUrl()
Preventing widget state changes
Some rendering environments, such as those that render widgets as portlets on a portal page, reset the state of the widget with each user interaction unless the concept of navigationalState
is used. Portable rendering environments require support for navigationalState
to ensure that the current state of the widget is not reset. One way to support navigationalState
is to declare an optional dependency and test for its availability at run time.
Test your widget or gadget
Use the widget test page to test for portability.
Parent topic: Best practices for developing widgets