This section describes how to modify the Content Server interface:
This section provides information about available skins and layouts provided by default with your Content Server. Skins and layouts provide alternate color schemes and alternate navigation designs.
Several skins and layouts are provided by default with the Content Server. In addition, you can design custom skins and layouts. When users changes the skin or layout, they change the look and feel of the interface. They 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 create and make new or custom skins. See "Configuration Entries" for additional information on setting the default look and feel of the user interface.Skins define the color scheme and other aspects of appearance of the layout such as graphics, fonts, or font size. (the default skin is Oracle). You can design custom skins or modify the existing skins.
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:
The User Personalization settings available on the User Profile page allow users to change the layouts of the Content Server or the skin.
Important:
This personalization functionality works with Internet Explorer 6+ or Mozilla Firefox 3+ and later versions.To change the skin or layout, follow these steps:
On the Content Server Home page, click <your_user_name> in the top menu bar. The User Profile page displays.
On the Content Server User Profile page, select the desired skin and layout.
Click Update and view the changes.
These values can be placed in the IntradocDir/config/config.cfg file to alter the default behavior for the Content Server instance:
LmDefaultLayout: The name of the layout used by guests, and new users. The default is Trays, but it can be set to Top Menus.
LmDefaultSkin: The name of the skin used by guests, and new users. The default is Oracle.
The ExtranetLook component can be used to change the interface for users who log in as anonymous random users. An example of this is when a Content Server-based Web site must be available to external customers without a login, but you want employees to be able to contribute content to that Web site.
When running Content Server on an Oracle WebLogic Server, this 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 into the Content Server repository so it can be referenced by the Content Server templates.
The following files in the IntradocDir/data/users directory can be altered:
prompt_login.htm
access_denied.htm
report_error.htm
Use the following procedure to update the look-and-feel of the Web site based on user login:
Display the Web Layout Editor.
Select Options, then Update Portal.
Modify the portal page as you wish. You can use dynamic resource includes based on user login to customize this page.
Click OK.
Customize the ExtranetLook.idoc file as desired.
Check the ExtranetLook content item out of the Content Server.
Check the revised ExtranetLook.idoc file back into the Content Server.
The Top Menu and Trays 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 using Cascading Style Sheets.
You can modify layouts and skins by altering the template files provided with the Content Server or design new skins and layouts by creating components that can be shared with other users.
This section provides an overview of this process. It includes these topics:
When the 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 then merge a custom row which 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 the Content Server returns to its default state.
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 used to create it did not have any access to the current service's DataBinder or any information about the current user.
This does limit the type of Idoc Script you can write in these files, so 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 thus increases the amount of bandwidth used.
This section describes the general steps needed to create and publish new layouts.
Merge a table into the LmLayouts table in IdcHomeDir/resources/core/tables/std_resources.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_resources.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 PublishStaticFiles table in std_resources.htm. This lists the directories that contain files, such as images, that should be published to the/weblayout directory.
You can direct Content Server to bundle published files so they can be delivered as one, thus minimizing the number of page requests to the server. In addition, you can optimize file use by referencing published pages using Idoc Script.
This section discusses the following topics:
Static weblayout file contents are cached on client machines and on Web proxies, significantly lowering the amount of server bandwidth they use. Therefore, best practice indicates that these types of files should be used 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 this file. This occurs even if the file is cached. Therefore, as the number of these files grows, so does the number of pings to the server for each page request.
To help minimize the number of round-trips, Content Server can bundle multiple published files so they are delivered as one. This feature can be disabled by setting the following configuration in the server's IntradocDir/config/config.cfg file:
BundlePublishedWeblayoutFiles=false
Bundling is accomplished using the PublishedWeblayoutBundles table in the std_resources.htm file.
<@table PublishedWeblayoutBundles@>
<table border=1><caption><strong>
<tr><td>class</td><td>bundlePath</td><td>loadOrder</td></tr>
<tr>
<td>javascript:common</td>
<td>resources/layouts/commonBundle.js</td>
<td>10</td>
</tr>
...
</table>
<@end@>
The columns in this table are as follows:
class: This refers to the same column in the PublishedWeblayoutFiles table and is used to determine which files are placed in which bundle.
bundlePath: The eventual location where the bundle is published. This path is relative to the /weblayout directory.
loadOrder: The order in which this bundle should be loaded on Content Server pages. Bundles with a lower loadOrder are loaded first.
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 class column in the PublishedWeblayoutFiles and PublishedWeblayoutBundles tables is a colon-separated classification. In the following example, two different bundles overlap. food accounts for all three published weblayout files, while food:fruit accounts for two of the three and food:vegetable accounts for the third.
Any given weblayout file can only be published into a single bundle, so food:fruit contains both APPLE and PEAR, while food picks up the leftover CARROT. The server checks each file to be published then looks for the most specific bundle in which to place it. If no bundle exists, it is published as a single file.
The order in which files are included in a bundle is determined through the loadOrder column in the PublishedWeblayoutFiles table. Files with a lower loadOrder are placed earlier in the bundle.
<@table PublishedWeblayoutFiles@>
<table border=1><caption><strong>
<tr>
<td>path</td>
<td>template</td>
<td>class</td>
<td>loadOrder</td>
<td>doPublishScript</td>
</tr>
<tr>
<td>resources/apple</td>
<td>APPLE</td>
<td>food:fruit:apple</td>
<td>10</td>
<td><$doPublish = 1$></td>
</tr>
<tr>
<td>resources/pear</td>
<td>PEAR</td>
<td>food:fruit:pear</td>
<td>20</td>
<td><$doPublish = 1$></td>
</tr>
<tr>
<td>resources/carrot</td>
<td>CARROT</td>
<td>food:vegetable:carrot</td>
<td>10</td><td><$doPublish = 1$></td>
</tr>
</table>
<@end@>
<@table PublishedWeblayoutBundles@>
<table border=1><caption><strong>
<tr>
<td>class</td>
<td>bundlePath</td>
<td>loadOrder</td>
</tr>
<tr>
<td>food:fruit</td>
<td>resources/fruit</td>
<td>20</td>
</tr>
<tr>
<td>food</td>
<td>resources/food</td>
<td>10</td>
</tr>
</table>
<@end@>
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.
To correctly include these files on a page, use the following Idoc Script and include it from somewhere within the HEAD of the page:
<$exec createPublishedResourcesList("javascript:common")$>
<$loop PublishedResources$>
<script language="JavaScript" src="<$HttpWebRoot$><$PublishedResources.path$>" />
</script>
<$endloop$>
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 result set 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.