Customizing the Content Server Interface

5.1 About Customizing the Content Server Interface

Skins and layouts provide alternate color schemes and alternate navigation designs.You can change the skin or layout to customize the Content Server interface.

The content server navigation system consists of a combination of menu bars and tree views, based on the layout the user is in (either Top Menus or Trays). The default layout is Trays, which provides a list of menu titles and options on the left of the page. The predefined Top Menus layout makes these options available in menu bars across the top of the page.

5.1.1 Types of Skins and Layouts

Some skins and layouts are provided by default with Content Server. In addition, you can design custom skins and layouts. When you change the skin or layout, you change the look and feel of the interface. You can select a skin and layout from the options provided on the User Profile page.

The only skills required to create and modify skins or layouts is an understanding of HTML, cascading style sheets, and JavaScript. After altering the appearance, the edited layouts and skins are published so that others in your environment can use them.

Note:

Only administrators can make new or custom skins. For more information about setting the default look and feel of the user interface, see Configure a Default Skin and Layout for New Users and Guests.

5.1.2 Skins

Skins define the color scheme and other aspects of appearance of the layout such as graphics, fonts, or font size. You can design custom skins or modify the existing skins.

Content Server has two existing skins:

Oracle (the default skin)
Oracle2

5.1.3 Layouts

Layouts define the navigation hierarchy display (the default layout is Trays), and custom layouts can be designed. Custom layouts change behavior and the look-and-feel systemwide. If you want your changes to apply only in limited situations, you might want to consider dynamic server pages.These layouts are provided:

Trays: This layout with the standard Oracle skin is the default interface. High-level navigation occurs through the navigation trays.
Top Menus: This layout provides an alternate look, with top menus providing navigation.

Most menu items are generated from data, and there are JavaScript hooks into the menus later. Each user gets a personalized JavaScript file that generates solely a user's navigation links.

5.2 Choosing a Different Skin or Layout

You can choose a different skin to provide an alternate color scheme or a different layout to provide an alternate navigation design, or both.

The User Personalization settings available on the User Profile page enable users to change the layout of Content Server or the skin.

Note:

This personalization functionality works with Internet Explorer 7+ or Mozilla Firefox 3+ and later versions.

To choose a different skin or layout:

On the Content Server Home page, click your_user_name in the top menu bar.

The User Profile page appears.
Choose the desired skin and layout.
Click Update, and view the changes.

After you choose a different skin or layout, it becomes the user interface for Content Server whenever you log in.

5.3 Configure a Default Skin and Layout for New Users and Guests

These values can be placed in the IntradocDir/config/config.cfg file to alter the default behavior for the Content Server instance:

LmDefaultSkin: The name of the skin used by guests, and new users. The default is Oracle.
LmDefaultLayout: The name of the layout used by guests, and new users. The default is Trays, but it can be set to Top Menus.

5.4 Modify the Template for a Skin or Layout

The Trays and Top Menus layouts are included by default with the system. The two layouts have two skin options (Oracle and Oracle2). The layouts are written in JavaScript, and the look of the skins is created by using cascading style sheets.

You can modify skins and layouts by altering the template files provided with Content Server or design new skins and layouts by creating components that can be shared with other users.

5.4.1 About Dynamic Publishing

When Content Server starts, or when the PUBLISH_WEBLAYOUT_FILES service is run, the PublishedWeblayoutFiles table in the std_resource.htm file is used to publish files to the weblayout directory. To have your custom component use this publishing mechanism, create a template, and then merge a custom row that uses that template into the PublishedWeblayoutFiles table.

Other users who want to modify or customize your file can override your template or your row in the PublishedWeblayoutFiles table. If your template uses any resource includes, other users can override any of these includes or insert their own Idoc Script code using the standard super notation. When your component is disabled, the file is no longer published or modified and Content Server returns to its default state.

5.4.2 IdocScript Files for Dynamic Publishing

In addition to giving others an easy way to modify and add to your work, you can also construct these former static files using Idoc Script. For example, you can have the files change depending on the value of a custom configuration flag. You can use core Content Server objects and functionality by writing custom Idoc Script functions and referencing them from inside your template.

