Before you perform the tasks described in this chapter, make sure you have already performed the setup steps described in Setting up Your Portal Development Environment. Also keep in mind that you must have the framework for your portal in place, including look and feel elements, any required CSS files, and so on, before you start building your portal.
This chapter includes the following sections:
When you create a portal, WebLogic Portal creates a portal file—an XML file with a .portal
file extension. The .portal
file is the central defining file of a portal, with references to all the major components of the portal: the desktops, books, pages, portlets, and so on.
This section includes the following topics:
To create a portal and its accompanying .portal
file, perform these steps:
WebContent
); right-click and then select New > Portal. The New Portal dialog displays, as shown in Figure 7-1.
Because you started this wizard by right-clicking the web content directory, the parent folder field automatically displays that directory name.
You must locate your portal file in a web content directory that is subordinate to the web project directory. The default web content directory name is WebContent
, and is assigned when you use the Portal Web Project Wizard. You can change the name of your web content directory if you wish; for more information, refer to New Portal Web Project - Web Module Dialog.
A file type of .portal
is required for portals; you can type the .portal
extension to the portal’s name if you wish, but WebLogic Portal automatically adds the extension if you don’t enter it.
The wizard adds the portal to the specified folder in the Portal Web Project and a view of the portal displays in the editor, as shown in Figure 7-2.
The created portal includes a desktop, header, footer, book, and page. A desktop is a user-specific view of the portal content. A portal can support many desktops. A single portal might support an employee-specific desktop, a customer-specific desktop, and others, where each desktop exposes different kinds of content to different sets of users. Any part of a portal can be included or excluded from a desktop, including a book, a page, a specific application, or an individual link.
Desktops can also define the look and feel attributes of a portal. Desktops can be associated with a particular skin that defines the color scheme, fonts, and images used. Desktops also contain a header and footer—you can place images, text, or any web content in these areas to give consistency to the look and feel of a desktop.
Typically, you use Workshop for WebLogic to develop a portal and its key components; then you use the WebLogic Portal Administration Console to create specific desktops using the portal as a template. For information about creating desktops in the next phase of development, refer to Managing Portal Desktops.
You use books to organize your content and navigation in a hierarchical manner. Books can contain other books or pages. In a browser, a book is rendered as a set of tabs or links. Each portal contains a main book called, by default, “Main Page Book.” A page consists of a set of columns and/or windows that organize the actual content of your portal. You navigate to a page by clicking on an individual tab or a link. You can create books and pages using either Workshop for WebLogic or the WebLogic Portal Administration Console.
This section describes how to add a second page to the portal’s main book. When the portal is rendered in a browser, the two pages will appear as two clickable tabs. You can add a new page using a few different methods; this description describes a drag and drop method.
Note: | The procedure for adding a book to a portal is almost identical to the procedure for adding a page. Rather than include both procedures here, we explain how to add a page and, where appropriate, highlight any differences between the two tasks. |
To add a page to a portal, perform these steps:
Tip: | If you do not see the Palette view, select Window > Show View > Design Palette. |
You can create a standalone book or page; when you do this, the book or page information is kept in a separate .book
or .page
file and is not embedded within the .portal
file. Standalone books and pages are very useful elements in your portal development environment. For example, in a team development environment, developers can create individual books or pages that can be managed separately and then added to the portal at a later time. Also, if you want to create books and pages that are accessible to remote consumer applications, you must create the book or page as a standalone .book
or .page
file using Workshop for WebLogic.
Note: | The procedure for creating a standalone book is almost identical to the procedure for creating a standalone page. Rather than explain both procedures here, we explain how to create a standalone page and, where appropriate, highlight any differences between the two procedures. |
To create a standalone page in a portal, perform these steps:
WebContent
) or to a folder within the web content folder.
You must locate books and pages in a web content directory or sub-directory that is subordinate to the web project directory. The default web content directory name is WebContent
, and is assigned when you use the Portal Web Project Wizard. You can change the name of your web content directory if you wish; for more information, refer to New Portal Web Project - Web Module Dialog.
In the New Page dialog, note that the parent folder auto-fills the path from which you started the wizard.
A file type of .page
is required for standalone pages (or .book
for standalone books); you can type the .page
extension if you wish, but WebLogic Portal automatically adds the extension if you don’t enter it.
The new page is added to the portal web project in the folder you specified, as shown in Figure 7-5.
In addition, the page opens in the editor, as shown in Figure 7-6.
You can extract an existing page and then re-use it in other portal applications within your web project. When you extract an existing page, all of its contents are extracted as well (portlets and so on).
To extract an existing page or book:
Use this selection to add a reference to an existing book or page, into a book or page in your portal.
To add a book or page reference from the Portal Editor:
An orange border appears around a selected element.
The Choose a Book dialog or Choose a Page dialog displays, as appropriate; all .book
/.page
files for the web project are listed.
Note: | The Insert menu option appears only when this selection is valid, depending on the selected portal element. |
.book
or .page
file, then click OK. The Workshop for WebLogic window updates, adding a Book (or Page) Content node in the Outline view and displaying the content properties in the Properties view.
To add a book or page reference from the Outline View:
The Choose a Book dialog or Choose a Page dialog displays, as appropriate; all .book
/.page
files for the web project are listed.
Note: | The Insert menu option appears only when this selection is valid, depending on the selected portal element. |
.book
or .page
file, then click OK. The Workshop for WebLogic window updates, adding a Book (or Page) Content node in the Outline view and displaying the content properties in the Properties view.
You can change the order of books and pages. For example, if the main page book contains a page and a book in the following order:
To change the order of books and pages, right-click the book or page that you want to move in the Outline view, and choose Move Up or Move Down. The book or page moves up or down in the Outline view, and the horizontal reordering occurs in the portal editor.
Rearranging books and pages does not rearrange them in any portal desktops that you already created with the WebLogic Portal Administration Console. For instructions on rearranging those books and pages, refer to Managing Portal Desktops.
Portal properties are named attributes of the portal that uniquely identify it and define its characteristics. Some properties—such as title and definition label—are required; many optional properties allow you to enable specific functions for the portal such as presentation properties, rollover images, and control tree optimization. The specific properties that you use for a portal vary depending on your expected use for that portal.
Each portal component includes a set of properties that are used to configure its behavior. For example, you can configure desktop properties that determine which look and feel the desktop uses, as well as the type of encoding used at runtime.
Portal properties include subsets of properties for the main components (books, pages, desktops and so on). The *.portal
file provides a complete view of these properties.
During the development phase of the portal life cycle, you generally edit portal properties using Workshop for WebLogic; this section describes properties that you can edit using Workshop for WebLogic.
During staging and production phases, you typically use the WebLogic Portal Administration Console to edit portal properties; only a subset of properties are editable at that point. For instructions on editing portal properties from the WebLogic Portal Administration Console, refer to Managing Portal Desktops.
This section contains the following topics:
When you click a border in the portal editor view, an orange outline appears around that section of the portal, and a related set of properties appears in the Properties view. The displayed properties vary according to the selected border in the view. Figure 7-7 shows the highlighted Header area and its related properties.
To edit portal properties, follow these steps:
.portal
file to open it in the editor. The displayed properties vary according to the active area that you select. If you click the outer (desktop) border, properties for the entire desktop appear; if you click inside a placeholder, properties for that placeholder appear, and so on.
If you hover the mouse over a property field, a description of that field displays in a popup window.
Values for some properties are not editable after you create the portal.
In some cases, from the property field you can view associated information pertaining to that property; for example, the Skeleton URI property provides an Open button to view the associated file. For more information about options available in the Properties view, refer to Tips for Using the Properties View.
The behavior of the Properties view varies depending on the type of field you are editing. The following tips might help you as you manipulate the content of the data fields in the Properties view.
.portal
file in the Package Explorer view and choose Edit with > XML Editor to open the file using the basic XML editor that Eclipse provides.Each component of your portal can have unique presentation properties. Table 7-1 describes presentation properties and their values.
Desktop properties allow you to determine how your portal desktop will behave. You can assign a backing file to your desktop as well as look and feel properties such as shell, title, and the look and feel you want the desktop to use. Table 7-2 describes desktop properties and their values
Two of the desktop properties are also important for performance: Tree Optimization and Asynchronous Mode. For more information about designing your portal for performance, see Designing Portals for Optimal Performance.
Asynchronous mode allows you to set the contents of a desktop to render asynchronously. When asynchronous mode is enabled, portal content (including individual portlets) displays when its individual rendering life cycle is complete.
|
||||
Set Disc Enabled to true to enable the Disc framework. Disc provides a client-side, JavaScript, object-oriented programming framework for handling events, making asynchronous portlet updates, and for accessing portal context objects. See the Client-Side Portal Developer’s Guide for detailed information on Disc.
|
||||
Set DVT Enabled to true to enable placeable movement (drag and drop) for the desktop. For more information, see Enabling Placeable Movement.
|
||||
Each component must have a unique identifier. A default value is entered automatically, but you can change the value. Definition labels can be used to navigate to books, pages, or portlets. Also, components must have definition labels for entitlements and delegated administration.
As a best practice, you should edit this value in Workshop for WebLogic to create a meaningful value. This is especially true when offering books, pages, or portlets remotely, as it makes it easier to identify them from the producer list.
|
||||
Select the encoding used to display the portal. The default is UTF-8. You can select a value using the drop-down menu, which provides five common IANA encoding selections, or you can type a value into the field. The values presented in the combobox are descriptive display names that are converted to actual IANA names when saved to the
.portal file.
You can enter a name from the extended encoding set as an IANA name, alias, or canonical name for the encoding. If you type in a value that does not appear in the drop-down menu, a validator checks the entry when you press Enter or click outside the field. If the encoding fails validation, a warning message displays; you can either change the value or accept it anyway. The value is stored as shown in the field, in the
.portal file.
|
||||
When portal users interact with scrollable pages, maintains browser focus on active portlet. This property is set to true by default.
|
||||
Using this function improves performance, especially for portals that have large control trees (books, pages, portlets). If this flag is set to
true , the portal framework generates a partial control tree rather than the full tree. Tree optimization causes slight changes in the behavior of the portal; do not use it without first performing a complete regression test on the portal. For more information, refer to Designing Portals for Optimal Performance.
|
You can assign a backing file to a book using book properties, as well as set up a page to use a theme file instead of the portal look and feel file. Book properties also include different presentation properties differ for books, see Table 7-3.
If you want to use a class for preprocessing (for example, authentication) prior to rendering the portlet, enter the fully qualified name of that class. That class must implement the interface com.bea.netuix.servlets.controls.content.backing.JspBacking or extend com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking.
|
||||
Each component must have a unique identifier. A default value is entered automatically, but you can change the value. Definition labels can be used to navigate to books, pages, or portlets. Also, components must have definition labels for entitlements and delegated administration.
As a best practice, you should edit this value in Workshop for WebLogic to create a meaningful value. This is especially true when offering books, pages, or portlets remotely, as it makes it easier to identify them from the producer list.
When you create a portal resource instance on a desktop in the WebLogic Portal Administration Console, the generated definition label is not editable.
About .book and .page definition labels: Avoid including multiple occurrences of the same .book or .page file (with the same definition label) within a portal. For example, if you use nested embeds of the same
.book or .page file within a portal, then rendering problems will occur due to the existence of duplicated definition labels.
|
||||
Because the specified path might not be relative to the project, the image file cannot be located by Workshop for WebLogic and is not rendered on book or page tabs in the portal editor. Image paths must be relative to the image search paths specified in the
skin.xml file associated with the selected look and feel.
|
||||
Select an image to override the icon that appears next to the book or page title. This image appears on the tab of selected pages.
Because the specified path might not be relative to the project, the image file cannot be located by Workshop for WebLogic and is not rendered on book or page tabs in the portal editor. Image paths must be relative to the image search paths specified in the skin.xml file associated with the selected look and feel.
|
||||
Select an image to override the icon that appears next to the book or page title. This image appears on the tab of unselected pages.
Because the specified path might not be relative to the project, the image file cannot be located by Workshop for WebLogic and is not rendered on book or page tabs in the portal editor. Image paths must be relative to the image search paths specified in the skin.xml file associated with the selected look and feel.
|
||||
For proper rendering, the class must exist in a cascading style sheet (CSS) file in the look and feel’s selected skin, and the skin’s
skin.xml file must reference the CSS file.
|
||||
|
||||
Select the default type of menu to use for navigation among books and pages. The dropdown menu displays these selections:
|
||||
Page properties allow you to configure properties for individual pages in your portal. The layout property determines how many placeholders the page has and their locations. Table 7-4 lists each page property.
Each component must have a unique identifier. A default value is entered automatically, but you can change the value. Definition labels can be used to navigate to books, pages, or portlets. Also, components must have definition labels for entitlements and delegated administration.
As a best practice, you should edit this value in Workshop for WebLogic to create a meaningful value. This is especially true when offering books, pages, or portlets remotely, as it makes it easier to identify them from the producer list.
When you create a portal resource instance on a desktop in the WebLogic Portal Administration Console, the generated definition label is not editable.
About .book and .page definition labels: Avoid including multiple occurrences of the same .book or .page file (with the same definition label) within a portal. For example, if you use nested embeds of the same
.book or .page file within a portal, then rendering problems will occur due to the existence of duplicated definition labels.
|
||||
Select the page layout style for positioning books and portlets in placeholders on a page. A dropdown menu provides the following selections:
For more information about layouts, see Working with Layouts
|
Placeholders are named sections within a page layout. By editing placeholder properties, you can modify a placeholder text flow, width, and so on. For more information about layouts, see Working with Layouts.
Table 7-5 lists placeholder properties.
If the Using Flow property is set to
true , this value can be vertical or horizontal . Flow determines whether books or portlets put in the placeholder are positioned on top of each other (vertical) or beside each other (horizontal). This value is read from the .layout file for the page's selected Layout Type.
|
You can override a resource in a shared J2EE library by copying the resource into your portal web project and then customizing it.
WARNING: | If you copy J2EE library resources into your project, keep in mind that with future updates to the WebLogic Portal product, you might have to perform manual steps in order to incorporate product changes that affect those resources. With any future patch installations, WebLogic Portal supports only configurations that do not have copied J2EE library resources in the project. |
To copy a J2EE library resource into your project, follow these steps:
Select Window > Show View > Merged Projects View.
The Merged Projects View is part of the default Portal Perspective, displaying in the same area as the Package Explorer view.
Italicized items in the Merged Projects View represent entities that are stored in shared J2EE libraries. All entities that are stored on your filesystem, such as any portal files that you create, are shown in regular type.
You can copy a single file, set of files, or an entire folder, to your project.
The resources are copied to the web content folder of your project, and reflect the hierarchy of their location in the J2EE library.
Note: | You can view a Properties dialog for a file in the Merged Projects View by right-clicking the file and selecting Properties. The dialog shows the J2EE library information for the file, including the J2EE library name and version. |
You can view local file overrides of J2EE library files in either of these ways:
The icon indicating J2EE library overrides is turned off by default, due to the processing time involved in updating the information, and the fact that using it causes the WebLogic Portal plugins to always load at startup.
To activate the library override marker icons, follow these steps:
WebLogic Portal provides custom Java controls—collections of actions (Java methods) that you can drag and drop into your page flows—to make development easier and more automated. You can add actions in a graphical interface and configure the actions with the Workshop for WebLogic editor, insulating you from working directly with Java code (although you can still work directly with the code in Source View). Even if you want to work directly with code, working initially with the graphical interface automates code entry and makes it more syntax error free.
For example, the custom controls provided with WebLogic Portal provide built-in forms on some methods. If you want an action that creates a user, you can use the createUser method in the User Provider control. If you add the createUser method into the control's action area, the control provides a CreateUserForm bean that can be added to a JSP and linked to the action automatically.
For information about creating page flows using Workshop for WebLogic, refer to the Oracle Workshop for WebLogic User’s Guide. For more information about the specific controls provided with WebLogic Portal, refer to the Javadoc.
The following sections provide more information about using controls provided by WebLogic Portal in page flows:
To add a control to a page flow:
.jpf
file) or create a new page flow. For information about creating page flows using Workshop for WebLogic, refer to the Oracle Workshop for WebLogic User’s Guide.
The Select Control dialog box displays, as shown in Figure 7-9.
All the methods in the control are now available to your page flow. For more information about portal controls, see the Javadoc.
You can add a method (action) to your page flow by dragging a method from the Page Flow Explorer view into the Flow View in the page flow editor, as shown in Figure 7-10.
Many portal framework controls have secured methods, meaning that any control attempting to execute such a method would need to be in an authorized security role. You can specify security roles in a page flow on each action. A user must be a member of the designated role(s) for the action to be fired. For example, the User Provider Control has a removeUser() action that requires the caller to be in the role of "Framework SystemAdministrator" or "Admin."
For user and group management actions, the roles you specify in the WebLogic Portal Administration Console Authentication Security Provider Service determine whether or not the user can perform the action.
You can add security roles to a domain using the WebLogic Server Administration Console.
You can deploy (publish) a portal to the server and view it in a browser window.
Note: | Opening the same portal desktop in multiple browser windows that share the same process (and, therefore, the same session) is not supported. For example, using the render:pageURL tag or the JavaScript window.open function to open a portal desktop in a new window is not supported and can result in unwanted side effects. For instance, if a portlet is deleted in the new window, and then the user tries to interact with that portlet in the main window, the interaction will fail. |
Note: | Due to a problem in Eclipse, some JSP tags are marked as containing an error when they are actually correct; although no error actually exists, Eclipse will not publish (deploy) the application. If this situation occurs, you must turn off JSP validation before publishing. Leave JSP validation on until you have fixed any problems except those caused by these tags; before deploying, select Window > Preferences, select Validation in the tree, and uncheck the JSP Syntax Validator check box. |
To deploy (publish) and view your portal project, follow these steps:
.portal
file for the portal in the Package Explorer view and select Run As > Run on Server, as shown in Figure 7-11. Note: | In many cases you are not required to redeploy a portal to see changes that you have made. For more information, refer to Running a Project on the Server. |
The Run On Server - Define a New Server dialog displays. Make sure the server that you want to use is highlighted.
Wait while Workshop for WebLogic starts the server, deploys files to the server, and runs the application. While deployment is in process, you can view status messages in the status bar at the bottom of the window.
The results appear in a new tab in the editor view, as shown in Figure 7-12.
Tip: | If you previously deployed a project of the same name and that project is in a different location, you need to undeploy that project from the server. To do this, double-click the server in the Servers view, and delete the appropriate portal web project (not the shared J2EE libraries) from the Published Modules list. For more information about this task, refer to the “Managing Servers” section of the Oracle Workshop for WebLogic Platform Programmer’s Guide. |
Tip: | You can choose to always use an external web browser to view your portal if you wish. To do so, select Window > Preferences and select General > Web Browser in the property tree; then select the Use external Web browser radio button. |
The following sections describe how to work with URLs in WebLogic Portal:
WebLogic Portal provides a convenient, extensible mechanism for creating URLs to your portal resources in a portal web project that can transfer from domain to domain without breaking, especially when server names and port numbers change. This URL-creation mechanism also lets you switch between secure and non-secure URLs (http and https).
The two pieces involved in creating portable URLs are:
The beehive-url-template-config.xml
file contains multiple URL “templates,” each with a unique name. Those template URLs contain variables such as url:domain
and url:port
that are read in from the active server. The <render:*Url>
JSP tags have a “template” attribute in which you can specify the name of a URL template in beehive-url-template-config.xml
.
Table 7-6 shows how the JSP tags use the templates to create URLs.
You can use any of the URL templates in beehive-url-template-config.xml
provided by WebLogic Portal, and you can add as many templates as you want into the file.
The following variables are available for use in URL template building:
{url:domain}
- Reads the name of the server from the current request.{url:port}
- Reads the listen port number of the server from the current request. (See Troubleshooting below.){url:securePort}
- Reads the SSL port number of the server from the current request. (See Troubleshooting below.){url:path}
- Reads the name of the web application. The URLs to all resources in a web application are relative to the web application directory. {url:queryString}
- Reads a queryString variable for the URL.{url:compression}
- Allows you to use the pluggable compression mechanism to create shorter, more readable, URLs. For details, refer to URL Compression. URL strings can take up a large percentage of the response HTML. WebLogic Portal’s URL compression mechanism provides a pluggable means of creating shorter URLs. For example:
Before implementing URL compression, a URL would look like this:
http://abc.com/webapp/portletEvents/activatePage/activatePage.portal?_nfpb=true&_windowLabel=pfTPC_source_1&pfTPC_source_1_actionOverride=%2FportletEvents%2FactivatePage%2FtoPage1
After implementing URL compression, a URL would look like this:
WebLogic Portal implements URL compression by mapping strings to the database. You set up URL compression using a web application-level setting; processing is invoked through the GenericURL
class.
The default algorithm uses two of the p13n caches for the mapping - wlp.urlCompression.compressed and wlp.urlCompression.expanded - which are located in p13n-cache-config.xml
in the framework-full-app
library module.
To configure a webapp to use url compression, follow these steps:
web.xml
; for example
<servlet>
<servlet-name>UrlCompressionServlet</servlet-name>
<servlet-class>com.bea.portlet.compression.UrlCompressionServlet
</servlet-class>
<init-param>
<param-name>defaultPage</param-name>
<param-value>/index.jsp</param-value>
</init-param>
<init-param>
<param-name>errorPage</param-name>
<param-value>/errors/error.jsp</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>UrlCompressionServlet</servlet-name>
<url-pattern>wlp.c</url-pattern>
</servlet-mapping>
{url:compression}
to the templates for which you want to apply compression.The following sections describe some special considerations to keep in mind as you implement URL compression.
URL compression interferes with some of the AJAX-specific mechanisms for page refreshes that are associated with asynchronous portlet rendering. Because of this, URL compression must be disabled whenever asynchronous content rendering is disabled to force page refreshes. WebLogic Portal disables URL compression automatically except when file upload forms are used; in this situation, you must explicitly disable it. For instructions, refer to the Portlet Development Guide.
A successful implementation of URL compression depends on portal developers following best practices and using supported URL tags and classes to generate URLs.
An off-site URL is a URL to a resource that is not hosted in the web application of the code generating the URL. In a web application that has compression enabled, you must specify a URL template with compression disabled when using GenericURL, its subtypes, or the corresponding JSP tags to generate off-site URLs.
Use the following code fragment as a guide:
GenericURL redirectURL = GenericURL.createGenericURL(request, response); redirectURL.setDomain("www.yahoo.com"); redirectURL.setPort(80); redirectURL.setPath("/compressedUrl/index.html"); redirectURL.setTemplate("no_compression_template");
where "no_compression_template" is the name of a URL template that excludes the {url:compression}
pseudo-token.
When reference freqently-accessed URLs in your code, it is a best practice to turn off URL compression. When URL compression is enabled, a new database entry is created each time the URL is accessed. For frequently accessed URLs, this could could create performance issues.
To disable URL compression on a per URL basis in your page flows or JSPs, you need to add a no compression template to your WEB-INF/beehive-url-template-config.xml file. You can then reference this template in your code.
For example, the following JSP results in increased entries in the database. Every time this JSP is rendered a new entry is created in the database regardless of whether or not the link is ever pushed.
<%
String value = String.valueOf(System.currentTimeMillis());
%>
<render:postbackUrl var="url">
<render:param name="name" value="hello" />
<render:param name="value" value="<%=value%>" />
</render:postbackUrl>
<a href="${url}">Post current time</a> url:${url}<p/>
To remedy the situation, you should add a new template to the WEB-INf/beehive-url-template-config.xml
that does not use URL compression, as shown in Listing 7-2.
<url-template>
<name>defaultNoCompression</name>
<value>{url:scheme}://{url:domain}:{url:port}/{url:path}?{url:queryString}{url:currentPage}</value>
</url-template>
After adding the no compression template, you then add the template to the postbackURL within the JSP, as shown in Listing 7-3. Using this example, the URL will not be compressed.
<render:postbackUrl var="noCompressionUrl" template="defaultNoCompression">
<render:param name="name" value="hello" />
<render:param name="value" value="<%=value%>" />
</render:postbackUrl>
<a href="${noCompressionUrl}">Post current time</a> url:${noCompressionUrl}
If you are using a proxy server or switching back and forth between non-secure and secure ports, you might find that URLs do not resolve if you use the {url:port} or {url:securePort} variables. This is because the variables for those values are read from the request. For example, if a user in a non-secure port (port number 80) clicks a secure https link that was created with a URL template that uses the {url:securePort} variable, the port number of the request (80) is used for the {url:securePort} variable, which would create a secure request (https) on an non-secure port. The same could happen if a user on a proxy server (port 80) clicks a link to a resource outside the proxy server (port 443).
In both of those cases, you need to hard code port numbers in the URL templates to get URLs to resolve correctly.
The beehive-url-template-config.xml file is automatically included (through a J2EE Shared Library) in all portal web projects. This file contains URL templates that are required to support URL rewriting in consumers. If you intend to use a web application as a WSRP producer, do not remove these URL templates and variables from the beehive-url-template-config.xml file.
WebLogic Portal uses the Beehive configuration file beehive-url-template-config.xml
for configuring the form of WebLogic Portal-generated URLs. The Beehive configuration element for using ampersand entities (&
) or ampersand characters (&
) is located in the NetUI configuration file beehive-netui-config.xml
. In an HTML configuration, the default is to generate URLs with ampersand entities, in the absence of a configuration element specifying the use of ampersand characters.
XHTML configurations force ampersand entities in URLs regardless of the configuration setting.
You can manually override the configuration setting using the useAmpEntity
method and the setForcedAmpForm
method in the GenericURL
class. For more information about these methods, refer to the Javadoc.
For a discussion of how previous releases of WebLogic Portal handled ampersands in URLs, refer to Ampersand Entities in Portal URLs in the WebLogic Portal Upgrade Guide.
The WebLogic Portal look and feel uses ResourceURLs (and thus, URL rewriters) for resource (CSS, Javascript, images, and so on) paths under two conditions:
URL templates that are specific to look and feel resources may be specified in a reference group named "lookandfeel-url-templates." This group is expected to contain one or both of the following keys: "laf-resource" and "window-resource". The "laf-resource" key is used for resources related to a skin or skeleton; the "window-resource" key is used for resources related to window dependencies. The resolved (relative) resource path will be used to replace the "{url:path}
" parameter in the corresponding URL template. The following portion of the beehive-url-template-config.xml
file shows the syntax of an example URL template:
<url-template>
<name>laf-resource-template</name>
<value>http://my.domain.com/resources/laf/{url:path}</value>
</url-template>
<url-template-ref-group>
<name>lookandfeel-url-templates</name>
<url-template-ref>
<key>laf-resource</key>
<template-name>laf-resource-template</template-name>
</url-template-ref>
</url-template-ref-group>
In the absence of the look and feel URL templates, look and feel resource paths will remain relative, with one exception: when generated within the context of a remote portlet, such paths will use the standard "resource" URL template.
The optional LookAndFeel URL templates can be used to "offload" resources to a different server. However, such resources MUST be copied (not moved) and be resolvable using URLs with the same relative resource path as the Portal Web Application (for example, .../framework/skins/bighorn/css/book.css
). Look and feel path resolution continues to rely on local file system access to resources.
The GetSkinPath tag in the render taglib will not be influenced by the optional look and feel URL templates. Paths produced by this tag will be relative in all cases.
This section describes how the encoding is set on the HTTP response.
WebLogic Portal uses the following method of setting encoding based on the information in the .portal
file:
netuix:desktop
element for an encoding
attribute and use that value if present..portal
file for the directive.page
element. Note that this mechanism is deprecated. If that element is present, pick up the encoding from an attribute there.netuix-config.xml
for a <defaultEncoding>
element, and use the encoding
attribute there.<encoding>
element in the <jsp-descriptor>
section of the weblogic.xml
file. For more information on <jsp-descriptor>
element, see
weblogic.xml Deployment Descriptor Elements on e-docs. This implementation differs from that of previous versions of WebLogic Portal. For more information, refer to the “Functional Changes” appendix of the Upgrade Guide.
The following examples show how to use the encoding settings.
<netuix:desktop ... encoding="UTF-8" />
in your .portal
file
<defaultEncoding encoding="UTF-8" />
in your netuix-config.xml
file
If configured properly, caches can vastly reduce the time needed to retrieve frequently used data. You can use Workshop for WebLogic to change settings for the current running instance of existing caches, or to flush caches. When you configure a cache, you modify its parameters to change its behavior or capacity. For example, you can set up a cache to hold only the most recent 200 entries and set the amount of time (in milliseconds) to remain in the cache. You can also flush a cache so that all new requests for information come from the database.
You cannot add a new cache using the Workshop for WebLogic user interface. However, you can add a cache by manually editing the META-INF/p13n-content-config.xml
cache configuration file in the in the content directory (named EarContent
by default) of the EAR project. You can also copy a cache file from the Merged Project view into your project if desired.
The cache changes that you make using Workshop for WebLogic are not persisted and will be lost the next time you publish the application or restart the server. To make persistent changes, use the WebLogic Portal Administration Console.
Caches are read-only and cluster-aware.
Note: | Before you can perform the steps in this section, your server must be running. |
To change cache settings in Workshop for WebLogic:
The Portal Cache Manager dialog displays, including a list of the current “live” caches. The caches displayed in this dialog comprise a superset of the caches that you can display in the Administration Console; the list in the Portal Cache Manager dialog includes the configured caches as well as caches that are triggered dynamically based on the processes that you are using in your portal.
Use the table below as a guide to the settings that you can change:
For detailed descriptions of each cache, refer to the documentation for the specific feature that is related to that cache. For example, personalization-related caches are described in the Interaction Management Guide.
If you are running your portal application on a Managed Server, you can improve the performance of the WebLogic Server Administration Console by using the <context-param> parameter in the web.xml
file, as shown in this example:
<context-param>
<param-name>portalFileDirectory</param-name>
<param-value>/</param-value>
</context-param>
This parameter takes advantage of an optimized call that returns EAR content information. Without this parameter, the call recursively searches for .portal
files. If you use this parameter, you must place all of the .portal
files in the same directory under the portal web application. Use the <param-value>
to specify the directory. In the example above, all .portal
files reside in the web application’s root directory (/
).
When a Book's 'Return To Default Page' attribute is set to true, the portal should display the Book's default page when the book is the target of a navigation URL. The behavior might not be what you expect. The purpose of this section is to clarify the behavior.
This section addresses the nesting of books where the immediate children of the Main Book are books and the return to default only applies when moving between books, not within books. Here is a simple portal hierarchy where each page has a portlet that contains a URL to Book2.
Main Book - Book 2 is the default book for the main book
Book 2 - Return To Default = true with default page = Page 2
When the above portal is rendered, Book 2 and Page 2 are displayed.
This works as expected as Page 2 is the default for Book 2 and the last active page in Book2 was Page 3.
When the above portal is rendered, Book 2 and Page 2 are displayed.
The reason for this is because Page 3 is within the same book and therefore, the return to default is not applied.
In the following hierarchy where pages are the children of the main book, the Return to Default feature does not apply.
Main Book - Page 1 is the default page for the main book
Book 2 - Return To Default = true with default page = Page 2
Using the above hierarchy, the user is returned to the last active page in Book 2.
If you created a portal EAR project or portal web project without adding commerce-related features, you can enable them later by adding the commerce-related facets to your project.
Note: | The commerce API and library modules are deprecated with WebLogic Portal 10.0. |
The J2EE shared libraries directly associated with commerce functionality are listed in Table 7-8:
To add commerce functionality to your portal application, follow these steps:
The commerce facet is shown in Figure 7-13:
The commerce facet is shown in Figure 7-14:
For technical details on Commerce Services, see the
Javadoc for the packages com.bea.commerce.*
and com.beasys.commerce.*
.
Note: | The commerce API is deprecated with WebLogic Portal 10.0. |
Workshop for WebLogic displays error, warning, and informational messages in the Problems view. The WebLogic Portal validation framework is built upon the Web Standard Tools framework of the Eclipse platform.
You can enable or disable validation globally in Workshop for WebLogic or on a per-project basis.
To enable or disable validation for all projects in a workspace, do the following:
The Validation dialog is shown in Figure 7-15.
To enable or disable validation for a project, do the following:
You can the way the severity of errors, warnings, and informational messages are mapped and reported in Workshop for WebLogic. This section explains how to customize validation mappings globally and per project.
The main areas of portal code that are checked by the WebLogic Portal validation framework include the following:
Ordinarily, when errors occur in a project, Workshop for WebLogic prevents you from deploying your application. In some cases, you might want to ignore such problems and deploy the application anyway. Or, you might have a policy whereby warnings are not allowed in a deployed application. In these cases, you can choose to flag the warnings as errors to prevent deployment. Although you cannot enable or disable specific problem-related messages, you can modify way the severity of types of problems are mapped and reported.
To customize validation for all projects in your workspace, do the following:
Tip: | Select the Verify related files on incremental builds check box to allow related files to be validated when an incremental build is performed. This feature is useful if you happen to copy a portal resource, such as a book within a portal web application. You will see validation errors related to duplicate definition labels reported on both the original and duplicate file. If you change the duplicate definition labels, only the changed file is validated on incremental builds: the validation errors remain for the original file. If you select Verify related files on incremental builds, both the newly changed and original file are validated and the validation errors on the original file are cleared. |
To customize validation for all projects for specific projects, do the following:
Note: | Project-level settings take precedence over global settings. |
You can enable a portal so that users can drag and drop individual portlets or books (placeables) on a page. This feature, called placeable movement, provides a convenient way for users to customize the location of content on their portal desktop.
Tip: | Placeable movement relies on the WLP REST API, which enables clients to dynamically retrieve, modify, and update portal data. See the Client Development Guide for more information about the REST API. |
Enabling placeable movement is a two-step process:
Note: | Only authenticated users can use placeable movement. Typically, you provide a login portlet to satisfy this requirement. See the Security Guide for more information. |
After you have created a portal with placeable movement enabled you need to use the Portal Administration Console to create a desktop using the .portal file as a template. After you complete this task, you can then open the desktop and test placeable movement.
The new portlet placement is automatically communicated to the server and stored. Whenever the user revisits the page, the new portlet arrangement is retained.
You can also enable placeable movement for an existing desktop using the Administration Console. See Desktops.
This section includes these topics:
Custom layouts offer you flexibility when designing portal pages. Oracle provides limited support for using placeable movement with custom layouts. Because the placeable movement feature is closely coupled to page layout, you must follow certain rules and patterns when writing custom layouts that use placeable movement. These rules and patterns are described in this section. For basic information on custom layouts, see Creating a Custom Layout.
Note: | Oracle recommends that you use the standard flow layouts with placeable movement whenever possible. Follow the rules in this section only if you want to write a custom layout that uses placeable movement. |
To use placeable movement with custom layouts, you must install patches for Bug 8793111 and Bug 8491408. Contact customer support for details about installing these patches.
Note: | If you find a bug that you suspect involves a custom layout, you must reproduce it with the sample custom layout and you must follow the requirements described in this section before contacting support. |
To use placeable movement with custom layouts, follow these rules:
Note: | This section assumes you are familiar with WebLogic Portal Look and Feels. To review this topic, see User Interface Development with Look And Feel Features. |
<netuix:flowLayout>
<div>
tags that use Weblogic Portal <skeleton:control>
tags to enclose <skeleton:child>
tags.Note: | The default skeleton JSP flowlayout.jsp (the standard skeleton JSP for a flow layout when no other skeleton JSP is specified) follows a consistent HTML rendering pattern that is required for DND to work properly. You can find the complete flowlayout.jsp file in the Merged Project view in the portal web application at /framework/skeletons/bighorn/flowlayout.jsp . Do not change this file; use it as an example only. |
<skeleton:context type="flowlayoutpc"> //presentation context
<skeleton:control name="div" presentationContext="${flowlayoutpc}" class="wlp-bighorn-layout" >
<c:set var="ph" value="${flowlayoutpc.placeholders}" />
<c:set var="placeholder1" value="${ph[0]}" /> //example placeholder declaration
<skeleton:control name="div" presentationContext="${placeholder1}" presentationClass="wlp-bighorn-layout-cell wlp-bighorn-layout-flow-horizontal" presentationStyle="width: 70%;">
<skeleton:child presentationContext="${placeholder1}"/>
</skeleton:control> //correct wrapping of the placeholder control and child
</skeleton:control>
</skeleton:context>
/framework/skeletons/bighorn/css/layout.css
. These classes are not required but, Oracle recommends that you use them as a guide to create custom CSS attributes. For example, to make <div>
elements appear side-by-side, the wlp-bighorn-layout-flow-horizontal
style can be applied. This style adds the “float: left;" attribute, which may be necessary for certain custom layouts. Other styles include min-height, overflow, and so on.horizontal
in the .layout
file. These placeholders cannot be registered as drop targets. Portlets cannot be dragged from or dropped into a placeholder with this setting.ScrollToWindow
to false. <netui:html>
, <head>
, <netui:base/>
, and <netui:body>
. For more information, see “
Portlets and Page Flow: Tags To Avoid When Combining These Technologies” at http://blogs.oracle.com/gmurnock/2008/09/portlets_and_page_flow_tags_to_1.html.
This section lists sample files that illustrate the correct way to implement placeable movement with a custom layout following the rules and patterns described previously. Listing 7-5 is a sample .layout
file. Listing 7-6 is a sample layout JSP file. Listing 7-7 is a sample layout HTML file. See also Creating a Custom Layout. The code also references custom_layout.gif
, the image file shown in Figure 7-20.
<?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:flowLayout markupType="Layout"
markupName="DNDcustom_layout"
title="DND custom layout"
orientation="horizontal"
description="Example custom layout DND compatible"
skeletonUri="/framework/markup/layout/custom_layout.jsp"
htmlLayoutUri="/framework/markup/layout/custom_layout.html.txt"
iconUri="/framework/markup/layout/custom_layout.gif"
thumbnailUri="/framework/markup/layout/custom_layout.gif" >
<netuix:placeholder markupType="Placeholder"
markupName="top_left_span"
title="topleftspan"
usingFlow="false"
description="top left placeholder spanning 2 columns">
</netuix:placeholder>
<netuix:placeholder markupType="Placeholder"
markupName="top_right"
title="topright"
usingFlow="false"
description="top right placeholder" >
</netuix:placeholder>
<netuix:placeholder markupType="Placeholder"
markupName="lower_left"
title="lowerleft"
usingFlow="false"
description="lower left placeholder in second row">
</netuix:placeholder>
<netuix:placeholder markupType="Placeholder"
markupName="lower_middle"
title="lowermid"
usingFlow="false"
description="mid placeholder in second row">
</netuix:placeholder>
<netuix:placeholder markupType="Placeholder"
markupName="lower_right"
title="lowerright"
usingFlow="false"
description="lower right placeholder in second row" >
</netuix:placeholder>
</netuix:flowLayout>
</netuix:markup>
</netuix:markupDefinition>
<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="flowlayoutpc">
<skeleton:control name="div" presentationContext="${flowlayoutpc}" class="wlp-bighorn-layout wlp-bighorn-layout-flow" cellspacing="0"
cellpadding="0" width="100%">
<c:set var="ph" value="${flowlayoutpc.placeholders}" />
<c:set var="topleft" value="${ph[0]}" />
<c:set var="topright" value="${ph[1]}" />
<c:set var="lowerleft" value="${ph[2]}" />
<c:set var="lowermid" value="${ph[3]}" />
<c:set var="lowerright" value="${ph[4]}" />
<div style="width: 70%; float: left" >
<skeleton:control name="div" presentationContext="${topleft}" presentationClass="wlp-bighorn-layout-cell">
<skeleton:child presentationContext="${topleft}" />
</skeleton:control>
<skeleton:control name="div" presentationContext="${lowerleft}" presentationStyle="width: 40%;"
presentationClass="wlp-bighorn-layout-cell wlp-bighorn-layout-flow-horizontal">
<skeleton:child presentationContext="${lowerleft}" />
</skeleton:control>
<skeleton:control name="div" presentationContext="${lowermid}" presentationStyle="width: 60%;"
presentationClass="wlp-bighorn-layout-cell wlp-bighorn-layout-flow-horizontal">
<skeleton:child presentationContext="${lowermid}" />
</skeleton:control>
</div>
<div style="width: 30%; float:left">
<skeleton:control name="div" presentationContext="${topright}" presentationClass="wlp-bighorn-layout-cell"
presentationStyle="width: 100%;">
<skeleton:child presentationContext="${topright}" />
</skeleton:control>
<skeleton:control name="div" presentationContext="${lowerright}" presentationClass="wlp-bighorn-layout-cell"
presentationStyle="width: 100%;">
<skeleton:child presentationContext="${lowerright}" />
</skeleton:control>
</div>
</skeleton:control>
</skeleton:context>
</jsp:root>
<table class="portalLayout" id="customPortalLayout" width="100%" height="100%">
<tr>
<td class="placeholderTD" valign="top" colspan="2" width="70%">
<placeholder number="0" />
</td>
<td class="placeholderTD" valign="top "width="30%">
<placeholder number="1" />
</td>
</tr>
<tr>
<td class="placeholderTD" valign="top" width="30%">
<placeholder number="2" />
</td>
<td class="placeholderTD" valign="top" width="40%">
<placeholder number="3" />
</td>
<td class="placeholderTD" valign="top "width="30%">
<placeholder number="4" />
</td>
</tr>
</table>
You can localize the title of a file-based book, page, or portlet by specifying a localized resource bundle in the .portlet
, .page
, or .book
file. For instance, to localize the title of a page, modify the .page
file as follows:
titleKey
and localizationBundle
attributes. Note that the titleKey
attribute value will be substituted for the title
attribute for the specified locale. The localizationBundle
value identifies the resource bundle.
For example, assume that you have the a resource bundle myresources/PageBundle
, where the directory that contains myresources
is in the Java CLASSPATH for the web application:
<netuix:page
definitionLabel="page2"
...
title="Default Title: Will Not Display When Localized Text Is Substituted"
titleKey="page2.title.key"
localizationBundle="myresources.
PageBundle"
...
myresources/PageBundle_<locale
>.properties
where <locale
> is the language code, for example, PageBundle_fr.properties
for a French translation.
page2.title.key=This is my Localized Title
. Follow the same procedure to localize portlets and books.
Note: | This procedure is only used for localizing the title attribute of file-based (non-streaming) portal resources. To localize a portlet in a portal desktop that is managed by the Administration Console (sometimes called a “streaming portal”), see Localizing a Portal Resource. |