® 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.
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.
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
Consider the following XDIME markup as applied to the previous layout:
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
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.
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.
Parent topic: Developing mobile portlets
Requirements and limitations for portlets that support XDIME markup
Properties used to configure Mobile Portal Accelerator extensions
- 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.
Policy naming conventions
Policy naming conventions are suggested for use with IBM
Mobile Portal Accelerator.
There are certain guidelines that you should follow regarding portlet-specific policies.
Global policy projects
There are global policy projects that contain policies, which can be used by multiple portlets and the XDIME aggregator.
Referencing policies in XDIME markup
There are certain guidelines that should be followed when referencing different types of policies in XDIME markup.
Using remote policies
The Remote Policy Server function enables Multi-Channel Server (MCS) to fetch policies from a remote server instead of from the local MCS database. In this way, Mobile Portal Accelerator can be integrated with a content management server. The content management server is then responsible for authoring, approving, publishing, and withdrawing the policies.