Using Multi-Channel Server policies

A number of different Multi-Channel Server (MCS) policy types can be used by portlets that support XDIME markup.

IBM® Mobile Portal Accelerator requires several types of MCS policies to be defined before XDIME markup can be rendered correctly. Policies are created using the policy editors provided with the Mobile Portal Toolkit. The policies are placed within a project in one of the toolkit's workspaces. Portlets can either reference policies in the portlet's project, or use global policies that are defined in a MCS project.

Device policies

At the core of MCS is a repository that contains information about thousands of devices, storing hundreds of attributes per device. Each collection of attributes associated with a class of devices or a specific device is called a device policy.

Device policies can be viewed by using the Mobile Portal Toolkit Device Repository Browser.

Layout policies

Because the screen size of two devices may be drastically different, it is difficult to code a page that is suitable to present on both devices. To solve this problem MCS uses a layout policy to deal with screen size differences. A layout basically describes areas on the screen and assigns each one a unique name (unique within the layout). The markup then assigns different fragments of the content to different panes in the Layout. Note the three panes in the following layout example:

Figure 1. Screen layout example Master screen Layout including four regions.

Consider the following XDIME markup as applied to the previous layout:

<canvas layoutName="Layout_A">
     <pane name="Pane1">
         WebSphere
     </pane>
     <pane name="Pane2">
         Portal
     </pane>
     <pane name="Pane3>"
         Server
     </pane>
     </canvas>

Notice that the markup rendered on devices that fall into the “Master” category will have the words “WebSphere”, “Portal”, and “Server”, all in a single column.

In the following layout, notice that the layout has the same name (Layout A), but is targeted for a different class of device (mobile). It is also missing Pane1 and Pane3. This is when breaking the content up into manageable sections starts to work for you. In this case the Layout author decided that the content in panes 1 and 3 was irrelevant for mobile device users and discarded the panes altogether. This approach is enabled by the fact that a named layout may be logically different for each device, or class of device, that makes a request. These two layouts are allowed to have the same name because they are assigned to different levels of the device hierarchy.

Figure 2. Screen layout example for mobile Mobile screen layout containing only two regions.

Component and Asset policies

MCS component policies bind different types of resources to devices. Examples of component policies include image, chart, audio, and text policies.

MCS asset policies describe assets (for example, images) and their attributes. Most assets are targeted at specific devices or device families.

For example, a variety of image assets may appear under a single image policy. MCS will use an algorithm to determine which image is appropriate for the requesting device. (For example, check for a device specific image first, then search for the most suitable generic image (based on size, color, format, etc.) else determine if there is a fallback image specified, or other action.) If used correctly, this provides for a very flexible approach to rendering images to multiple devices.

Theme policies

MCS also has the capability to deliver style information to a device that is appropriate for the device in use. It introduces the concept of a theme policy to handle this. A theme is very similar in concept to a CSS (more like a superset of CSS). In fact it is fairly straightforward to take an existing CSS and implement it as an XDIME theme.

Note:

MCS themes are different from WebSphere® Portal themes. WebSphere Portal themes define which versions of an aggregator's JSPs are used to provide different branding and look and feel.
Portlets should not provide their own theme policies because device limitations prevent MCS from generating style rule markup that will work for all devices. Style rules needed by portlets should be included in the theme policies used by the XDIME aggregator.