|
|
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 J2EE Shared Library 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 J2EE Shared Library. To see a list of available portlets, you can use the Merged Projects View of the workbench; resources contained in J2EE Shared Libraries 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 J2EE Libraries and their locations on your file system, you can select Window > Preferences > WebLogic > J2EE Libraries.
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 J2EE Shared Library 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 Shared 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 J2EE Shared Libraries, 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 WorkSpace Studio. WorkSpace Studio 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.
WorkSpace Studio invokes the Portlet Wizard any time you perform one of these operations:
portal file is open in the editor view of the workbench.) WorkSpace Studio 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 and later versions, the option to convert a non-portal project to a portal project is not offered. For information on how to integrate portal J2EE Shared Libraries 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.
| Tip: | The Java Server Faces (JSF) Portlet selection only appears by default if you have added the JSF Project facet to you portal web project. In some cases, you may wish to manaully install the modules that are required to create JSF portlets. Although this method is not recommended, if you manually install the appropriate modules, you can force the JSF portlet option to appear in the dialog by selecting Show All Portlet Types. For more information on JSF portlets, see JSF Portlets. . |
The Show All Portlet Types option forces all portlet types to appear in the Select Portlet Type dialog even if their modules were not installed. For example, the Java Server Faces (JSF) Portlet selection only appears by default if you have added the JSF Project facet to your portal web project. In some cases, you may wish to manaully install the modules that are required to create JSF portlets. Although this method is not recommended, if you manually install the appropriate modules, you can force the JSF portlet option to appear in the dialog by selecting Show All Portlet Types. For more information on JSF portlets, see JSF Portlets.
| WARNING: | If you create and publish portlets that require modules that have not been properly installed, unexpected behavior and server runtime errors can occur. |
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 WorkSpace Studio window updates, adding the Portlet_Name.portlet file to the display tree; by default, WorkSpace Studio 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.
WorkSpace Studio 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. WorkSpace Studio lets you export Java portlets to a supported archive file (WAR, JAR, or ZIP) that can be deployed on any supported server. You can also use the Import feature to import archive files containing Java portlets into your WorkSpace Studio workspace. For details, see Importing and Exporting Java Portlets.
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>
The init-param element contains a name/value pair as an initialization parameter of the portlet. You can use the getInitParameterNames and getInitParameter methods of the javax.portlet.PortletConfig interface to return these initialization parameter names and values in your portlet code. Init-params are described in the JSR168 specification.
You can add init-params to your Java portlet by dragging a New Init-Param icon from the Design Palette onto the Java portlet in the portlet editor. Then, click on the init-param section of the portlet to display the parameter’s properties in the Property view. In the Property view, you can enter the following init-param data:
For example, if you created an init-param called “Color” and set the default value to “green,” the following entry will be made in the portlet.xml file:
<init-param>
<description>My init param</description>
<name>Color</name>
<value>green</value>
</init-param>
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
.java that has no corresponding class in the project or J2EE Shared Libraries, 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.
|
|
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 WorkSpace Studio window updates, adding the Portlet_Name.portlet file to the display tree; by default, WorkSpace Studio 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).
| Note: | The Java Server Faces (JSF) Portlet selection only appears in the Portlet Wizard if you have added the JSF Project Facet to you portal web project. To add the JSF Project Facet, right-click the portal web project in the Package Explorer. In the Properties dialog, select Project Facets in the tree on the left. Click Add/Remove Project Facets, select JSF in the Project Facets dialog, and click Finish. |
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 WorkSpace Studio window updates, adding the Portlet_Name.portlet file to the display tree.
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.
If you are using JSPs in your JSF portlets, be aware that you will only see your JSP edits when you view the portlet in a new session. A simple page refresh is not sufficient. This behavior differs from typical JSP development behavior, where changes are compiled and made available after a page refresh. Normally, JSPs are handled by the servlet container, which checks for updated JSPs. JSF, on the other hand, uses JSPs as a source for the component tree, which typically is loaded only once per session, depending on how the JSF implementation handles or does not handle changed JSP source. To see your JSP changes reflected in a JSF portlet, you must view the portlet in a new session. Typically, you can do this by opening a new browser to view the portal.
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.
| Tip: | A clipper portlet also lets you include remote web content in a portal page. For information on clipper portlets and how they differ from browser portlets, see Creating Clipper Portlets. |
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 WorkSpace Studio window updates, adding the Portlet_Name.portlet file to the display tree; by default, WorkSpace Studio 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. |
A clipper portlet is a portlet that renders content from another web site. A clipper portlet can include all or a subset of another web site’s content using a process called “web clipping.” Clipper portlets are discussed in Creating Clipper Portlets.
Use the Portlet Wizard to generate a portlet based on a Struts module, as explained in this section.
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.
| Tip: | It is highly recommended that you fully develop and test a Struts application before attempting to host it within a portal. This helps to separate the complexities of developing a working Struts application from the additional issues involved in putting the Struts application into a portlet. |
To create a Struts portlet, follow these steps:
WEB-INF directory of the portal web application.
The WorkSpace Studio window updates, adding the Portlet_Name.portlet file to the display tree; by default, WorkSpace Studio 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 WorkSpace Studio 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 WorkSpace Studio.
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”);
A file-based portlet can exist either as a stand-alone .portlet file or as an inlined portlet. Typically, within the WorkSpace Studio portal editing framework, .portlet files are included in portals by reference. For instance, when you drag a .portlet file onto a portal, page or book, a reference is created to the portlet file inside the portal, page, or book. On the other hand, an inlined portlet’s entire XML definition is embedded directly in a page or book.
Inlined portlets are created under the following circumstances:
.book or .page file. For detailed information on creating remote books and pages, see the Federated Portals Guide. .book or .page file that contains portlets, those portlets will be inlined if they were originally inlined. If the original page contained referenced portlets, they will be referenced when the page is extracted. For detailed information on the Export/Import Utility, see the Production Operations User Guide. You can drag and drop, cut, copy, and paste inline portlets from one page or book to another from within the portal editor.
Figure 5-19 shows a remote page that contains an inlined portlet and a referenced portlet. Note that the icon used in an inlined portlet is distinct from a referenced portlet.
| Tip: | You can edit the properties of inlined portlets exactly like file-based portlets; however, portlet states and modes are not editable for inlined portlets. |
You can export an inlined portlet to a .portlet file. When you do this, the resulting .portlet file is functionally equivalent to any other .portlet file. When you extract an inlined portlet, the inlined portlet XML code is automatically removed from the source file (a page or book) and replaced with a reference to the newly created .portlet file.
| Note: | After you extract an inlined portlet, you can undo the operation (re-inline the portlet). However, note that the .portlet file that was created during the extraction will not be deleted from your system. The source document will simply not reference the .portlet file any longer. |
To extract an inlined portlet, do the following:
| Tip: | If you receive errors after extracting a portlet, be sure to save the source file and run the Project > Clean command. |
You can set the theme of an inlined portlet exactly as you would for a referenced portlet. To set the theme, right-click the inlined portlet in the book or page editor, and pick a theme from the Theme menu. The theme is retained for that portlet as long as it remains referenced in the page or book.
You can extract any book or page in a portal to a .book or .page file. Once a book or page is extracted, you are free to use it in another portal within the same portal web application if you wish.
The procedure for extracting books and pages is similar to the procedure for extracting inlined portlets, described in Extracting Inlined Portlets. To extract a book or page, do the following:
| Tip: | Any theme applied to a book or page is retained for an extracted book or page as long as the book or page remains referenced in the portal. |
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 WorkSpace Studio interface; this section describes properties that you can edit using WorkSpace Studio.
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 WorkSpace Studio 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-22 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 WorkSpace Studio 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-1 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. See also Portlet Dependencies.
The value defaults to
true if the attribute is not already included in the .portlet file. The value is read-only for proxy portlets and editable for all other portlet types. For proxy portlets, the value is initialized from th e producer whenever a proxy portlet is generated from the portlet wizard.
|
|||
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 WorkSpace Studio 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. Use this value to configure interportlet communication using portlet events. The default is
No event handlers. To select or add an event handler, click Browse in the Properties view. You an also click the Event Handlers link in the portlet editor. Both of these methods bring up the Portlet Event Handlers dialog box.
|
|||
For details on this property, refer to Portlet Forking.
|
|||
For details on this property, refer to Portlet Forking.
|
|||
For details on this property, refer to Portlet Forking.
|
|||
For details on this property, refer to Portlet Forking.
|
|||
For details on this property, refer to Portlet Forking.
|
|||
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.
|
|||
(Optional) Lets you add name/action pairs to a JSF portlet. The name field is simply an alias. Event handlers (and the Event Handler dialog) can simply reference this name. The action is a reference to a JSF view ID, such as
myfaces/foo.face. For more information on adding event handlers, see Portlet Events.
|
|||
|
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.
|
|||