Working with Two-Panel Implementations

AJAX transfers, or asynchronous in-place transfers, use AJAX (asynchronous JavaScript and XML) technology to allow component-to-component transfers to occur without exiting from the fluid wrapper (fluid activity guide or master/detail component) that contains the source component from which the transfer was invoked. When AJAX transfers are enabled for the fluid wrapper, then the new content replaces the target content area within the fluid wrapper. When AJAX transfers have not been enabled (the default configuration), the new content replaces the entire browser window. AJAX transfers apply to four PeopleCode functions only: Transfer, TransferExact, ViewContentURLContent, and ViewContentURLFluid.

Image: Elements within a fluid wrapper component

The following diagram illustrates the elements that are presented within a fluid wrapper component:

• Fluid banner — With fluid activity guides, the content of the fluid banner is maintained by the activity guide. With master/detail components, the content is maintained by the individual components displayed in the target content area.

• Optional sub-banner — With fluid activity guides, the content of the sub-banner is maintained by the activity guide.

• Navigation panel — The items in the navigation panel are presented by the fluid wrapper component.

• Target content area — The component selected in the navigation panel is displayed in the target content area.

Since AJAX transfers are disabled by default, you must explicitly enable AJAX transfers on each fluid wrapper where the behavior is desired:

• For fluid activity guides including fluid navigation collections, add the following query string parameter to the URL for the content reference definition that launches the activity guide: &AJAXTransfer=y

• For master/detail components, add the following query string parameter to the URL for the content reference definition that launches the master/detail component: &ICAJAXTrf=true

• If you are creating a custom fluid wrapper definition in Application Designer (that is, a custom master/detail component or a custom activity guide component), use the SetMDAJAXTrf function.

In addition, when you enable AJAX transfers, then you might also need enable a slide-out left panel to prevent inadvertent left panel collisions:

• For master/detail components, fluid activity guides, and fluid navigation collections, add the following query string parameter to the URL for the content reference definition that launches the fluid wrapper: &ICMDListSlideout=true

• If you are creating a custom fluid wrapper component definition, use the SetMDListSlideout function.

The “slide-out” left panel is a feature that enables you to include a component that itself has a left panel within fluid wrappers (master/detail components, fluid activity guides, fluid navigation collections, or custom fluid wrapper components) that also use the left panel to present navigation links. If collision handling with the slide-out left panel is not enabled, contention will occur as both the outer and inner components attempt to manage the contents of the left panel. When this occurs, users lose the ability to navigate via the navigation links of the outer, wrapper component, via the navigation links of the inner component, or both.

Two types of contention (or collisions) can occur depending on the implementation of the inner component that causes the collisions:

• Intra-page collisions occur when the inner component has included its own left panel (that is, a page type of Side Page 1). Because the fluid wrapper also implements the left panel using Side Page 1, the collisions occur within this side page. Fluid components developed on PeopleTools 8.55 and later releases use Side Page 1 to implement the left panel.

• Inter-page collisions occur when the inner component has included the left panel as part of the page content—for example, in PeopleTools 8.54, the PSL_TWOPANEL layout page provided one mechanism for creating a left panel. In this case, the collisions occur between the Side Page 1 of the fluid wrapper and the content of the inner component.

Image: No collisions detected (slide-out left panel not in effect)

When the slide-out left panel is enabled and an inner component without its own left panel is displayed, the left panel of the outer, fluid wrapper is displayed normally; there is no need for a slide-out left panel.

Image: Slide-out left panel in a closed state

When the slide-out left panel is enabled and an inner component with its own left panel is displayed, the left panel of the outer, fluid wrapper is initially minimized as shown in the following example. The navigation links displayed are those from the inner component:

Image: Slide-out left panel in an open state

Clicking anywhere on the tab divider (labeled Detail, in this example) will slide open the left panel of the outer, fluid wrapper. The navigation links displayed are those from the outer, fluid wrapper:

The slide-out left panel is disabled by default. You must enable the slide-out left panel on each fluid wrapper definition which requires its use:

• For master/detail components, fluid activity guides, and fluid navigation collections, add the following query string parameter to the URL for the content reference definition that launches the fluid wrapper: &ICMDListSlideout=true

• If you are creating a custom fluid wrapper, use the SetMDListSlideout function.

In addition, when you enable AJAX transfers, then you might also need to enable a slide-out left panel to prevent inadvertent left panel collisions.

Within fluid activity guides, master/detail components, and fluid navigation collections, search interactions are not allowed for fluid components. Moreover, the search type must be set to none. In addition, SearchInit PeopleCode cannot be used to set search keys. Therefore, you must use some other mechanism to set component keys for each fluid component.

The following examples show how you could create a “translator component” to set the search keys and then redirect the user to the actual target component. In each example for simplicity in comparisons, it is assumed that two search keys are required and that both keys are of type string. In these examples, the key values are hard-coded within the program. However, you could use other techniques such as global variables or selecting the values from the database as would be appropriate for your application.

Local string &key1 = "value_1";
Local string &key2 = "value_2";

If All(&key1) And
      All(&key2) Then
   SRCH_REC.KEY1.Value = &key1;
   SRCH_REC.KEY2.Value = &key2;
   SetSearchDialogBehavior(0);
End-If;

Local string &key1 = "value_1";
Local string &key2 = "value_2";
Local Record &sRecord = CreateRecord(Record.SRCH_REC);

If All(&key1) And
      All(&key2) Then
   &sRecord.KEY1.Value = &key1;
   &sRecord.KEY2.Value = &key2;
End-If;

Transfer( False, MenuName.MENU_NAME, BarName.BAR_NAME, ItemName.MENU_ITEM_NAME, Page.COMPONENT_ITEM_NAME, %Action_UpdateDisplay, &sRecord);

Local string &key1 = "value_1";
Local string &key2 = "value_2";
Local Array of string &qry_str = CreateArrayRept("", 0);

If All(&key1) And
      All (&key2) Then
   &qry_str.Push("KEYVALUE1=" | EncodeURLForQueryString(&key1));
   &qry_str.Push("KEYVALUE2=" | EncodeURLForQueryString(&key2));
End-If;

Local string &sURL = GenerateComponentContentURL(Portal.PORTAL_NAME, Node.NODE_NAME, MenuName.MENU_NAME, "GBL", Component.COMPONENT_NAME, "", %Action_UpdateDisplay);

If &qry_str.Len > 0 Then
   &sURL = &sURL | &qry_str.Join("&", "&", "");
End-If;

ViewContentURLFluid(&sURL);