Because this Idoc Script is evaluated once during publishing, you cannot use Idoc Script as you would normally do from the IdcHomeDir/resources/core/idoc/std_page.idoc file. When a user requests that file, it has already been created, so the script that was used to create it did not have any access to the current service's DataBinder object or to any information about the current user.

This does limit the type of Idoc Script you can write in these files. If you are writing CSS or JavaScript that needs information that dynamically changes with users or services, consider having the pages that need this code include the code inline. This increases the size of pages delivered by your web server and so increases the amount of bandwidth used.

5.4.3 Navigation Engine Reference

The following navigation engine reference shows the data you can use to add to the navigation menus or trays. For information about how to use this data to customize Content Server navigation, see Creating Custom Components.

5.4.3.1 Dynamic Data Tables for Content Server Navigation

The following sections describe the dynamic data table resources (dynamicdata tables) for Content Server navigation, including what each table is for and what each column does.

5.4.3.1.1 CoreMenuItems

This dynamicdata table defines basic information for every menu item.

Column	Description
`id`	Specifies the ID for the menu item.
`label`	Specifies he label for the menu item. Keys for localized strings are acceptable here, as well as IdocScript.
`linkType`	Determines the way that the `linkData` value is manipulated to create the final link.
`linkData`	Specifies the data for this link.

5.4.3.1.2 CoreMenuItemRelationships

This dynamicdata table defines how menu items in the core navigation system relate to each other. This table shows both where each item should be in relation to its parent as well as in relation to its siblings.

Column	Description
`parentId`	Specifies the ID for the parent menu item. For a node to be a top-level node, enter a special value here, either "`MENU_A`" or "`MENU_B`".
`id`	Specifies the ID for the menu item.
`loadOrder`	Specifies the load order for the menu item. Sibling menu items are loaded in this order. Setting `loadOrder` to blank will cause an item not to be loaded.

5.4.3.1.3 CoreMenuItemsFlags

This dynamicdata table defines the flags for menu items. See also List of Flags.

Column	Description
`id`	Specifies the ID for the menu item.
`flags`	Specifies a colon-separated list of flags for this menu item.

5.4.3.1.4 CoreMenuItemsImages

This dynamicdata table defines the images for menu items when in the Trays layout. Default images are used if not supplied, so it is not necessary to define an image for every item.

Column	Description
`id`	Specifies the ID for the menu item.
`image`	Specifies the image that should appear next to the menu item and also the image that shows next to a folder item when closed.
`imageOpen`	Specifies the image that should appear next to the menu item when open.

5.4.3.1.5 CoreMenuItemsDynamicLoadCallbacks

This dynamicdata table defines the JavaScript function that is the dynamic load callback for menu items. This works only in the Trays layout. When the menu item is opened, the function is called.

Column	Description
`id`	Specifies the ID for the menu item.
`dynamicLoadFunction`	Specifies he JavaScript function to apply as the dynamic load callback. It is possible to place arbitrary JavaScript here as well, so long as it ends up returning a function.

5.4.3.1.6 CoreMenuItemsExitLinks

This dynamicdata table defines exit URLs for menu items. Exit URLs are appended to the parameters when provided. This specialized table is not necessary most of the time.

