Status

Initial planning phase

Introduction

We will be dealing with a mobile site as a separate site from the main portal. As such we need to be careful in how we redirect users between the various portals, especially with respect to following various links.

Since the mobile site is separate and may have completely different content and node layouts, we need a way to provide the best experience to the user when they deal with urls and nodes.

Use Cases

• UserD on a desktop is emailed a link to the portal from UserM using a mobile phone, the link is to the mobile site. UserD will expect to be shown the corresponding page on the desktop site, and not just redirected to the desktops portal's home page
• UserD emails UserM a link to a page on the desktop site, but there doesn't exist a corresponding page on the mobile site.
• PortalD (desktop) and PortalM (mobile) are separate sites, and the page/node names are completely different between the two. But there are corresponding pages between the two.
• PortalD and PortalM have similar node layouts, but the content between the two may be different. For example /portalD/news/latest/stocks doesn't exist on portalM, but /portalM/news/latest does

Specification

URL mapping between the sites is something that will be unique between the various sites and is something that an admin will have to configure. The various configuration options they will need to set are:

• explicit url mappings between the two sites. This will include a list of node paths to match against
• node mappings based on the name of the nodes. If the nodes are named the same between servers, then just map based on this. Node name matching can be enabled or disabled.
• what should happen if we have a node without a corresponding redirect node.
  • don't perform the redirect, take them to the orginally requested url
  • redirect them anyways, let the redirect site take care of what node should be displayed

• try and redirect instead to commonly named ancestor nodes
• redirect to the root of the redirect site.

Redirection Node Detection

We may wish to make sure that a node exists on the redirect site before performing the redirect. Using the navigation service we can determine if the redirect node already exists or not and use this information to make more intelligent redirects.

Redirection Mapping

The admin needs to be able to explicitly specify the mapping between the two separate sites. The admin should be able to specify either exact node names, or use regular expressions to do the matching.

If no explicit mapping is specified in the configuration for the node but a node exists with the same name on the redirect portal, we should be able to redirect based solely on the node names matching.

Common Ancestor Redirection

Common ancestor redirection looks at the node names of the ancestor nodes and tries to match it based on them. Performs a redirect if common ancestors with the same name are found or it results in redirect to the main page of the redirect site.

For example: origin node portalO/foo/bar/x/y/z where there is no redirect node portalR/foo/bar/x/y/z

• if portalR/foo/bar/x/y exists, then redirect to portalR/foo/bar/x/y
• otherwise, if portalR/foo/bar/x exists, then redirect to portalR/foo/bar/x
• ....
• if not ancestor match, then redirect to portalR

Workflow

TODO: update the chart, the ask the user what they want option has been removed and will be handled by the manual redirect portlets instead.

Configuration

XML Configuration File

See Gatein Mobile Detection And Redirection Mapping: XML Configuration for the device redirection XML configuration options. See the "Node Mappings" section for specifics on how to handle redirection between nodes on the origin and redirect sites.

UI Administration

See Gatein Mobile Detection And Redirection: Administration UI for the device redirection Admin UI components.