|
|
This chapter describes the most common ways to create portlets, including the Portlet Wizard and the use of out-of-the-box portlets. This chapter also contains instructions for building each type of portlet that is supported by WebLogic Portal.
Before you begin, be sure you are familiar with the concepts associated with creating portlets, as described in Understanding Portlet Development.
This chapter contains the following sections:
The following portlet types are supported by WebLogic Portal:
For a detailed discussion of each portlet type, refer to Portlet Types.
You can copy portlets or other resources from a library module into your portal application and modify them as needed. A portlet existing in your project will supersede a portlet of the same name in a library module. To see a list of available portlets, you can use the Merged Projects View of the workbench; resources contained in library modules are shown in italic print. You can expand the tree to see the resources that are stored in the various modules. For a reference list of all the library modules and their locations on your file system, you can select Window > Preferences > WebLogic > Library Modules.
After you locate a portlet that you want to use, you can right-click the portlet in the Merged Projects View and select the Copy to Project option. Figure 5-1 shows an example of a library module portlet in the Merged Projects view with the Copy to Project option selected.
| Caution: | Portlets that are part of the GroupSpace sample application cannot be used in a non-GroupSpace-enabled application. |
| Caution: | 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. |
For more information about library modules, refer to the Portal Development Guide.
An important tool that you can use to create portlets from scratch is the WebLogic Portal Portlet Wizard. The following sections describe the Portlet Wizard in detail:
In general, you choose the portlet type on the first dialog of the wizard; when generating a portlet based on an existing resource, the Portlet Wizard automatically detects the portlet type whenever possible.
This section provides an overview of the two methods you can use to begin creating a portlet—creating the portlet resource information/file first or creating the portlet itself first.
You might already have a JSP file, for example, that you want to use as the basis for a portlet. (In addition to JSP files, you can drag other resources onto the portal (such as content selectors) to automatically start the portlet wizard.)
If you have an existing resource that you want to use as the basis of a portlet, follow these steps:
.portal file in Workshop for WebLogic. Workshop for WebLogic prompts you with a dialog similar to the example in Figure 5-2.
If you click Yes, the Portlet Wizard uses information from the resource file to begin the process of creating a portlet, and displays the Portlet Details dialog. Figure 5-3 shows an example:
If you do not have an existing source file to start with, you can create the portlet using the New Portlet dialog and the Portlet Wizard. To do so, right-click a folder in your portal web project and select New > Portlet. Figure 5-4 shows an example of the New Portlet dialog.
After you confirm or change the parent folder, name the portlet, and click Finish, the Portlet Wizard begins and displays the Select Portlet Type dialog. Figure 5-5 shows an example dialog.
Detailed instructions for creating each type of portlet are contained in How to Build Each Type of Portlet.
Workshop for WebLogic invokes the Portlet Wizard any time you perform one of these operations:
portal file is open in the editor view of the workbench.) Workshop for WebLogic prompts you with a dialog similar to the example in Figure 5-6.If you click Yes, the Portlet Wizard uses information from the resource file to begin the process of creating a portlet.
When you use File > New > Portlet to create a new portlet, a New Portlet dialog displays before the Portlet Wizard begins. Figure 5-4 shows an example of the New Portlet dialog.
The parent folder defaults to the location from which you selected to add the portlet.
This dialog requires that you select a project and directory for the new portlet, and provide a portlet file name. (The file name appears in the Package Explorer view after you create the portlet.) The Finish button is initially disabled; the button enables when you select a valid project/directory and portlet name. If you select an invalid portal project in the folder tree on this dialog, an error message appears in the status area near the top of the dialog explaining that the project is not a valid portal project. You cannot continue until you have selected a valid project (if one is available).
| Note: | With WebLogic Portal Version 9.2, the option to convert a non-portal project to a portal project is not offered. For information on how to integrate portal library modules into an already existing project, see the Portal Development Guide. |
When the Portlet Wizard starts, it determines the valid portlet types to offer on the Select Portlet Type dialog, based on the type of project that you are working in.
For example, if you are working within a Portal Web Project that has only the WSRP-Producer feature (and its required accompanying features) installed, it does not have the full set of portal libraries. In this case, only the JPF, JSF, Browser, and Struts portlet types are valid selections; the other portlet types are not included in the Select Portlet Type dialog.
If no valid portlet types exist based on the project type, an informational message displays.
Figure 5-8 shows an example of the Select Portlet Type dialog.
The Portlet Details dialogs that display after you select a portlet type vary according to the type of portlet you are creating. The portlet-building tasks that are described in How to Build Each Type of Portlet contain detailed information about each data entry field of the portlet details dialogs.
The following sections describe how to create each type of portlet supported by WebLogic Portal:
JSP portlets are very similar to simple JSP files. In most cases you can use existing JSP files to build portlets from them. JSP portlets are recommended when the portlet is simple and doesn't require the implementation of complex business logic. Also, JSP portlets are ideally suited for single page portlets.
There are several ways to invoke the Portlet Wizard, as explained in the section Starting the Portlet Wizard. This description assumes that you create a portlet based on an existing JSP file.
To create a JSP portlet, follow these steps:
The Portlet Wizard displays the Portlet Details dialog; Figure 5-9 shows an example.
Select the desired check boxes to allow the user to minimize, maximize, float, or delete the portlet. For a more detailed description of portlet states, refer to Portlet States.
|
|
|
To enable an option, select the desired check box and provide the path to the JSP page that will provide the appropriate function. For a more detailed description of portlet modes, refer to Portlet Modes.
|
The Workshop for WebLogic window updates, adding the Portlet_Name.portlet file to the display tree; by default, Workshop for WebLogic places the portlet file in the same directory as the content file.
Java portlets are based on the JSR 168 specification that establishes rules for portlet portability. Java portlets are intended for software companies and other enterprises that are concerned with portability across multiple portlet containers.
WebLogic Portal provides capabilities for Java portlets beyond those listed in the JSR168 spec. For example, you can set threading options, use a backing file, and so on. To implement these additional features, WebLogic Portal uses a combination of the typical .portlet file—which you create in the same way that you create other portlet types—as well as the standard portlet.xml file and the weblogic-portlet.xml file.
To create a Java portlet, follow these steps:
The New Portlet dialog displays.
The Portlet Wizard displays the Select Portlet Type dialog.
The Java Portlet Details dialog displays. Figure 5-10 shows an example.
portlet.xml file) by selecting the appropriate radio button. If you are creating a new portlet, WebLogic Portal uses the information that you enter in the wizard to perform these two tasks:
.portlet fileportlet.xml file (if this is the first Java portlet that you are creating in the project), or add an entry in the portlet.xml file, which is located in the WEB-INF directory.
If you choose to refer to an existing portlet in the wizard, the wizard displays a selection for every entry in the portlet.xml file, allowing you to create a new .portlet file and associate it with an existing entry in the portlet.xml file.
Based on these values that you entered, the Wizard creates a .portlet file, and adds an entry to /WEB-INF/portlet.xml, if it already exists, or creates the file if needed.
Workshop for WebLogic displays the newly created portlet and its current properties. Figure 5-11 shows an example of a Java portlet's appearance and properties.
The portlet-name attribute in the portlet.xml file matches the definitionLabel property in the .portlet file.
After you create the portlet, you can modify its properties in the Properties view, or double-click the portlet in the editor to view and edit the generated Java class.
| Note: | If you delete a .portlet file, the corresponding entry remains in the portlet.xml file. You might want to clean up the portlet.xml file periodically; these extra entries do not cause problems when running the portal but do result in error messages in the log file. |
The separate portlet.xml deployment descriptor file for Java portlets is located in the WEB-INF directory. In addition, the weblogic-portlet.xml file is an optional BEA-specific file that you can use to inject some additional features.
Listing 5-1 shows an example of how entries might look in the portlet.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<portlet-app version="1.0"
xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<portlet>
<description>Description goes here</description>
<portlet-name>helloWorld</portlet-name>
<portlet-class>aJavaPortlet.HelloWorld</portlet-class>
<portlet-info><title>Hello World!</title></portlet-info>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<portlet-info><title>new Java Portlet</title></portlet-info>
</portlet>
</portlet-app>
WebLogic Portal produces Java portlets that conform to the JSR 168 specification and can be used universally across operating systems. To package a Java portlet that you created using WebLogic Portal, use your desired packaging/archiving tool (such as the File > Export > WAR file feature in Workshop for WebLogic) to create a standard WAR file that contains the portlet.xml file, portlet .class file, and any other files the portlet needs to function. Keep in mind that these required files might include Java classes from non-WebLogic Portal JARs, any non-BEA EJBs from the application, JSPs or HTML files to handle rendering, and so on.
WebLogic Portal allows you to add more functionality to java portlets than you can obtain using the standard JSR 168 specification. You can use the optional weblogic-portlet.xml file to inject some additional features. The following sections provide some examples.
If you want to create a floatable Java portlet, you can do so by declaring a custom state in weblogic-portlet.xml as shown in the following example code:
<portlet-name>fooPortlet</portlet-name>
<mime-type>text/html</mime-type>
To add an icon to a Java portlet, you need to edit the weblogic-portlet.xml file, as described in this section.
weblogic-portlet.xml file to open it. This file is located in the portal's WEB-INF folder, for example:
myPortal/WEB-INF/weblogic-portlet.xml
weblogic-portlet.xml file: <portlet>
<portlet-name>myPortlet</portlet-name>
<supports>
<mime-type>text/html</mime-type>
<titlebar-presentation>
<icon-url>myIcon.gif</icon-url>
</titlebar-presentation>
</supports>
</portlet>
You can use the Portlet Wizard to built a portlet that uses Apache Beehive Page Flows to retrieve its content.
To create a page flow portlet, follow these steps:
The New Portlet dialog displays.
The Portlet Wizard displays the Select Portlet Type dialog.
The Portlet Wizard displays the Portlet Details dialog; Figure 5-12 shows an example.
The Page Flow Request URI. You can type a value here, or click the Browse button
 to open a class picker and select the appropriate class.