Column	Description
`id`	Specifies the ID for the menu item.
`exitLinkType`	Determines the way that the `linkData` value is manipulated to create the final exit link (acts the same way as `linkType` in CoreMenuItems.
`exitLinkData`	Specifies the data for this exit link (acts the same way as `linkData` in CoreMenuItems.

5.4.3.1.7 CoreMenuItemsTrayDocLinks

This dynamicdata table defines tray document URLs for menu items. This works only in the Trays layout. A tray document URL can be added to a top-level tray node, which will then open to an iframe using this URL instead of the normal child nodes. This specialized table is not necessary most of the time.

Column	Description
`id`	Specifies the ID for the menu item.
`trayDocLinkType`	Determines the way that the `linkData` value is manipulated to create the final tray document link (acts the same way as `linkType` in CoreMenuItems.
`trayDocLinkData`	Specifies the data for this tray document link (acts the same way as `linkData` in CoreMenuItems.

5.4.3.2 List of LinkType Values

LinkType is used to determine how to manipulate the LinkData value to get the final URL. The following table lists the core LinkType values. You can create your own LinkType values and manipulate the data from either the std_compute_menu_link or navigation_modify_rset_menu_item includes.

LinkType Value	Description
`cgi`	Starts with `HttpCgiPath` and uses `linkData` as the parameters.
`enterprise`	Starts with `HttpEnterpriseCgiPath` and uses `linkData` as the parameters
`web`	Starts with `HttpWebRoot` and appends `linkData` to it.
`admin`	Starts with `HttpAdminCgiPath` and uses `linkData` as the parameters.
`javascript`	Executes `linkData` as JavaScript.
`external`	Uses `linkData` as the URL.

5.4.3.3 List of Flags

The flags in the following table can be appended to a row in CoreMenuItemsFlags to affect the behavior of a menu item. Multiple flags should be separated with a colon.

Flag	Description
`isTopMenusOnly`	Menu item is shown only in the `Top Menus` layout.
`isTraysOnly`	Menu item is shown only in the `Trays` layout.
`isLoggedIn`	Menu item is shown only to users who are logged in.
`isAnonymous`	Menu item is shown only to users who are not logged in.
`isAllowIntranetUsers`	Menu item is shown only if `<$AllowIntranetUsers$>` is true.
`isSelfRegistration`	Menu item is shown only if self-registration is enabled.
`isProxiedServer`	Menu item is shown only if `<$#env.IsProxiedServer$>` is true.
`isContributor`	Menu item is shown only if user is a contributor.
`isAdminAtLeastOneGroup`	Menu item is shown only if user is an admin of one or more groups.
`isSubAdminOrSysManager`	Menu item is shown only if the user is a subadmin or sysmanager.
`isAdmin`	Menu item is shown only if the user is an administrator.
`isSubAdmin`	Menu item is shown only if the user is a subadmin.
`isSysManager`	Menu item is shown only if the user is a sysmanager.
`isContentRefineryPresent`	Menu item is shown only if a content refinery is present.
`isDynamicConverterEnabled`	Menu item is shown only if dynamic converter is enabled.
`isJspServerEnabled`	Menu item is shown only if JSP server is enabled.
`hasIndexAdminActions`	Menu item is shown only if there are index admin actions.
`isGroup`	Identifies the menu item as a group. The item itself is not visible, but any items with this item as the parent will be grouped together.
`targetTop`	Sets this menu item's target as "`_top`"
`targetBlank`	Sets this menu item's target as "`_blank`".

5.4.3.4 Global Javascript Variables

The variables in the following table are available after menu creation so that you can modify menus on the fly.

Javascript Variable	Description
`oMenuBarA`	The `YAHOO.widget.MenuBar` for `menuA`. It is always present.
`oMenuBarB`	he `YAHOO.widget.MenuBar` for `menuB`. It is present only in the `Top Menus` layout.
`oTreeViewA`	The `YAHOO.idc.widget.TrayTreeView` for the side tray. It is present only in the `Trays` layout.

5.4.3.5 Access to Menu Items and Nodes

You can use the YUI API for accessing nodes. Here are some tips for getting a menu or menu-item node:

All YAHOO.idc.widget.TrayTreeView objects have a variable oNodeList. It is an object that references the ID of a node to the node itself. This list is fully populated after startup, but afterwards it needs to be updated manually.
You can easily access menus and menu items with YAHOO.widget.MenuManager, which has the methods getMenu() and getMenuItem().
For menus built from the navigation engine, all menu items are prefixed with "MENU_?_", where ? is either 'A' or 'B' (depending on which menu the item is in).

5.4.3.6 11g Support for NavBuilder Functions

There is partial backwards compatibility between the 11g menu system and the old NavBuilder API. This is provided to keep old components working. New components should not use any of these methods. The following table lists the old NavBuilder functions and their level of support.

Method	Compatibility	Notes
`addTopLevelNode`	Partial	This method affects only nodes added through `addChildNodeTo`. Nodes added through the new system ignore the top-level-node list altogether.
`deleteTopLevelNode`	Partial	This method affects only nodes added through `addChildNodeTo`. Nodes added through the new system ignore the top-level-node list altogether.
`addPrevSiblingNodeTo`	Full
`addChildNodeTo`	Full
`moveItemInto`	Partial	Cloning while moving is no longer available. You cannot move items into the top-level container (that is, `NAVTREE`).
`moveItemAbove`	Partial	Cloning while moving is no longer available. You cannot mix items from the top level and lower levels with this method. For example, moving a node in trays to become a top-level node does not work.
`setAttributeValue`	None	The XML tree is no longer used at all, so this method is not applicable.
`deleteItem`	Partial	If you delete an item from a YUI menu so that the parent no longer has any items in it, the parent will still indicate it has children even though it is empty
`deleteChildrenOf`	Partial	If you delete the children of a YUI menu, the menu will still indicate it has children even though it is empty
`getNodeById`	Partial	This method now returns either a `MenuItem` or `Node` object. It does not return an XML node.
`buildHtmlStringFromXml`	None	The XML tree is no longer used at all, so this method is not applicable.

5.5 Alter the Anonymous User Interface

The ExtranetLook component can be used to change the interface for anonymous, random users. An example of this is when a website based on Content Server must be available to external customers without a login, but you want employees to be able to contribute content to that website.

When Content Server is running on Oracle WebLogic Server, the ExtranetLook component alters privileges for certain pages so that they require write privilege to access. The component also makes small alterations to the static portal page to remove links that anonymous, random users should not see.

Note:

The ExtranetLook component does not provide form-based authentication for Oracle WebLogic Server or provide customizable error pages.

The ExtranetLook component is installed (disabled) with Content Server. To use the component, you must enable it with the Component Manager.

You can customize your web pages to make it easy for customers to search for content, and then give employees a login that permits them to see the interface on login. To do the customization, modify the ExtranetLook.idoc file, which provides dynamic resource includes that can be customized based on user login. The IDOC file is checked in to the Content Server repository so it can be referenced by the Content Server templates.

If the IsWebServerPagesOnly configuration variable is set to TRUE in the IntradocDir/config/config.cfg file, the ExtranetLook web server plug-in delivers customized versions of pages created by the web server filter. It also disables cookie-based login functionality. See Customizing Content Server Communication in Oracle Fusion Middleware Administering Oracle WebCenter Content.

5.5.1 Altering the Anonymous User Interface

You can update the look and feel of the anonymous user interface for the Content Server website by altering the following files in the IntradocDir/data/users/ directory:

prompt_login.htm
access_denied.htm
report_error.htm

To alter the anonymous user interface:

Display the Web Layout Editor.
From the Options menu, choose Update Portal.
Modify the portal page as you want to. You can use dynamic resource includes to customize this page.
Click OK.
Customize the ExtranetLook.idoc file as you want to.
Check out the ExtranetLook content item from Content Server.
Check in the revised ExtranetLook.idoc file to Content Server.

After you modify the portal page and customize the ExtranetLook.idoc file, your design becomes the user interface for Content Server whenever a user goes to the website without logging in.

5.6 Changing the URL of the Login Page

You can change the URL of the Login page for Content Server by changing its context root, which is normally /cs/. You cannot change the URL by setting a relative context root with the HttpRelativeWebRoot property because the value of this property does not apply to the Login page. If you need to change the web location where users log in, you can redeploy the WebCenter Content application with a deployment plan.

To change the URL of the Login page:

Log in to the Oracle WebLogic Server Administration Console as the administrator of the domain where WebCenter Content is deployed.
Click Deployments under the name of your domain, in the Domain Structure area on the left.
Click Oracle WebCenter Content - Content Server in the Deployments table on the Control tab of the Summary of Deployments page.
This application may be on the second or third page of the table.
Note the path to the deployment plan.
If no plan is specified for your WebCenter Content instance, you can create one:
1. Click Configuration on the Settings for Oracle WebCenter Content - Content Server page.
2. Change the value of any parameter on the Configuration tab.
3. Click Save.
4. Confirm the path to the deployment plan on the Save Deployment Plan Assistant page, or change the path.
5. Click OK.

In a text editor, add lines at two places in the deployment plan:

Add the original_loginpage_path and original_loginerror_path variables, each in a <variable> element of a <variable-definition> element, as in this example:

<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan 
 http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd"> 
    <application-name>ServletPlugin</application-name> 
    <variable-definition> 
     <variable> 
       <name>original_loginpage_path</name> 
       <value>/content/login/login.htm</value> 
     </variable> 
     <variable> 
       <name>original_loginerror_path</name> 
       <value>/content/login/error.htm</value> 
     </variable> 
      <variable> 
        <name>SessionDescriptor_timeoutSecs_12996472139160</name> 
        <value>3600</value> 
     </variable>

In the <module-descriptor> element of web.xml in the cs.war file, add two <variable-assignment> elements that assign the following values to the original_loginpage_path and original_loginerror_path variables, respectively:

/web-app/login-config/form-login-config/form-login-page

/web-app/login-config/form-login-config/form-error-page

For example:

    <module-override> 
      <module-name>cs.war</module-name> 
      <module-type>war</module-type> 
      <module-descriptor external="false"> 
        <root-element>weblogic-web-app</root-element> 
        <uri>WEB-INF/weblogic.xml</uri> 
      </module-descriptor> 
      <module-descriptor external="false"> 
        <root-element>web-app</root-element> 
        <uri>WEB-INF/web.xml</uri> 
        <variable-assignment> 
          <name>original_loginpage_path</name> 
          
 <xpath>/web-app/login-config/form-login-config/form-login-page</xpath> 
        </variable-assignment> 
        <variable-assignment> 
          <name>original_loginerror_path</name> 
          
 <xpath>/web-app/login-config/form-login-config/form-error-page</xpath> 
       </variable-assignment> 
      </module-descriptor> 
    </module-override> 
    <module-override>

Stop the WebCenter Content Managed Server (UCM_server1 by default), with the stopManagedWebLogic script:
- UNIX script: DomainHome/bin/stopManagedWebLogic.sh UCM_server1
- Windows script: DomainHome\bin\stopManagedWebLogic.cmd UCM_server1
In the Administration Console, click Deployments under the name of your domain.
Select Oracle WebCenter Content - Content Server in the Deployments table, and click Update.
Select Redeploy this application using the following deployment files, make sure the path to the deployment plan is correct, and then click Finish.
After the redeployment completes successfully, click Apply Changes.
Start the WebCenter Content Managed Server with the startManagedWebLogic script.
- UNIX script: DomainHome/bin/startManagedWebLogic.sh UCM_server1
- Windows script: DomainHome\bin\startManagedWebLogic.cmd UCM_server1
In the Administration Console, click Deployments.
Select Oracle WebCenter Content - Content Server in the Deployments table, and from the Start menu, choose Servicing all requests.
After the WebCenter Content application is launched, verify that the URL of the login page has changed.

5.7 Creating and Publishing a New Layout

The following general steps are necessary to create and publish new layouts:

Merge a table into the LmLayouts table in IdcHomeDir/resources/core/tables/std_publishing.htm to define the new layout. Define the layout ID, label, and whether it is enabled (set to 1) or not.
Merge a table into the PublishedWeblayoutFiles table in IdcHomeDir/resources/core/tables/std_publishing.htm. This new table describes the files that are created from Content Server templates and then pushed out to the weblayout directory. Specify the necessary skin.css files to push out to each skin directory.
Merge a table with the PublishedStaticFiles table in std_publishing.htm. This lists the directories that contain files, such as images, that should be published to the weblayout directory.

5.8 Optimize the Use of Published Files

You can direct Content Server to bundle published files so that they can be delivered as one, minimizing the number of page requests to the server. In addition, you can optimize file use by referencing published pages using Idoc Script.

5.8.1 Bundling Files

Multiple resources may be packaged together into units called bundles. A bundle is a single file containing one or more published resources. Only JavaScript and css resources should be bundled and only with other resources of the same type. Bundling helps reduce the client overhead when pages are loaded but increases client parse, compile, and execute overhead. Generally, it is recommended to bundle resources that have some thematic similarity or are expected to be included at similar times. For example, if you know that resources A, B, and C are needed on every page, and resources D, E, and F are needed rarely but are all needed together, it is recommended to bundle A, B, and C together and to put D, E, and F into a separate bundle.

Almost all JavaScript resources for the Content Server core are bundled into one of two bundles: yuiBundle.js, which contains script provided by the third-party Yahoo User Interface library, and bundle.js, which contains the rest of the resources.

The PublishedBundles table is used for determining how resources are bundled. Essentially a bundle is identified by its target bundlePath, which is the path name to the bundle (relative to the weblayout directory), and a list of rules detailing which resource classes are included or excluded. A loadOrder value in this table applies only to the order in which the filtering rules are applied, not the order in which the resources appear in the bundle.

Note:

The bundling has changed since Oracle Universal Content Management 10g, which used a different table and had a loadOrder value that determined the order of resources in each bundle.

Static weblayout file contents are cached on client machines and on web proxies, significantly lowering the amount of server bandwidth they use. Therefore, the best practice is to use these types of files wherever possible.

However, each static weblayout file requested by the client's browser requires a round-trip to the server just to verify that the client has the most up-to-date version of the file. This occurs even if the file is cached. As the number of these files grows, so does the number of downloads from the server for each page request.

To help minimize the number of round-trips, Content Server can bundle multiple published files so that they are delivered as one. You can disable this feature by setting the following configuration in the server's IntradocDir/config/config.cfg file:

BundlePublishedWeblayoutFiles=false

Bundling is accomplished by using the PublishedBundles table in the std_publishing.htm file, which {Example - PublishedBundles Table in std_publishing.htm file} shows.

In the previous example, files of the javascript:common class are published to a single bundle located at resources/layouts/commonBundle.js. The contents of all bundled files that match this class are appended to form a single file to be stored at that location.

The columns in this table are as follows:

PublishedBundles Table Column	Description
`bundlePath`	The eventual location where the bundle is published. This path is relative to the `weblayout` directory.
`oMenuBarB`	he `YAHOO.widget.MenuBar` for `menuB`. It is present only in the `Top Menus` layout.
`oTreeViewA`	The `YAHOO.idc.widget.TrayTreeView` for the side tray. It is present only in the `Trays` layout.

Example - PublishedBundles Table in std_publishing.htm File
<@table PublishedBundles@>
<table border=1><caption><strong>
    <tr>
        <td>bundlePath</td>
            <td>includeClass</td>
        <td>excludeClass</td>
        <td>loadOrder</td>
    </tr>
    <tr>
    <td>resources/bundle.js</td>
        <td>javascript:common</td>
        <td></td>
        <td>128</td>
    </tr>
. . .
</table>
<@end@>

5.8.2 Referencing Published Files

Most published files (both bundled and unbundled) must be directly referenced from within HTML to be included in a page. It can therefore be difficult to know exactly which files to include for a given situation, especially when bundling can be enabled or disabled by server administrators. A simple Idoc Script method can be used to easily and transparently include all of the files you need on a given page.

For example, if you write a page that includes all files associated with the javascript:common bundle (as described previously), then do not write HTML that includes all of the files mentioned in the first table in addition to the bundle mentioned in the second, the server is asked for each file. This negates the purpose of bundling because the server is pinged for each file whether it actually exists or not.

{Example - Idoc Script to Reference a Bundle of Files} shows Idoc Script code, within the HEAD section for a page, to correctly include these files on the page.

This code fragment includes all javascript:common files even if bundling is switched off. If javascript instead of javascript:common is passed, all files whose class starts with javascript are included.

This PublishedResources ResultSet is sorted by loadOrder, so files and bundles with the lowest loadOrder are included first. Files with a greater loadOrder can override JavaScript methods or CSS styles that were declared earlier.

Example - Idoc Script to Reference a Bundle of Files
<$exec createPublishedResourcesList("javascript:common")$>
<$loop PublishedResources$>
<script language="JavaScript" src="<$HttpWebRoot$><$PublishedResources.path$>" />
</script>
<$endloop$>