Oracle® Fusion Middleware Portal Development Guide for Oracle WebLogic Portal 10g Release 3 (10.3.4) Part Number E14243-06 |
|
|
View PDF |
This chapter describes how to use the portal framework to develop the overall appearance and behavior of the portal you develop in Oracle Enterprise Pack for Eclipse. You will be able to look at a rendered portal in a browser and understand which pieces of the underlying framework that you need to modify to obtain the results you want. In addition, the look and feel editor is discussed. The look and feel editor lets you interactively modify the text styles used by a portal.
This chapter includes the following sections:
Section 7.6, "Using Look And Feels From Previous Portal Releases"
Section 7.13, "Building User Interfaces to Address Accessibility Guidelines"
A look and feel file determines the appearance of your portal application, from the placement and behavior of elements on a portal page to the colors used in the portlet title bars.
By using the portal rendering framework, developers can modify and create new look and feel files that portal administrators can apply to individual portal desktops. If visitor tools are enabled, end users can then access different look and feels to change the appearance of their own portal instance.
WebLogic Portal includes robust examples and templates to use when creating the user interface for your portal in Oracle Enterprise Pack for Eclipse.
As with other portal resources (J2EE libraries and so on), you must copy framework resources to your web project before you can modify them. However, in many cases, customizing the user interface for your portal involves modifying a single file or creating a new file to reference rather than modifying an entire set of framework resources.
As a best practice, you should only keep the resources in your project that you need to modify. This allows you to more easily upgrade to newer versions of WebLogic Portal. When you upgrade, all predefined portal resources from J2EE library modules to look and feel files are overwritten.
Table 7-1 lists the key elements involved in the look and feel framework:
Table 7-1 Elements of a Look And Feel
Framework File | What it does: |
---|---|
|
This file is an XML file that includes references to a specific skin and skeleton XML file. The |
|
The |
|
The |
Chromosomes and Genes and chromosomes |
A gene defines a particular characteristic of a look and feel, such as a CSS property that can be referenced as a variable in look and feel resources (a A |
|
A |
|
The layout file is used to provide the structure for portal pages as well as headers and footers. The layout file you choose (one column, two column and so on) determines where you can place portlets and books within a page, header, or footer. For example, if you want to place portlets within your header, you must apply a layout to that header. |
|
A shell file defines the header and footer regions of your portal. If you have applied a |
|
A menu file defines the navigation style you want to use in your portal. WebLogic Portal provides two types of menus: single-level tab style and multi-level nested. |
This section includes these topics:
A look and feel file (.laf
) is an XML block that is inserted into the overall .portal
XML file that determines the style and behavior of a portal. A look and feel file references a specific skin and skeleton. A skin provides a set of images, JavaScript functions, and CSS files. Skeleton files contain the JSPs that convert the portal XML components to the final HTML output. Figure 7-1 shows the Look And Feel and related files in the lookandfeel folder. These files are provided with WLP. You can also create your own look and feel files (see Section 7.4, "Creating a New Look and Feel"). To view this folder, open the Merged Projects view and select <webproject>/framework/markup/lookandfeel
.
Skins and skeletons can leverage skin or skeleton chromosome files which allow you to set variables for CSS values and JavaScript actions, see Section 7.3.4, "Working with Genes and Chromosomes."
When you select a different look and feel for a portal desktop, you potentially change the skin and skeleton (and other supporting files) that are used to render the portal.
You assign a look and feel to a portal desktop by specifying a value for a Look and Feel desktop property. You can also allow portal visitors to choose a look and feel by enabling Dynamic Visitor Tools and providing different look and feels from which they can choose. See also Chapter 9, "Using the Dynamic Visitor Tools."
You assign an existing look and feel (*.laf
) to your desktop in Oracle Enterprise Pack for Eclipse. As you develop or customize your portal's look and feel, this is a helpful way to view your changes.
To assign a look and feel to a desktop using Oracle Enterprise Pack for Eclipse:
Navigate to the location of the portal whose properties you want to edit, and double-click the .portal
file to open it in the editor.
Click the border of the desktop to display its properties in the Properties view.
Navigate to the Properties view and choose a look and feel from the look and feel property down-down list for that desktop's properties, as shown in Figure 7-2.
Optionally, to view recent, saved changes to your look and feel, click Reload.
To see how the look and feel you have selected affects your portal, navigate to your *.portal file, right-click and select Run As > Run on Server.
A number of legacy WLP look and feel components have been deprecated. This section lists the look and feel components that have been deprecated and explains how to upgrade a WLP application to use them with WLP 10.3.2 and later versions.
WLP has deprecated several legacy look and feels and layouts. Table 7-2 lists the deprecated components and their replacements. Note that the deprecated components are no longer included in a WLP web project by default. When you upgrade an older application, however, these components are added automatically. See Section 7.2.3.3, "Upgrading a WLP Application to Use Deprecated Components."
The deprecated legacy look and feels and layouts no longer appear by default in the IDE or Administration Console. Under the Merged Projects view, the contents of the framework/markup/layout, framework/markup/lookandfeel, framework/markup/skeletons, and framework/markup/skins folders contain only the components that are supported by default. For example, the look and feel file classic.laf
no longer appears under framework/markup/lookandfeel, as shown in Figure 7-3.
Figure 7-3 Default Contents of the lookandfeel Folder
In addition, only the new Look and Feels appear in the Look and Feel menu of the portal desktop Properties view, as shown in Figure 7-4.
Figure 7-4 Look and Feel Property Selections
Similarly, the Layout Type Page Property menu only contains the new layouts by default, as shown in
When you follow the domain and application upgrade procedures outlined in the Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Portal, the deprecated components are automatically added. No further action is required by you.
To manually add these components to or remove them from a portal web application, right-click the web application in the Project Explorer in Oracle Enterprise Pack for Eclipse, and select Properties. Then, select Project Facets and add or remove the WebLogic Portal (Optional) > Portal Deprecated Markup Files facet.
The deprecated components are physically located in the J2EE Shared Libraries listed in Table 7-3. These library files are located here in your WLP installation:
FM_HOME/wlportal_10.3/light-portal/deprecated/lib/j2ee-modules
Table 7-3 J2EE Shared Libraries Containing Deprecated Components
Component Category | J2EE Shared Library |
---|---|
Deprecated Layouts |
wlp-light-deprecated-web-lib.war |
Deprecated Look and Feels |
wlp-lookandfeel-deprecated-web-lib.war |
You can find references to these library files in:
<wls:library-ref>
element(s) in WEB-INF/weblogic.xml
. A separate element exists for each library file.
<library>
element(s) in your domain's config.xml
file. This file is located in DOMAIN_HOME/wlp/config
. A separate element exists for each library file.
WebLogic Portal provides several predefined look and feel files that you can use in your applications. The predefined look and feels are listed in Table 7-4. Often it is easier to customize one of these existing look and feels to suit your needs, rather than develop your own. For example, you can customize a look and feel by editing associated CSS files or by using genes and chromosomes to create color or JavaScript variables. For more information about genes, Section 7.3.4, "Working with Genes and Chromosomes."
Tip:
When choosing a WLP look and feel to customize, use ONLY skins or skeletons prefaced with the name "bighorn". Other deprecated templates are available for use in WebLogic Portal; however, these deprecated templates do not support new look and feel features such as genes and chromosomes. For information on deprecated Look and Feels, see Section 7.2.3, "Adding Deprecated Look and Feel Components to a Web Project."
Using an existing, predefined look and feel ensures that you always have the necessary look and feel files necessary for properly rendering your portals. Table 7-4 lists the look and feels that are included to use as starting points.
Table 7-4 Predefined Look And Feels
Look and Feel Name | Skeleton | Skin | Skeleton Chromosomes | Skin Chromosomes |
---|---|---|---|---|
bighorn |
bighorn |
bighorn |
No |
No |
bighorn-xhtml |
bighorn-xhtml |
bighorn |
No |
No |
bighorn-genes |
bighorn |
bighorn-genes |
No |
default.chromosome |
bighorn-water |
bighorn |
bighorn-genes |
No |
water.chromosome |
bighorn-fire |
bighorn |
bighorn-genes |
No |
fire.chromosome |
bighorn-template |
bighorn |
bighorn |
No |
No |
Note:
The bighorn-xhtml skeleton does not enforce XHTML compliance for portal content. Non-compliant portlets in portals using this skeleton will cause rendering errors.
This section describes ways to customize an existing look and feel. You can use one of these suggested methods independently or use them together.
If you want to create a new look and feel, see Section 7.4, "Creating a New Look and Feel."
The following topics are covered in this section:
You can create a custom look and feel file that is based on different combinations of predefined skin and skeleton files. For example, if you require an XHTML skeleton and would also like to use genes in your skin file, you can combine those respective files into a new look and feel file.
To create a new look and feel file based on predefined skin and skeleton files, do the following:
In Navigator view, right-click your portal web project and choose New > Look And Feel. A wizard guides you through the rest of the process.
After you name your new look and feel, you see the window shown in Figure 7-7.
In the Skin field, use the ellipsis icon to navigate to the skin you would like to use and select the skin.xml
file.
In the Skeleton field, use the ellipsis icon to navigate to the skeleton you would like to use and select the skeleton directory.
Note:
To select a skin, you must select a skin.xml
file. To select a skeleton, you must only select the skeleton directory.
Click Finish.
The new look and feel is opened in the look and feel editor.
Create a 100x75 px .gif
that represents the look and feel in the same directory as the .laf
file. This gif file must have the same name as your *.laf file.
For example, create a gif file called telecom.gif
to represent a look and feel file called telecom.laf
. This image appears in the visitor tools when end users select look and feels for their own customized view of a portal desktop.
If you want to make overrides to the selected skin and/or skeleton, you must manually create your skin and skeleton directories and files in the /skins/
<your_skin>
and /skeletons/
<your_skeleton>
directories. In this case, you do not have to create a full set of skin or skeleton files. You need to create only the skin or skeleton files that will override the files in the base skin or skeleton you selected.
For example, if you use the "bighorn" skin in your new look and feel, and you create only a bighorn/images/titlebar-button-edit.gif
file, that graphic overrides the graphic in the "bighorn" skin. All other bighorn skin resources are used for your look and feel.
You use the look and feel file to re-order your titlebar buttons or change window icons. The bighorn look and feel files included with WebLogic Portal include a default titlebar order, as shown in Example 7-1. You can re-order titlebar buttons by editing the XML in your look and feel file.
Example 7-1 Default Titlebar Button Order in the bighorn.laf File
<netuix:titlebarButtonOrder> <netuix:otherButtons/> <netuix:namedButton name="float"/> <netuix:namedButton name="edit"/> <netuix:namedButton name="help"/> <netuix:namedButton name="minimized"/> <netuix:namedButton name="maximized"/> <netuix:namedButton name="delete"/> </netuix:titlebarButtonOrder>
CSS files are used by skin.xml
files to define your HTML rendering, and to define colors, border styles, images, and so on.
By modifying CSS files, you can change many aspects of your look and feel file. Each skin.xml
file uses multiple CSS files to define various aspects of the skin. In addition, you can create custom CSS files to override existing CSS files or add new attributes.
Each skin.xml
file included with WebLogic Portal includes a reference to a custom.css
file that is reserved for your customizations. This CSS file is a placeholder for any CSS changes you want to make to the skin.xml
file you wish to use.
More commonly, you will want to add custom CSS styles. The easiest way to do this is to add your customizations to the custom.css
file included in your skin.xml
file.
The following example shows you how to use the custom.css
file that is included in the bighorn look and feel file's respective skin directory. This custom.css
is already referenced in the bighorn skin.xml
file.
Tip:
You can use steps similar to these to modify any specific look and feel resource. For example, if you want to modify images that are referenced by a skin.xml
file, you can copy the image to your project, modify it and save it with the same name. This method allows you to perform minor customizations without modifying entire look and feel files and their resources.
To customize the bighorn skin.xml
using the custom.css
file:
Using the Merged Projects view, navigate to /yourWebProject
/framework/skins/bighorn/css/custom.css.
Right-click on the custom.css
file and select Copy to Project.
In the Project Explorer, navigate to /
yourWebProject
/framework/skins/bighorn/css/custom.css
.
Right-click the custom.css
file and choose open it with the editor of your choice.
You can now add any custom styles you want to use in your skin. These can include any number of CSS properties such as one that changes the border of all portlets, as shown by the example in Example 7-2
Genes give you an extra level of flexibility, control, and ease of maintenance in working with a look and feel file. A gene defines a particular characteristic of a look and feel, such as a CSS color property, that can be referenced as a variable in look and feel resources.
For example, if a look and feel is defined to have a gene named wlp.portlet.border.color, you can use that gene name in your CSS files rather than a literal color definition. If that gene is defined to be the color value #ff0000, any CSS that uses that gene variable gets that color value. You only have to modify the color value in the gene definition to automatically update all CSS files that use that gene.
Chromosomes are files that contain one or more genes. You can create multiple chromosome files that contain the same gene names, though with different gene values. By referencing a different chromosome in your look and feel file, you can simulate a completely different look and feel without changing any of your core look and feel resource files.
You can also use genes in your JavaScript functions.
Using genes is optional and provides the following advantages in your look and feel:
Simplified look and feel customization for minor modifications such as color scheme changes.
Convenient facility to support the generation of dynamic values in associated CSS files or JavaScript files.
Easier implementation of branding, allowing one look and feel to be used for multiple brands. For example, by creating a new chromosome that provides different values for genes that are used in the look and feel, you can reference that new chromosome in the look and feel file and provide different appearance and behavior for the existing look and feel.
Global parameterization capabilities. For example, genes can be used to share a set of global properties to toggle the rendering of certain portal-wide features.
Important: In order to use genes, you must configure the CSS and JavaScript entries in your skin.xml
to be inlined in the HTML rather than referenced, as described in Section 7.4.1, "Working with Skins."
Following is an example that highlights one of the primary benefits of genes.
In a .chromosome
file, you could define a gene called "bodyColor" and assign it a value of "red," like this:
<gene name="bodyColor"> <value>#FF0000</value> </gene>
In your CSS file, you could use bodyColor as a variable:
body { border:1px solid ${bodyColor}; };
When the page is rendered in a browser, the inlined style definition becomes:
body { border:1px solid #FF0000; };
When you use this gene in your CSS files, you only need to modify the gene value itself to cascade the change throughout all configured CSS files rather than changing the value manually in each CSS file.
Each skin and theme that uses genes must have its own unique chromosome files, even if they are duplicates of each other. Chromosome files are stored in the same directory as the respective skin.xml
and skeleton.xml
.
The default.chromosome
file is intended to contain the complete set of genes for a particular skin.xml
file. By using the default.chromosome
file, you can keep all your genes in one place. When you need to override a particular gene, you can provide an additional .chromosome
file. If the look and feel framework does not find a gene in the chromosome you specify in the .laf
file, it looks for it in the default.chromosome
file.
Note:
As a best practice, you should use a one-to-one representation of genes to CSS property values.
To create and use genes:
Create a new *.chromosome
file.
Select File > New > Other.
In the New dialog, open the XML folder and select XML. The New XML File wizard opens.
Choose Create XML From XML Schema File and click Next.
Enter a name for the XML file in the XML File Name dialog and click Next.
In the Select XML Schema File dialog, choose Select XML Catalog Entry and in the Key column select laf-genes-1_0_0.xsd as the schema. Click Next.
In the Select Root Element dialog, click Finish.
Rename the generated file's extension from .xml to .chromosome.
Add genes to the chromosome, using the structure shown in Section 7.3.4.1, "Gene Example."
Note:
Gene values can contain references to other genes.
In your skin or theme CSS files, replace the appropriate hard-coded style values with the related gene names, using the ${geneName}
syntax.
In your skin.xml
or *.theme
files, make sure you reference your CSS or JavaScript files so that they appear inline in the final HTML output, as described in Section 7.4.1, "Working with Skins."
If you want to create multiple versions of chromosomes that provide identically named genes with different values, copy the default.chromosome
, give it a new filename (such as holiday.chromosome
). Delete all but the genes in that file you want to override, and provide different values for those genes. Copy the new .chromosome
file to any skin or skeleton directories for which it will be used.
Open your look and feel file in the XML editor, and add specific the .chromosome
file you want to use for the look and feel by adding one or both of the following attributes to the <netuix:lookAndFeel>
element:
<netuix:lookAndFeel skinChromosome="holiday" skeletonChromosome="holiday"
The look and feel framework does not check to see if a gene you reference is defined in a chromosome. If the framework cannot find a gene, it prints the gene variable in the HTML output.
The look and feel editor HTML preview does not display CSS values that are represented by gene variables. Any CSS rules that use genes are dropped from your HTML preview. If you want to preview a portal's look and feel that use genes, you can do so by right-clicking .portal
file and selecting Run On Server.
If you want to do extensive redesign of either the skeleton aspects of your portal (placeholders, layout, and so on) or skin elements (color, borders, buttons and so on), you can create a new look and feel file based on a skin and skeleton templates included with WebLogic Portal.
Tip:
WebLogic Portal recommends using the bighorn-template look and feel to create any new look and feel files. It supports genes and provides a complete set of look and feel files that take advantage of the features of the latest version of WebLogic Portal.
You can copy all of the resources associated with a specific skin and skeleton and modify most or all of them to suit your needs. This option should be used only if you need to do extensive modifications that cannot be accomplished with CSS files or genes.
Caution:
When creating new a new look and feel file, use skins or skeletons prefaced with the name "bighorn". Other deprecated templates are available for use in WebLogic Portal; however, these deprecated templates do not support new look and feel features such as genes and chromosomes. For information on deprecated Look and Feels, see Section 7.2.3, "Adding Deprecated Look and Feel Components to a Web Project."
To create a new look and feel based on a provided template:
In Navigator view, right-click your portal web project and choose New > Look And Feel. A wizard guides you through the rest of the process.
Name your look and feel file and chose next, the Look And Feel Details page displays as shown in Figure 7-7.
In the Skin field, use the ellipsis icon to navigate to the skin you would like to use and select the skin.xml
file.
To copy the skin as a template, mark the Copy skin as template check box, and navigate to the project location where you would like to save the skin files.
In the Skeleton field, use the ellipsis icon to navigate to the skeleton you would like to use and select the skeleton directory.
To copy the skeleton as a template, mark the Copy skeleton as template check box, and navigate to the project location where you would like to save the skeleton files.
Click Finish. The new look and feel is opened in the look and feel editor.
Create a 100x75 px .gif
that represents the look and feel in the same directory as the *.laf
file.This image appears in the visitor tools when end users select look and feels for their own customized view of a portal desktop and must have the same name as your *.laf
file, but with a *.gif
extension.
For example, create a gif file called telecom.gif
to represent a look and feel file called telecom.laf
. This image appears in the visitor tools when end users select look and feels for their own customized view of a portal desktop.
The following sections provide guidance on working with your new look and feel.
Section 7.4.2, "Working with Skeletons"
Note:
See Section 7.8, "The Look And Feel Editor" for information about using the look and feel editor.
Skins are collections of images, cascading style sheets (CSS), and JavaScript files that allow changes to be made to the look and feel of a portal without modifying the portal components directly. References to images and styles are made in the skin rather than being hard coded into the portal definition.
Skins, combined with skeletons, make up a portal desktop's look and feel.
Each skin has its own /images, /css, and /js (JavaScript) subdirectories that contain its skin resources. Create and store your look and feel images, CSS files, and JavaScript files in these directories. You can also store global look and feel resources in a common location outside of a skin's root directory. A skin knows which resources to use based on its skin.xml
file, stored in the skin's root directory. The skin.xml
tells the skin which paths to look in to find image, CSS, and JavaScript files that the look and feel uses.
Use the following guidelines when configuring a skin.xml
file:
The <target-skeleton> section specifies the skeleton to use if no skeleton is specified in the look and feel file.
The <images> section lets you set the paths the skin should use to find images. For example:
<skin> <images> <search-path> <path-element>images</path-element> <path-element>../default/images</path-element> </search-path> </images> </skin>
This block tells the skin to look in the skin's images subdirectory, and for any files it cannot find in that directory to look for in the default skin's images directory.
Search paths are relative to the skin directory.
The <render-dependencies> section lets you determine how CSS styles and JavaScript functions are inserted into the <head> region of the HTML.
The <search-path> child element of <links>, <scripts>, and <styles> serves the same purpose and behaves the same as it does for images.
Use the <links> section if you want to insert references to CSS files in the HTML <head> area.
To reference JavaScript files:
<html> <scripts> <script src="my.js" type="text/javascript" /> <search-path> <path-element>js</path-element> <path-element>../default/js</path-element> </search-path> </scripts> </html>
If you want to inline JavaScript functions in the HTML output (for example, if you are using genes), use the following types of entries:
<html> <scripts> <script content-uri="my.js" type="text/javascript" /> </scripts> </html>
or
<html> <scripts> <script type="text/javascript"> alert("Hello World!"); </script> </scripts> </html>
Typically, you should reference your CSS files in your skin.xml
unless you are using genes. To reference CSS files, use the following types of entries:
<html> <links> <search-path> <path-element>../bighorn/css</path-element> </search-path> <link href="general.css" rel="stylesheet" type="text/css"/> <link href="menu.css" rel="stylesheet" type="text/css"/> </links> </html>
When you are using genes, you need to inline CSS style definitions in the HTML output To inline CSS style definitions, use the following types of entries:
<html> <styles> <style content-uri="my.css" type="text/css" /> <search-path> <path-element>css</path-element> <path-element>../bighorn/css</path-element> </search-path> </styles> </html>
or
<html> <styles> <style type="text/css"> .bea-portal-body { margin: 0px; padding: 0px; background-color: #ffffff; font-family: Verdana, Arial, Helvetica, sans-serif; color: #000000; } </style> <search-path> <path-element>css</path-element> <path-element>../bighorn/css</path-element> </search-path> </styles> </html>
Create a structure.xml
file in the skin's root directory, which lets you specify:
The paths to any themes that correspond to the skin. You can also set paths to look and feel files that you want to use as themes, assuming you have created a .theme
file that corresponds to that look and feel.
The paths to any resources that correspond to different device classification.
Any localization subdirectories.
Following is a sample structure.xml
file:
<?xml version="1.0" encoding="UTF-8"?> <structure xmlns="http://www.bea.com/servers/portal/framework/laf/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/portal/framework/laf/1.0.0 laf-structure-1_0_0.xsd"> <specializations> <localizations> <localization locale="ja"/> </localizations> <classifications path="classifications"> <classification name="nokia"/> <classification name="mozilla"/> </classifications> </specializations> <themes> <theme name="red_theme" path="../../redtheme"/> <theme name="holiday" path="holiday"/> </themes> </structure>
Create a structure.xml
file in each skin directory. Using this file gives you flexibility in the location of the themes and classification look and feel files, and supports look and feel localization.
For best performance, reference your CSS and JavaScript files rather than inlining them in the HTML.
If you are using genes (see Section 7.5, "Working with Themes"), you must inline the CSS styles and JavaScript functions that use genes.
Note:
Skeletons hard code the names of look and feel resources, such as CSS style names, JavaScript functions, and image names. If you rename resources from their default names, you must also modify those names throughout your skeleton JSPs.
Each predefined look and feel includes a specialization directory that includes resources (including a separate skin.xml
) that are used for Microsoft Internet Explorer. Considerations for Internet Explorer includes specific Javascript for menus, for example.
If you create your own look and feel or make extensive skin modifications, you may require additional browser-specific additions for Internet Explorer. As a best practice, use the existing MSIE classification skin.xml
to include these additions.
In addition, if you add new skin resources, you will need to add them to both your look and feel skin.xml
and the skin.xml
within the MSIE directory. For example, if you add a new CSS file you need to add a link to the new CSS file in both the skin.xml
file in the /markup/skins/ directory and the skin.xml
file in the /markup/skins/msie/ directory, as illustrated in Figure 7-8.
Figure 7-8 Location of MSIE Specialization Directory
Note:
The MSIE specialization directory takes advantage of client-classifications to track different resources. For more information about client-classifications, see Chapter 12, "Creating Portals for Multiple Device Types."
The icon graphics used in portlet title bars are stored in a skin /images
directory. The names of these graphics are declared in the portal web project's WEB-INF/netuix-config.xml
file to determine which of these graphics to use for the portlet's different states and modes (minimize, maximize, help, edit). If you want to change the name of the graphics used for the portlet title bar icons, change the filenames and the corresponding entries for those graphics in netuix-config.xml
.
WebLogic Portal provides a set of skeletons in the look and feel files it provides. This section discusses skeletons and provides guidance on developing your own skeletons for your own custom look and feel files.
A skeleton.xml
file controls the document type and markup that are emitted by a portal. Skeletons provide the physical boundaries for portal components (such as books, pages, and portlets). A portal web project can have multiple skeletons. When you select a Look & Feel for a desktop, a specific skeleton (and skin) is used.
Each type of portal component, from a desktop to a portlet's title bar, has an associated skeleton JSP file that renders it. Some skeleton files are simple, others are more complex. For example, each desktop uses a skeleton file called desktop.jsp
that determines and renders the appropriate DOCTYPE information for your portal. A portlet title bar, on the other hand, has a skeleton file called titlebar.jsp
that is more complex and provides references to button graphics.
Each portal component has one or more corresponding skeleton JSP files, located in the <web_project>/framework/skeletons
directories. For example, a portlet title bar has a corresponding skeleton JSP file that renders it. When a portal desktop is rendered, the skeleton JSPs for each portal component (in conjunction with any related classes) perform their logic and insert the resulting HTML into the correct hierarchical locations of the HTML file.
Skeletons also use the WebLogic Portal API to get specific types of information, such as presentation context and style overrides that developers may enter in the Properties view for a selected component.
In summary, skeleton JSPs combine API calls, JSP tags, and HTML snippets to ultimately render a portal desktop in HTML. Example 7-3 provides an example of a well-formed skeleton JSP.
Tip:
For more information on the skeleton tag library, see the "Portal Skeleton Rendering" in Oracle Fusion Middleware JSP Tag Java API Reference for Oracle WebLogic Portal.
Example 7-3 Book.jsp Skeleton from the Bighorn Look and Feel
<!-- The book skeleton file renders a HTML <DIV> element for the book. This <DIV> element contains a menu and book content. The book content is contained within an additional HTML <DIV> element. --> <jsp:root version="2.0" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:skeleton="http://www.bea.com/servers/portal/tags/netuix/skeleton"> <jsp:directive.page session="false" /> <jsp:directive.page isELIgnored="false" /> <skeleton:context type="bookpc"> <skeleton:control name="div" presentationContext="${bookpc}" presentationClass="wlp-bighorn-book" presentationId="${bookpc.label}"> <skeleton:child presentationContext="${bookpc.menuPresentationContext}"/> <skeleton:control name="div" content="true" presentationContext="${bookpc}" presentationClass="wlp-bighorn-book-content"> <skeleton:children/> </skeleton:control> </skeleton:control> </skeleton:context> </jsp:root>
Each skeleton you create must have its own skeleton.xml
file in the your skeleton's root directory. One example of when you might want to create your own skeleton is if you want to provide appropriate rendering on a particular mobile device.
Use the following guidelines when developing your own skeletons:
If you want to use CSS styles and JavaScript functions in your skeletons to help control behavior, reference those CSS files/styles and JavaScript files/functions in the skeleton.xml
file the same way you reference them in a skin.xml
file.
In the skeleton.xml
, you can also control content types or doctypes to help ensure proper rendering. For example:
<skeleton> <render-format> <preset>HTML_4_01_TRANSITIONAL</preset> </render-format> </skeleton>
The <preset> elements allows values for XHTML_1_0_STRICT, XHTML_1_0_TRANSITIONAL, HTML_4_01_STRICT, HTML_4_01_TRANSITIONAL, HTML_4_01_STRICT_NO_SYSTEM_ID, HTML_4_01_TRANSITIONAL_NO_SYSTEM_ID, HTML_3_2, and NONE.
You can define your own <custom-htmlType> or <custom-xhtmlType>, using <doctype-public-id> and <doctype-system-id> child elements. In addition, the <custom-xhtmlType> element provides <namespace-uri> and <schema-system-id> child elements.
You can provide content type overrides for individual types of devices, such as mobile devices, using:
<content-type-overrides> <override classification="nokia" content-type="application/xhtml+xml" /> </content-type-overrides>
where classification is the name of a device type defined in WEB-INF/client-classifications.xml
; and content-type can also use the value "text/html".
Keep in mind that JSPs are rendered literally. That is, if there are blank lines in the JSP, there will be blank lines in the HTML. At times you may need to sacrifice JSP readability for quality HTML output.
Create a structure.xml
file in the skeleton directory, as described in Section 7.4.1, "Working with Skins." This file lets you reference skeleton themes, skeleton resources for different types of devices (classifications), and localized skeleton subdirectories.
To render a portal that is XHTML compliant, you must set the portal to emit XHTML and you must develop your portlets using a framework that supports XHTML. Note that by default, portals support HTML 4.01 Transitional.
To enable a portal for XHTML compliance, you need to do one of the following.
Set the skeleton render format to XHTML_1_0_STRICT, XHTML_1_0_TRANSITIONAL or HTML_4_01_STRICT. See Section 7.4.2.2, "Guidelines for Creating Custom Skeletons."
Select an XHTML-compliant look and feel. Currently, WLP supplies the bighorn-xhtml skeleton. This skeleton is used by the Bighorn (XHTML) look and feel. This skeleton is designed to be valid in accordance with the XHTML 1.0 Transitional DTD.
The use of the bighorn-xhtml skeleton does not imply XHTML compliance of content. You must also assure that your portlets are XHTML compliant. Non-compliant portlets in portals using this skeleton will cause rendering errors. XHTML compliance in portlets depends on the framework used to develop the portlet, as described in Table 7-5.
Table 7-5 Portlet Framework Support for XHTML
Framework | XHTML Support |
---|---|
NetUI |
Supports HTML or XHTML rendering. You can set the render format with a flag in |
Struts 1.x |
The Struts JSP tags emit HTML and are not XHTML compliant. |
JSF 1.x |
Supports XHTML transitional. Does not support XHTML strict. |
The current AJAX implementation does not support XHTML. The implementation performs DOM operations that are known not to work in some browsers when using an XHTML content type. See "Considerations for AJAX-based Asynchronous Rendering" in Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
Themes provide a way to override the look and feel of books, pages, or portlets, allowing those components to look or behave differently than the rest of the portal desktop. For example, you can set a theme on a portlet that displays a jagged portlet border, turns the portlet title bar red, and displays different portlet title bar button images.
You can use themes in skins and/or skeleton files. In the previous example, the skeleton theme would control the jagged portlet border, and the skin theme would contain the modified CSS and title bar images.
You also use themes to develop look and feels for specific devices, such as mobile devices, to be used in conjunction with WebLogic Portal's multichannel framework.
Themes are made up of the same types of resources as regular skins and skeletons. The themes typically provide only the files necessary to override the overall look and feel, though full look and feels can also be used as themes. Themes can also be used as look and feels.
Themes are made up of the following resources:
The .theme
file is a simple XML file that provides the name of a theme, and ensures that theme name appears in drop-down menus for selection by developers, portal administrators, or end users.
Theme resources include supporting files such as *.gif
files or *.css
files. The example in Figure 7-9 depicts the "alert" theme which is a subdirectory of the "default" skin, which in turn contains its own look and feel resources. If the alert theme is selected for a book, page, or portlet, the portal framework looks in the structure.xml
file in the look and feel's /skin or /skeleton directories for theme locations. If no structure.xml
file is present, the framework looks for /alert skin and skeleton subdirectories under whichever look and feel is being used. If found, the files in the /alert subdirectory take precedence over or are used in addition to the files used in the parent look and feel.
For example, if the alert theme provides a titlebar.jsp
skeleton file, the portal framework uses that skeleton file instead of the parent skeleton's titlebar.jsp file.
Figure 7-9 shows the types of resources included in a theme:
This section includes the following topics:
If you are using Internet Explorer, there are additional tasks associated with using themes to modify skins. See Section 7.4.1.2, "Considerations for Microsoft Internet Explorer" for more information.
To develop a theme:
In Merged Projects view, navigate to your portal web project's framework/markup/theme
directory, and copy an existing theme to your file system.
Open the copied theme, and modify the name, title, description, and markupName. Each theme must have a unique markupName.
Save the file with a new filename.
Create a 100x75 px .gif that represents the theme in the same directory as the .theme
file and have the same name.This gif file must have the same name as your *.theme
file.
For example, create a gif file called telecom.gif
to represent a *.theme
file called telecom.theme
. This image appears in the visitor tools when end users select themes for their own customized view of a portal desktop.
Create the theme directory (using the same, case-sensitive name as the theme markupName) and subdirectories. You can create the theme resources anywhere in the portal web project, where it can be used by any look and feel. Create any unique resources that the theme will use, or duplicate and modify any resources you want to override in the parent skin or skeleton.
For any skin or skeleton, be sure to create a structure.xml
file that specifies the path to the current theme, as described in Section 7.4.1, "Working with Skins."
You can also create a structure.xml
in the theme directory if you also plan to use the theme as a full look and feel.
If you do not use the structure.xml
file in your look and feel /skin and /skeleton directories, store your themes as subdirectories of those skins and skeletons.
Note:
If you create any unique resources, be sure to reference them either in the parent skin or skeleton, or in the theme skin or skeleton.
After you create a theme, you can select it in the Properties view for any selected book, page, or portlet.
You can use look and feels created in previous WebLogic Portal releases by importing them into your portal web project (into the proper directories).
If you have look and feel files from WebLogic Portal 8.1 and want to use genes, you will need to upgrade your look and feel files. To upgrade a previous look and feel, open the .laf
file in Oracle Enterprise Pack for Eclipse from your portal web project. You are prompted to create the skin.xml and skeleton.xml files. After creating these new files, you are ready to use the new WebLogic Portal look and feel features.
Note:
In WebLogic Portal 8.1, skin.properties
files could also contain settings for themes. In WebLogic Portal 9.2 and higher, themes are stand-alone look and feels that use their own skin.xml
files. If your WebLogic 8.1 skin.properties
files contain theme details that you want to reuse, you must manually add those theme settings to your theme's skin.xml
files.
To troubleshoot or fine tune a look and feel, use the following guidance:
Use the Look And Feel editor to determine which CSS properties you need to modify. See Section 7.8, "The Look And Feel Editor" for details.
When viewing a portal desktop in a browser, view the HTML source to help determine where a problem is occurring and where it needs to be fixed, in a skin or skeleton.
If the problem is a CSS-related issue, use the HTML source to locate the CSS style that needs to be modified.
If the problem is a structural issue, use the HTML source to help pinpoint which shell resource or skeleton JSP needs to be modified.
This section describes the Look and Feel Editor and includes these topics:
The look and feel editor lets you interactively edit the text styles used by portal text elements. Technically, the editor modifies Cascading Style Sheet (CSS) files that are referenced by a portal's skin.xml
file. For example, using the look and feel editor, you can change the size of a heading, the color of a list element, or the padding around a table cell for a portal.
The look and feel editor also lets you change the properties of a portal's look and feel file (.laf
file), such as the skin and skeleton files that it references.
In addition, the editor shows you, at a glance:
The CSS cascade for a portal
The properties assigned to a selected CSS style
The inherited properties of a selected CSS style
The elements of the portal's skin.xml
file
With the look and feel editor, you can experiment with a portal's look and feel and see the results immediately. The look and feel editor lets you interactively edit the text styles used by a portal. Using the look and feel editor, you can select text in a portal and modify the text's characteristics, such as font size, color, padding, and so on. The changes you make are immediately reflected in the editor's view area.
Remember that a portal's skin helps to define the overall look and feel of a portal. The portal's skin.xml
file specifies one or more CSS files used by the skin. A portal's HTML text can reference these CSS files and use their style definitions. If you modify the font size for a particular text style, the look and feel editor changes the style's definition inside a CSS file. The change is then immediately reflected in the HTML displayed in the editor's view area.
The following figure shows the parts of the look and feel editor. This section discusses each of these parts in detail.
Figure 7-10 Look And Feel Editor Components
The Navigator view displays the file structure of a portal project. Use this panel to locate and select the look and feel file for the portal that you wish to edit. The look and feel (.laf)
file contains references to the skins and skeletons that define a portal's look and feel.
To open the look and feel editor, use the Navigator view to locate the .laf
file for the portal you wish to edit. Then, double-click the filename to open the look and feel editor. The .laf
files for a portal are located in the portal web project's framework/markup/lookandfeel
folder. For example, the mycustom.laf
file is shown selected in the Navigator view in Figure 7-11.
Tip:
Use the menu function Edit > Look and Feel to quickly change the format of the preview HTML rendered by the Look and Feel Editor. None of these settings are saved when the Look and Feel editor is closed. Table 7-6 describes the Look and Feel menu options.
Note:
Oracle Enterprise Pack for Eclipse tries to detect if the look and feel being edited is based on Bighorn or the others and use the appropriate preview HTML. Some legacy Look and Feels are deprecated and require extra configuration to make them available. For information on deprecated Look and Feels, see Section 7.2.3, "Adding Deprecated Look and Feel Components to a Web Project."
Table 7-6 Look and Feel Menu Functions
Menu Function | Description |
---|---|
Render Alternative Text |
Changes the preview HTML being rendered with the open look and feel to an alternate view. (See the previous note.) |
Render Bighorn Text |
Changes the preview HTML being rendered with the open look and feel to the Bighorn view. (See the previous note.) |
Render Default Text |
Changes the preview HTML being rendered with the open look and feel to the default view. (See the previous note.) |
Render Custom Text... |
Changes the preview HTML being rendered with the open look and feel to custom HTML text that you can enter directly in a dialog. |
Render Custom URL... |
Lets you enter a URL or file for the preview HTML. Use this option to preview the look and feel with your own portal that is running on a server. |
The Style Hierarchy tab shows the CSS cascade for the selected style. The cascade is a hierarchy of CSS styles, defined by the HTML document structure. It is useful to see the cascade, because it can help you to locate and appropriately handle inherited style properties. In Figure 7-12, note that the style wlp-bighorn-window-content is below wlp-bighorn-window in the hierarchy. This means that wlp-window-content can inherit properties from wlp-bighorn-window, and, potentially, from all other style classes higher up the hierarchy. For more information on inheritance, see Section 7.8.5.1, "CSS Inheritance." When you select a style in the Style Hierarchy view, its style definitions and inherited style properties appear in the Style Description window, described in Section 7.8.5, "Style Description Panel."
The Link Style Hierarchy Selection with HTML Preview Selection button, shown in Figure 7-12, lets you control whether or not the Style Hierarchy view changes to reflect what is selected in the Look & Feel Editor view. When this button is toggled on, the Style Hierarchy view updates its display to show the style hierarchy corresponding to the styles of the selected HTML element in the editor. If this button is toggled off, the Style Hierarchy view does not update when you click in the Look & Feel Editor. This button is toggled on by default. In a typical use case, you can select an element in the editor and then toggle this button off to "lock" the Style Hierarchy view. Then, you can click around in the editor to compare the "locked" Style Hierarchy to other selected elements in the editor.
The Style Description panel lets you see at a glance the selected style's properties and its inherited style properties. The Style Info section, shown in Figure 7-13, comes directly from the CSS file in which the style is defined. The Inherited Styles list, also shown, is constructed directly from the document structure of the HTML text that is currently opened in the look and feel editor. The Inherited Styles list shows the style properties and their values that are inherited from styles higher up in the document hierarchy. For instance, you can see that wlp-bighorn-window-content inherits the background color property from the wlp-bighorn-book-content style.
Figure 7-13 Window Shows Inherited Styles
To understand the value of the Inherited Styles list, it helps to have a basic understanding of HTML and CSS.
Tip:
This section is a very brief overview of CSS inheritance. Many books and web sites are devoted to CSS and cover this important subject in greater depth.
HTML documents are hierarchically organized. In other words, each element of an HTML document can have one or more child elements, one parent element and possibly many ancestor elements. A central feature of CSS is that styles are inherited down the HTML document hierarchy. For example, Figure 7-14 depicts a simple HTML document hierarchy:
If you would like all the text in this document to be blue, you could define the body
tag to be blue. Because of CSS inheritance, all of the elements below body
(specifically, li
and h1
) will also be blue. If, on the other hand, you would like everything to be blue except list elements, you could define the ul
tag to be another color, such as red. Then, all of the li
elements inherit the color red from their parent, ul
. At the same time, the h1
tags will be blue (h1
tags still inherit their color from body
).
The look and feel editor shows you all styles that a selected style inherits. Therefore, if you want to change the font size of a style, but font size is not defined in that style, you can see at a glance from which style font size is inherited. Then, you can easily edit the property, as explained in the next section.
Tip:
Without this convenient feature, it would be difficult to decide which styles a given style inherited. Typically, you would have to open and examine the CSS files in the hierarchy to find where a specific style property is defined or possibly overridden.
As mentioned in the previous section, in some cases, the property you wish to modify is not defined in the specific CSS style class associated with the text you have selected. It is possible, for instance, to select a heading in the look and feel editor, but find that font size is not a property of that heading's style. In this case, the property you wish to change might be an inherited property.
The look and feel editor displays and lets you edit any inherited property for a given style. For example, suppose you wish to change the font size of some text. After selecting the style you wish to edit (for example, by clicking the text in the View Area), you then notice that font-size
is not a property of that text's CSS style. Next you look at the Inherited Styles list, and you discover a style higher up in the cascade in which font-size is defined.
At this point, you must decide whether you want to edit the font-size property where it is currently defined (higher up in the cascade) or add the property directly to the style of the text you wish to modify. Of course, if you modify a property up the cascade, you might inadvertently change the properties of other text that inherits the same property. It is up to you to make this decision. If you change it directly in the selected style, then the inherited property is overridden, and only that style (and any styles down the hierarchy) receive the new property value (unless it is once again overridden).
Tip:
To add or modify a property in an inherited style, double-click the style name in the Inherited Styles list. Then, use the CSS Style Wizard to make your changes.
HTML documents are hierarchically organized. In other words, each element of an HTML document can have one or more child elements, one parent element and possibly many ancestor elements. A central feature of CSS is that styles are inherited down the HTML document hierarchy. For example, the following tree diagram depicts a simple HTML document hierarchy:
If you would like all the text in this document to be blue, you could define the body tag to be blue. Because of CSS inheritance, all of the elements below body (specifically, li and h1) will also be blue. If, on the other hand, you would like everything to be blue except list elements, you could define the ul tag to be another color, such as red. Then, all of the li elements will inherit the color red from their parent, ul. At the same time, the h1 tags will be blue (h1 tags still inherit their color from body).
The look and feel editor shows you all styles that a selected style inherits. Therefore, if you want to change the font size of a style, but font size is not defined in that style, you can see at a glance from which style font size is inherited. Then, you can easily edit the property, as explained in the next section.
The View area displays the HTML that uses the CSS styles you wish to edit. When you start the look and feel editor, a default HTML page is displayed, showing a representative sample of text elements.
Note:
Remember that you start the look and feel editor by opening a look and feel (.laf
) file. The HTML file that is shown in the View Area must reference the same CSS files that the .laf
file references in its skin. If you load the default HTML page into the editor, this connection is automatically established. However, if you load HTML from a portal into the editor, you must be sure the portal references the same .laf
file as the editor.
The Outline view shows a representation of the files that are referenced by the portal's skin.xml file. In this panel you can edit properties of:
The look and feel (.laf
) file for the portal
The style properties located in each of the CSS (.css
) files referenced by the portal's skin
Figure 7-15 shows a portion of the Document Structure panel. In this figure, the css/portlet.css
file is expanded to reveal the styles defined in it. You can double-click a style to add or modify its properties. You can also single-click a .css
file, style name, or style property to display and edit values in the Properties view.
Figure 7-15 Double-Click a Style to Modify Its Properties
In addition to using this panel to access CSS styles, you can also access and edit the properties of the look and feel file associated with a portal, as shown in Figure 7-16. You can change any of these properties, including picking new skin and skeleton files. Note that the look and feel file node occurs at the top of the document structure.
Figure 7-16 Look and Feel file in the Outline View
The Properties view lets you interactively modify values of the selected CSS style or look and feel file. To display properties in the Properties view, you can do one of the following:
Click on a text element in the HTML file in the View Area.
Click a CSS style or the look and feel filename in the Outline view.
Click on a CSS filename in the Outline view, then expand the CSS file in the Properties view to edit the properties.
This section discusses these useful features of the Look and Feel Editor:
The Link Style Hierarchy Selection with HTML Preview Selection button
The Mouse-Over Button
The Link Style Hierarchy Selection with HTML Preview Selection button, shown in Figure 7-17, lets you control whether or not the Style Hierarchy view changes to reflect what is selected in the Look & Feel Editor view. When this button is toggled on, the Style Hierarchy view updates its display to show the style hierarchy corresponding to the styles of the selected HTML element in the editor. If this button is toggled off, the Style Hierarchy view does not update when you click in the Look & Feel Editor. This button is toggled on by default. In a typical use case, you can select an element in the editor and then toggle this button off to "lock" the Style Hierarchy view. Then, you can click around in the editor to compare the "locked" Style Hierarchy to other selected elements in the editor.
Figure 7-17 The Link Style Hierarchy Selection with HTML Preview Selection Button
The Mouse Motion button provides a convenient way for you to scan the CSS style information as you move the mouse pointer around the Look and Feel editor window. When the Mouse Motion button, shown in Figure 7-18, is toggled on, the Outline and Properties views update immediately as you move the mouse over the Look and Feel editor window. If you select the Link Style Hierarchy Selection with HTML Preview Selection button (described previously), the mouse will also track the Style Hierarchy and Style Description views. When you click in the Look and Feel Editor window, the Mouse Motion button automatically toggles off.
The following packages, documented in Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal, let you perform many programmatic operations on look and feels:
com.bea.netuix.laf
com.bea.netuix.laf.genes
com.bea.netuix.laf.genes.mutators
Shells define the header and footer regions of a portal. You can include portlets, JSPs, and HTML files in a shell to define the content displayed in the header or footer. You can create a new shell or modify existing shells.
Note:
Shells created with previous versions cannot be modified using the shell editor. You must continue to use an XML editor to modify previously created shells.
This section includes the following topics:
To create a new shell:
In Merged Projects view, copy an existing shell from your portal web project's framework/markup/shells directory to your file system.
In the Project Explorer, right-click the shell and select Open With > Shell Editor.
Within the Outline view, click the shell to view its properties in the Properties view.
In the Shell Properties view, modify the title and the description properties.
Save the new shell.
You can modify the properties of shell, as well as header and footer properties. One of the most common shell modifications is to add a layout to a header or footer. When you add a layout to a header or footer, you can place portlets within the header or footer, respectively.
To modify a shell:
In the Merged Projects view, right-click the shell and select Open With > Shell Editor.
In the Shell Editor, click the element you want to modify such as the header or footer.
In the Properties view, modify the properties that you want to change. For example, choose a Layout Type to use.
Save your changes
If you want to change the shell that is used by your portal desktop, you must update the Shell property for your portal. For more information about updating portal properties, see Section 8.2.1, "Editing Portal Properties."
If you have modified or assigned a new shell to your portal desktop, you must reload the shell to ensure your changes are saved.
To reload a shell:
Update the shell property using the Properties view.
Click the Reload button next to the Shell property drop-down list.
To place portlets in a header or footer, you must first associate a layout with the respective header or footer.
You may notice that portlets in a header or footer do not display a delete button, even if the portlet specifies that it should have one. When you put a layout inside of a header or footer, the placeholders inside the layout are considered to be "locked." This means that users can't move or delete the contents of the placeholders. Therefore, even if a portlet in a header or footer specifies that it is supposed to have a delete button, the delete button will not render.
Layouts, used by portal pages as well as headers and footers, provide structure that determines where you can place portlets and books within a page. Layouts can be implemented using HTML tables or CSS-based approaches.
WebLogic Portal provides a set of predefined layouts you can use in your portals, available for selection in the Properties view when you select a page in the portal editor. For more information about page properties, see Section 8.2.2.4, "Page Properties."
In addition to using the predefined layouts that WebLogic Portal provides, you can create custom layouts A layout includes the following files:
An XML file with a .layout
extension - This file maps to a skeleton JSP that renders the final layout in HTML.
An HTML file with a .html.txt
extension - Used to simulate the layout in the portal editor and WebLogic Portal Administration Console.
This section describes the following layout tasks:
WebLogic Portal provides the following three standard layouts for creating your own layouts: border layout, flow layout, and grid layout, as shown in Figure 7-19.
Figure 7-19 Standard Layouts: Border, Flow, and Grid
You create each type of layout by configuring the .layout
file to suit your needs. For example, you could create a border layout that uses only North (N), West (W), and East (E) areas.
Each type of standard layout has a corresponding skeleton JSP to render it as HTML: borderlayout.jsp
, flowlayout.jsp
, and gridlayout.jsp
.
If you want to create a layout beyond what the standard layouts provide, you must create a custom layout. See Section 7.11.2, "Creating a Custom Layout."
To create a standard layout:
In Merged Projects view, copy an existing .layout
file and its corresponding .html.txt
file from your portal web project's framework/markup/layouts in the shared J2EE libraries.
Open the layout, and rename it. Be sure to retain the .layout
extension. Rename the .html.txt
file using the same name as the new layout, but retain the .html.txt
extension.
In the .html.txt
file, create an HTML table structure that provides the layout configuration you want.
In the .layout
file, inside the <netuix:markup>
tag, insert opening and closing <netuix:gridLayout>
, <netuix:flowLayout>
, or <netuix:borderLayout>
tags, depending on the type of layout you want to create. (Replace the existing opening and closing <netuix:*Layout>
tag.)
Inside the opening <netuix:*Layout>
tag, add (or modify) the following attributes, as shown in Table 7-7.
For example, if you are modifying a copy of the fourcolumnflow.layout
to create a border layout, replace the columns attribute with the layoutStrategy attribute and change its value.
Attribute | Description |
---|---|
Title |
Provides the name for selecting the layout in a drop-down menu. |
Description |
Provides a description for the selected layout. |
Border layout attributes |
layoutStrategy – Enter If you enter <netuix:placeholder>North</netuix:placeholder> makes the placeholder the north placeholder. If you enter <netuix:placeholder title="south" ...></netuix:placeholder> makes the placeholder the south placeholder. |
Flow layout attributes |
orientation – Enter |
Grid layout attributes |
columns – Determines the number of columns in the layout. The number of rows are determined automatically. Do not use the rows – Determines the number of rows in the layout. The number of columns is determined automatically. Do not use the |
htmlLayoutUri |
Provides the path (relative to the project) to the |
markupName |
The markupName must be unique among the other layouts. |
Inside the <netuix:*Layout>
tag, add opening <netuix:placeholder>
and closing </netuix:placeholder>
tags for each placeholder you want in the layout.
If you are creating a border layout, use no more than five placeholders.
In the opening <netuix:placeholder>
tag of each placeholder, add the following attributes:
title – Enter a title for the placeholder. If you are using a border layout with the layoutStrategy attribute set to title
, enter north
, south
, east
, west
, or center
for the title to determine which position of the placeholder in the border layout.
description – Enter a description for the placeholder.
flow – Optional. If you want to control whether the books and portlets are automatically positioned vertically or horizontally when they are added to a layout, enter true
.
usingFlow – Optional. If you set the flow
attribute to true
, enter vertical
or horizontal
for this attribute value. This value determines whether books and portlets are positioned on top of each other in the placeholder (vertical) or side by side (horizontal).
width – Optional. Set a width for the placeholder.
markupType – Required. Enter Placeholder
.
markupName – Required. Used as an ID for the placeholder. Each placeholder must have a unique markupName across all layouts.
If you are creating a border layout and the layoutStrategy attribute is set to order
, enter North
, South
, East
, West
, or Center
as the content between the opening and closing <netuix:placeholder>
tag to determine each placeholder's position in the layout. For example, <netuix:placeholder>North</netuix:placeholder>
makes a placeholder the north placeholder.
Save the layout file.
Create a 100x75 px .gif
that represents the layout in the same directory as the .layout
file and have the same name, but with a *.gif
extension. This image appears in the visitor tools when end users select layouts for their own customized view of a portal desktop.
You can now use the layout in your portals, by selecting a page in the portal editor and selecting the layout in the Properties view.
If none of WebLogic Portal's standard layouts suit your needs, you can create a custom layout. When creating a custom layout you need to create three things:
The layout file for a custom layout is the same type of file that is used in creating standard layouts. A layout file is an XML file that must have a .layout
extension and can live anywhere in the web application directory except /WEB-INF
.
You must create the .layout
files by hand (using a text or XML editor). The best way to get started is by copying an existing layout, located in the shared J2EE library in your portal web project's /framework/markup/layout
directory.
The following example uses a custom layout with one vertical column on the left, with a spanning row at the right with two vertical columns underneath.
The layout looks something like this, as shown in Figure 7-20.
As a best practice, store your custom layout and its supporting files in a separate directory. This example assumes that your custom layout is stored in the /webContent/custom/layout/.
Note:
The the easiest way to create a new *.layout
file is to copy one from another layout.
In this example, the layout file is called example.layout
as shown Example 7-4.
This example layout uses the generic netuix:layout
tag since gridLayout, borderLayout, or flowLayout cannot construct the desired layout. It has four placeholders, named "left", "upper", "lower_left" and "lower_right".
Note:
The skeletonUri attribute is important for custom layouts, because you will often develop a custom skeleton JSP to render your custom layout. This attribute tells the portal rendering framework which JSP to use.
Example 7-4 Sample Code for the example.layout File
<?xml version="1.0" encoding="UTF-8"?> <netuix:markupDefinition xmlns:netuix="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0 markup-netuix-1_0_0.xsd"> <netuix:locale language="en"/> <netuix:markup> <netuix:layout markupType="Layout" markupName="exampleLayout" title="Example Custom Layout" description="Example with Left, Upper, Lower Left and Lower Right placeholders" skeletonUri="/custom/layout/examplelayout.jsp" htmlLayoutUri="/custom/layout/example.html.txt" iconUri="/framework/markup/layout/example.gif" thumbnailUri="/framework/markup/layout/example.gif" type="example"> <netuix:placeholder markupType="Placeholder" markupName="exampleLayout_left" title="left" usingFlow="false" description="Left Side placeholder" width="30%"> </netuix:placeholder> <netuix:placeholder markupType="Placeholder" markupName="exampleLayout_upper" title="upper" usingFlow="true" flow="horizontal" description="Upper placeholder with horizontal flow" width="70%"> </netuix:placeholder> <netuix:placeholder markupType="Placeholder" markupName="exampleLayout_lowerLeft" title="lower_left" usingFlow="false" description="Lower Left placeholder (below Upper)" width="35%"> </netuix:placeholder> <netuix:placeholder markupType="Placeholder" markupName="exampleLayout_lowerRight" title="lower_right" usingFlow="false" description="Lower Right placeholder (below Upper)" width="35%"> </netuix:placeholder> </netuix:layout> </netuix:markup> </netuix:markupDefinition>
This example requires a custom skeleton to do the rendering (as specified by the skeletonUri attribute). You must create this JSP, copying it to any look and feels in which the layout is to be used. As with the layout file, the easiest way to create a custom layout JSP is to copy an existing one.
Example 7-5 displays what the custom skeleton JSP (/framework/markup/layout/examplelayout.jsp
) looks like:
<jsp:root version="2.0" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:skeleton="http://www.bea.com/servers/portal/tags/netuix/skeleton" > <jsp:directive.page session="false" /> <jsp:directive.page isELIgnored="false" /> <skeleton:context type="layoutpc"> <skeleton:control name="table" presentationContext="${layoutpc}" class="wlp-bighorn-layout" cellspacing="0" cellpadding="0" width="100%" > <c:set var="ph" value="${layoutpc.placeholders}"/> <c:set var="left" value="${ph[0]}"/> <c:set var="upper" value="${ph[1]}"/> <c:set var="lowerLeft" value="${ph[2]}"/> <c:set var="lowerRight" value="${ph[3]}"/> <tr> <td rowspan="2" valign="top" width="${left.width}"> <skeleton:child presentationContext="${left}"/> </td> <td colspan="2" width="${upper.width}"> <skeleton:child presentationContext="${upper}"/> </td> </tr> <tr> <td valign="top" width="${lowerLeft.width}"> <skeleton:child presentationContext="${lowerLeft}"/> </td> <td valign="top" width="${lowerRight.width}"> <skeleton:child presentationContext="${lowerRight}"/> </td> </tr> </skeleton:control> </skeleton:context> </jsp:root>
The custom layout is now functionally complete. The html.txt file has not yet been created, but you can test the layout. To do this, create a portal file, select a page, and in the Properties view select the custom layout in the Layout field.
Note:
If you change your .layout file after you have used it in the .portal file, you need to reload the changed layout. To reload a layout, update the layout property using the Properties view. Then click Reload. then click Reload (next to the layout property drop-down list).
The .html.txt
is an HTML
snippet used by Oracle Enterprise Pack for Eclipse to give a visual representation of what the layout looks like, so the developer or administrator can place the portlets in the correct placeholders.
In this example, the custom.html.txt
file is /framework/markup/layout/example.html.txt
and should look something like the example shown in Example 7-6:
Example 7-6 Sample example.html.txt Code
<table class="portalLayout" id="thePortalLayout" width="100%" height="100%"> <tr> <td class="placeholderTD" valign="top" rowspan="2" width="30%"> <placeholder number="0"/> </td> <td class="placeholderTD" valign="top" colspan="2" width="70%"> <placeholder number="1"/> </td> </tr> <tr> <td class="placeholderTD" valign="top" width="35%"> <placeholder number="2"/> </td> <td class="placeholderTD" valign="top" width="35%"> <placeholder number="3"/> </td> </tr> </table>
Menus determine the navigation style used for your portal pages. WebLogic Portal provides two types of menus: single-level for single rows of tabs and multi-level for nested, drop-down style page navigation.
Single Level Menu - Provides visible layering of book and page links. Any sub-books and pages appear in rows below the main book navigation.
Multi Level Menu - Provides a single row of tab-like links for the books and pages at the level you apply the Multi Level Menu. Any sub-books and pages appear in a drop-down list for selection. The Multi Level Menu implements JavaScript functionality contained in the skins.
If you want navigation menu behavior other than what is provided with the default menus, modify the singlelevelmenu.jsp
or multilevelmenu.jsp
skeletons in your look and feel /skeletons directory by copying those files from the shared J2EE library to your file system and making the desired modifications. If you are modifying the multi-level menu behavior, you may also need to modify the skin's menu.js
file located in your skin's /js
subdirectory.
To use images on page tabs (Rollover Image, Selected Image, Unselected Image in the Properties view for a selected book), enter a path to the images that is relative to the look and feel's image search paths specific in the skin.xml
file.
For example, if you skin.xml image search path is <path-element>images</path-element>
, and your menu images are stored in your skin's /images
directory, enter the name of the image file in the Properties view. If your menu images are stored in an /images subdirectory of your portal web project, enter a path to the graphic like this: ../../../../images/my_rollover.gif
.
Many organizations are required to provide web sites that meet industry or government standards for supporting people with special needs. And even if you do not have specific requirements, it is just good business to design your site to serve the needs of a diverse audience.
WebLogic Portal provides a flexible architecture that supports the design, development, and management of accessible portals and applications, for example, the ability to target specific user interfaces based on user preferences or browser and request attributes.
To learn more about building user interfaces with WebLogic Portal, see Section 7.2, "Working with Look And Feel Files."
This section contains information on the following subjects:
When you develop web sites, you can use the following general guidelines to facilitate accessibility. For a complete list, refer to the industry or government regulation relevant for your implementation.
Text Tags – Provide a text equivalent for every non-text element (for example, using "alt", "longdesc", or in element content).
Multimedia Presentations – Synchronize equivalent alternatives for any multimedia presentation.
Color – Design web pages so that all information conveyed with color is also available without color. (for example, from context or markup.)
Readability (style sheets) – Organize documents so they are readable without requiring an associated style sheet.
Server-Side Image Maps – Provide redundant text links for each active region of a server-side image map.
Client-Side Image Maps – Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
Data Table (simple row and column headers) – Identify row and column headers for data tables
Data Tables (multiple levels of row and column headers) – Use markup associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
Frames – Entitle frames with text that facilitates frame identification and navigation.
Flicker Rate – Design pages to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
Text-Only Alternative – Provide a text-only page, with equivalent information or functionality, to make a web site comply with the provisions of this section when compliance cannot be accomplished in any other way. You must remember to update the content of the text-only page whenever the primary page changes.
Scripts – When pages use scripting languages to display content, or to create interface elements, you must identify the information provided by the script with functional text that can be read by assistive technology.
Applets and Plug-ins – When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, you must provide a link in the page to a plug-in or applet that complies with Section 508 §1194.21(a) through (l).
Electronic Forms – When electronic forms are designed to be completed online, you must create the form to allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
Navigation Links – Provide a method that permits users to skip repetitive navigation links.
Time Delays – When a timed response is required, you must alert users and give them sufficient time to indicate more time is required.
http://www.w3.org/WAI/w3c.htm
- Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
Table 7-8 lists some government regulation resources.
These tools allow you to validate web page code. They do not repair your code, but they do provide reports on what does and does not need to be fixed, as relating to HTML 4.0, W3C, Section 508 and general accessibility issues.
W3C Web Accessibility Initiative's Web Tools Page - Evaluation, Repair, and Transformation Tools for Web Content Accessibility: http://www.w3.org/WAI/ER/existingtools.html
W3C HTML Validator - The W3C HTML Validation Service checks HTML documents for conformance to W3C HTML and XHTML recommendations and other HTML standards: http://validator.w3.org/
CSS Validator - If you are using Cascading Style Sheets (CSS), then use the CSS Validator: http://jigsaw.w3.org/css-validator/
For more information, visit the W3C's Evaluation & Repairs Tools page: http://www.w3.org/TR/2000/WD-AERT-20000426
The Lynx Viewer generates an HTML page that indicates how much of the content of your page would be available to Lynx, which is a text-only browser. In addition to showing how useful a site would be for a visually-impaired person, it is also a good indicator for anyone with older technology, see http://www.delorie.com/web/lynxview.html
.