If you use the class picker to choose a page flow class, this fully-qualified class name is converted to a URI path of a JPF. The JPF does not reside in the project, but is referred to by the
.portlet file when the portlet is created.
If you enter or navigate to a
.jpf that has no corresponding class in the project or library modules, the Portlet Wizard creates the .java file for the page flow. If multiple project source directories exist, then the wizard prompts you to store the new .java file in the source directory of your choice. The .java template refers to a .jpf that is also created as part of this operation. The .jpf is created in the web content directory using the same directory structure as the package name of the new page flow class.
|
|
Select the desired check boxes to allow the user to minimize, maximize, float, or delete the portlet. For a more detailed description of portlet states, refer to Portlet States.
|
|
|
To enable an option, select the desired check box and provide the path to the JSP page or page flow that will provide the appropriate function. For a more detailed description of portlet modes, refer to Portlet Modes.
|
The Workshop for WebLogic window updates, adding the Portlet_Name.portlet file to the display tree; by default, Workshop for WebLogic places the portlet file in the same directory as the content file.
In order to fully understand the process of creating a page flow portlet, you should be familiar with the concept of Page Flows. For more information on using page flows with WebLogic Portal, refer to the Portal Development Guide.
If you want to create a page flow portlet that calls a web service, refer to Web Service Portlets.
You can create JSF portlets for a WSRP producer or a framework web application that has the JSF facet installed (that is, you selected the JSF facet when you created the portal web project).
To create a JSF portlet, follow these steps:
The New Portlet dialog displays. Figure 5-15 shows an example of the New Portlet dialog.
The parent folder defaults to the location from which you selected to add the portlet.
The Finish button is initially disabled; the button enables when you select a valid parent folder and portlet name. If you select an invalid portal project in the folder tree on this dialog, an error message appears in the status area near the top of the dialog explaining that the project is not a valid portal project.
The Portlet Wizard displays the Select Portlet Type dialog.
The Portlet Wizard displays the Portlet Details dialog; Figure 5-14 shows an example.
|
|||
Select the desired check boxes to allow the user to minimize, maximize, float, or delete the portlet. For a more detailed description of portlet states, refer to Portlet States.
|
|||
|
To enable an option, select the desired check box and provide the path to the file that will provide the appropriate function. For a more detailed description of portlet modes, refer to Portlet Modes.
|
The Workshop for WebLogic window updates, adding the Portlet_Name.portlet file to the display tree.
| Note: | If you want to have more than one JSF portlet on a portal page, use the namingContainer JSP tag immediately after a JSF view tag, in order to provide component naming in the generated component tree. For more information about this tag, refer to the Portal Development Guide or to the Javadoc for the package com.bea.portlet.adapter.faces. |
Browser portlets, also called Content URI portlets, are basically HTML portlets that use URLs to retrieve their content. Unlike other portlet types that are limited to displaying data contained within the portal project, browser portlets can display URL content that is outside from the portal project.
There are several ways to invoke the Portlet Wizard, as explained in the section Starting the Portlet Wizard. This description assumes that you right-click in the Package Explorer view tree within a portal project and select New > Portlet from the menu.
To create a browser portlet, follow these steps:
The New Portlet dialog displays. Figure 5-15 shows an example of the New Portlet dialog.
The parent folder defaults to the location from which you selected to add the portlet.
The Finish button is initially disabled; the button enables when you select a valid parent folder and portlet name. If you select an invalid portal project in the folder tree on this dialog, an error message appears in the status area near the top of the dialog explaining that the project is not a valid portal project.
The Portlet Wizard displays the Select Portlet Type dialog.
The Portlet Wizard displays the Portlet Details dialog; Figure 5-16 shows an example.
Select the desired check boxes to allow the user to minimize, maximize, float, or delete the portlet. For a more detailed description of portlet states, refer to Portlet States.
|
|
|
To enable an option, select the desired check box and provide the path to the JSP page that will provide the appropriate function. For a more detailed description of portlet modes, refer to Portlet Modes.
|
The Workshop for WebLogic window updates, adding the Portlet_Name.portlet file to the display tree; by default, Workshop for WebLogic places the portlet file in the same directory as the content file.
| Note: | The internal implementation of Browser portlets depends on asynchronous portlet content rendering; because of this, the portlet attribute Async Content displayed in the Properties view is set to none and is read-only. For more information about asynchronous content rendering, refer to Asynchronous Portlet Content Rendering. |
You can use the Portlet Wizard to generate a portlet based on a Struts module.
Before you can create a Struts portlet, you must first integrate your existing Struts application into your portal web application. For detailed information on integrating Struts applications into WebLogic Portal, refer to the Portal Development Guide.
To create a Struts portlet, follow these steps:
The New Portlet Dialog displays.
The Portlet Wizard displays the Select Portlet Type dialog.
The Portlet Wizard displays the Struts Module Path dialog, as shown in Figure 5-17.
The Struts Config File dialog displays; an example is shown in Figure 5-18.
As a best practice, BEA recommends that you locate your configuration file(s) in the WEB-INF directory of your portal web project.
The Struts Actions dialog displays, as shown in Figure 5-19.
The actions that appear in the drop-down menu are based on entries in the configuration file(s) that you selected in a previous step.
The Workshop for WebLogic window updates, adding the Portlet_Name.portlet file to the display tree; by default, Workshop for WebLogic places the portlet file in the directory that you specified in the Struts Module Path dialog of the wizard.
Because remote portlet development is a fundamental task in a federated portlet environment, the task of creating remote portlets is described in detail within the BEA WebLogic Portal Federated Portals Guide.
The following types of portlets can be exposed with WSRP inside a WebLogic portal:
A web service portlet is a special type of page flow portlet, allowing you to call a web service. You create web service portlets using the features of Workshop for WebLogic and WebLogic Portal.
Before you can create a portlet that calls a web service, you must perform the following prerequisite tasks:
Instructions on performing these tasks are contained in the BEA Workshop for WebLogic Programmer's Guide.
After you have performed the setup tasks, you can create a web service portlet by following these steps:
WebLogic Portal supports the use of detached portlets, which provide popup-style behavior. Technically, a detached portlet is defined as anything outside of the calling portal context. Any portlet type supported by WebLogic Portal can be rendered as a detached portlet.
Keep the following considerations in mind as you implement detached portlets:
You use the standalonePortletUrl class or associated JSP tag to create URLs to detached portlets.
To create a detached portlet URL from a JSP page, you use the render:standalonePortletUrl JSP tag or class; the following example shows the syntax of the JSP tag:
<render:standalonePortletUrl portletUri="/absolute_path/detached_portlet_name.portlet" .../>
To create a detached portlet URL from Java code, use the following example as a guide:
StandalonePortletURL detachedURL = StandalonePortletURL.createStandalonePortletURL(request, response);
detachedURL.setPortletUri("/path/to/detached.portlet");
Portlet properties are named attributes of the portlet that uniquely identify it and define its characteristics. Some properties—such as title, definition label, and content URI—are required; many optional properties allow you to enable specific functions for the portlet such as scrolling, presentation properties, pre-processing (such as for authorization) and multi-threaded rendering. The specific properties that you use for a portlet vary depending on your expected use for that portlet.
During the development phase of the portal life cycle, you generally edit portlet properties using the Workshop for WebLogic interface; 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 portlet properties; only a subset of properties are editable at that point. For instructions on editing portlet properties from the WebLogic Portal Administration Console, refer to Modifying Library Portlet Properties and Modifying Desktop Portlet Properties.
For a detailed description of all portlet properties, refer to Portlet Properties in the Portal Properties View and Portlet Properties in the Portlet Properties View.
This section contains the following topics:
To edit portlet properties, follow these steps:
.portlet file to open it in the workbench editor. The displayed properties vary according to the active area that you select. If you click the outer border, properties for the entire portlet appear; if you click the inner border, properties for the content of the portlet appear, and so on.
If you click on a property field, a description of that field displays in the status bar.
Values for some portlet properties are not editable after you create the portlet.
In some cases, from the property field you can view associated information pertaining to that portlet property; for example, the Java portlet Class Name property contains a read-only value with an Open button to view the associated Java 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.
.portlet file in the Package Explorer view and choose Edit with > XML Editor to open the file using the basic XML editor that Eclipse provides. | Caution: | The Eclipse XML editor has limited validation capabilities. BEA recommends the use of a robust validation tool to ensure that your hand-edited XML is valid. |
to launch the page flow class picker dialog. If you open the dialog, the page flow class name is converted to a URI when you leave the dialog. WebLogic Portal stores the URI in the .portlet file when you save the portlet. The property editor validates the page flow URI specified and warns you if you choose a URI that has no corresponding page flow class. You can choose to proceed anyway and store an invalid URI; you should create a valid class later so that the portlet works correctly.
The properties described in this section are contained within the .portal file and are editable using the Workshop for WebLogic workbench. The values you enter here override the corresponding value in the .portal file, if a value exists there.
To display the portlet properties that display in the Properties view for a portal, follow these steps:
| Note: | These steps assume that you have an existing portal that contains portlets. |
The Properties view displays the properties of the portlet instance; Figure 5-21 shows an example.
Table 5-6 describes these properties and their values.
Required. A single portlet, represented by a
.portlet file, can be used multiple times in a portal. Each use of that portlet is a portlet instance, and each portlet instance must have a unique ID, or Instance Label. A default value is entered automatically, but you can change the value. Instance labels help WebLogic Portal manage the runtime state of multiple instances of portlets independently of each other on the server. WebLogic Portal also uses instance labels during URL rewriting and scoping of various HTML controls such as names of forms, and ID attributes.
|
|
The properties described in this section are contained within the .portlet file and are editable using the Workshop for WebLogic workbench. The values you enter here override the corresponding value in the .portlet file, if a value exists there.
When you select the outer border of a portlet instance in the editor, a related set of properties appears in the Properties view. The displayed properties vary according to the type of portlet that you are viewing. Figure 5-22 shows a portion of the Properties view for a portlet.
Table 5-7 describes these properties and their values.
Optional. 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 should implement the interface com.bea.netuix.servlets.controls.content.backing.JspBacking or extend com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking. From the data field you can choose to browse to a class or open the currently displayed class.
|
|||
Required. The path (relative to the project) to the file/class to be used for the portlet's content. From the data field you can choose to browse to a file (or class for page flow portlets) or open the currently displayed file/class. For example, if the content is stored in
Project/myportlets/my.jsp, the Content URI is /myportlets/my.jsp.
|
|||
Allows you to specify whether to use asynchronous content for a given portlet and the implementation to use. An editable dropdown menu provides the selections
none, ajax, and iframe. Portlet files that do not contain the asyncContent attribute appear with the initial value none displayed.
For more information, refer to Asynchronous Portlet Content Rendering.
|
|||
This instance-scoped boolean property appears in the Properties view whenever a window portlet or proxy portlet is loaded, allowing render dependencies to be cached.
|
|||
Optional. Select the multichannel devices on which the portlet can be viewed. The list of displayed devices is obtained from the file Project_Path
\WEB-INF\client-classifications.xml. You must create this file to map clients to classifications in your portal web project. For more information about this task, refer to the Portal Development Guide.
|
|||
Required. Each portlet must have a unique value within the web project. For Java portlets, you type the desired value when creating the portlet; for the remaining portlet types, a value is generated automatically when you create the portlet. Definition labels can be used to navigate to 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 portlets remotely, as it makes it easier to identify them from the producer list.
|
|||
Optional. Indicates whether or not the portlet can be multithread rendered. When set to
true, a portal administrator can use the Fork Render property to make the portlet multithread rendered. The default is false.
For more information, refer to Parallel Portlet Rendering.
|
|||
Optional. If Fork Pre-Render is set to
true, you can set an integer timeout value, in seconds, to indicate that the portal framework should wait only as long as the timeout value for each fork pre-render phase. The default value is -1 (no timeout). If the time to execute the forked pre-render phase exceeds the timeout value, the portlet itself times out (that is, the remaining life cycle phases for this portlet are cancelled), the portlet is removed from the page where it was to be displayed, and an error level message is logged that looks something like the following example.
|
|||
Optional. If Fork Render is set to
true, you can set an integer timeout value, in seconds, to indicate that the portal framework should wait only as long as the timeout value for each fork render portlet. The default value is -1 (no timeout). When a portlet rendering times out, an error is logged, but no markup is inserted into the response for the timed-out portlet.
|
|||
Optional. Hint to the skeleton to position the portlet title bar on the top, bottom, left, or right side of the portlet. You must build your own skeleton to support this property in the .portal file. Following are the numbers used in the .portal file for each orientation value: top=0, left=1, right=2, bottom=3.
|
|||
Optional. To enhance performance, set to
true to cache the portlet. For example, portlets that call web services perform frequent, expensive processing. Caching web service portlets greatly enhances performance.
For more information, refer to Portlet Caching.
|
|||
Required. Enter the title for the portlet's title bar. You can override this title in each instance of the portlet (in the portal editor, as described in Portlet Properties in the Portal Properties View).
|
|||
Optional. Possible values are
none, session, and transient-session. This attribute controls attribute persistence for Page Flow, JSF, and Struts portlets. The default is session, where request attributes populated by an action are persisted into a collection class that is placed into a session attribute so that the portal framework can safely include the forwarded JSP on subsequent requests without re-running the action. Using the value session can cause session memory consumption and replication that would not otherwise occur in a standalone Page Flow, JSF, or Struts application. The value transient-session places a serializable wrapper class around a HashMap into the session. The value none performs no persistence operation.
JPF or Struts portlets that have the
transient-session value applied generally have the same behavior as existing portlets; however, in failover cases, the persisted request attributes disappear on the failed-over-to server. In the failover case, you must write forward JSPs to handle this contingency gracefully by, at a minimum, not expecting any particular request attribute to be populated; ideally you should include the ability to either repopulate automatically or present the user with a link to re-run the last action to repopulate the request attributes. For non-failover cases, request attributes are persisted, providing a performance advantage for non-postback portlets identical to default session persistence portlets.
Portlets that have the
none value applied will never have request attributes available on refresh requests; you must write forward JSPs to assume that they will not be available. You can use this option to completely remove the framework-induced session memory loading for persisted request attributes.
|
|||
|
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.
Sample: If you enter "my-custom-class", the rendered HTML from the default skeletons looks like this:
The properties you enter are added to the component's parent <div> tag. This property also applies to books and pages. For more information, refer to the Portal Development Guide.
|
|||
Optional. Defines whether the portlet is accessible using the WSRP producer. The default is
true, which allows the portlet to be accessed. For more information about entitling remote portlets, refer to the Federated Portals Guide.
|
|||
Optional. If you want to use a backing file for content prior to rendering the portlet, enter the fully qualified name of the appropriate class. That class should implement the interface com.bea.netuix.servlets.controls.content.backing.JspBacking or extend com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking.
|
|||
Optional. If set to
true the portlet can be floated into a separate window. For instructions on creating a floatable Java portlet, which requires editing the weblogic-portlet.xml file, in Customizing Java Portlets Using weblogic-portlet.xml.
|
|||
Optional. If you want to use a class for preprocessing (for example, authentication) prior to rendering the portlet's mode page (such as the edit page), enter the fully qualified name of that class. That class should implement the interface com.bea.netuix.servlets.controls.content.backing.JspBacking or extend com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking.
|
|||
This property is described in the Portal Development Guide.
|
|||
This property is described in the Portal Development Guide.
|
|||
This property is described in the Portal Development Guide.
|
|||
This property is described in the Portal Development Guide.
|
|||