Portal Component Modes 

Purpose

Portal component modes enable a component to render a different user interface (UI). Modes abstract a context in which a component can react and display an appropriate UI. Each component must offer support for the mode. A mode must represent a situation that is often encountered by most of the portal components.

For this reason, the PRT handles the following predefined modes:

Mode	System Delegate	Description
/runtime/prt.modes/edit	StandardEditDialog	Edit and save the profile of a component
/runtime/prt.modes/about	SystemModes	Display a short text explaining the purpose of the component
/runtime/prt.modes/help	SystemModes	Display the help text of the component
/runtime/prt.modes/preview	SystemModes	Do a preview of the component
/runtime/prt.modes/config	SystemModes	Display the UI of the configuration framework starting from the root plug in of the component
/runtime/prt.modes/test	SystemModes	Start the component in a test mode. All the methods signed starting with test and signed with a TestResponse will be invoked in that test mode
/runtime/prt.modes/error	ErrorComponent	Used by the runtime to display the error returned by a component
/runtime/prt.modes/badUserAgent	SystemModes	Runtime internal usage
/runtime/prt.modes/_release	ReleaseComponent	Runtime internal usage

Implementation Considerations

The default way to render a component in a specific mode is to specify it through the URL used to access the component. The portal runtime API offers similar mechanisms:

• getComponentContext(NodeMode) on the IPortalComponentRequest
• setNodeMode(NodeMode) on the INode interface
• setNodeMode(NodeMode) on the IComponentURI interface using the CreateComponentURI() method

When deriving from AbstractPortalComponent, the behavior to handle the mode named XXX is to invoke the doXxx(IPortalComponentRequest, IPortalComponentResponse) on the portal component instance.

Portal component implements their own behavior by overloading the doXxx() method as follow:

public void doHelp(    IPortalComponentRequest request,    IPortalComponentResponse response) {    response.write("<BR> We are in help mode"); }

The delegation occurs when a portal component decides to forward its rendering to another component. This mechanism makes itpossible for specialized components to be developed. This is done in the configuration of the component in the portalapp.xml file:

<component name="mycomp">    <component-config>      <property         name="ClassName"         value="com.sapportals.portal.prt.component.MyComp"/>        <property name="mode" value="edit">        <property name="delegate"          value="DelegateComponent.default"/>      </property>    </component-config> </component>

When the delegation for the XXX mode takes place, the doXxx() method is called on the delegate component. In the above example, the PRT invokes the doEdit() method on the component called DelegateComponent.default. The subsequent request events are also sent to the delegate component until the mode is set to default.

Features

The delegation mechanism can be defined as a default way of handling a mode. To do so, a component needs to declare itself as the delegate for a specific mode by binding this mode in a specific folder called /runtime/prt.modes of the portal registry. In which case, invoking this bound mode on any component will result in invoking the mode handling method on the delegate.

The setup of such a component is also done in the portal application configuration as shown in the following example:

<application>   <registry>     <entry path="/runtime/prt.modes/admin"        name="adminDelegate"        type="component”        rebind="false"/>   </registry>     ... </application>

 

See also:

 

·        Rendering a Portal Component in Test Mode

·        Help Mode Implementation