| Oracle® Fusion Middleware Client-Side Developer's Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14229-01 |
|
|
View PDF |
| Oracle® Fusion Middleware Client-Side Developer's Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14229-01 |
|
|
View PDF |
This chapter discusses Portlet Publishing, a feature that lets you surface portlets remotely over HTTP.
This chapter includes these topics:
Portlet Publishing refers to a family of WebLogic Portal features that make portlets available over HTTP. Once published through the WLP Portlet Publishing service, a portlet can be reused in a variety of heterogeneous host environments. For example, you can embed published portlets in an <iframe> tag or include the portlet into a non-portal web page using JavaScript.
This section includes these topics:
Portlets are published through the WLP Portlet Publishing service. The publishing service is a REST-style service that runs in the WLP server. As shown in Figure 5-1, the Portlet Publishing service serves individual portlet instances to remote consumers over HTTP. A remote consumer simply uses a URL to request that the Portlet Publishing service return a portlet. The service then returns the portlet markup to the consumer.
You can ask the Portlet Publishing service to return a library instance of a portlet or a desktop instance. The type of portlet instance you want determines the structure of the URL sent to the service.
You can think of a library portlet instance as a non-customizable instance of a portlet. When you use the Administration Console to add a library portlet to a page in a portal desktop, the added portlet becomes a desktop instance, which makes it possible for each user of the portlet to have their own customized version of it. You can see library and desktop portlets listed in the Portal Resources Tree of the WebLogic Portal Administration Console.
You might decide to ask for a library instance of a portlet if you do not expect users to customize it or if it was not designed to be customizable. For example, a simple mortgage calculator portlet might not require customization. You might choose to consume a desktop instance of a portlet, on the other hand, if you do expect users to customize it. A stock quote portlet might allow users to select their favorite stocks to display and then remember their individual choices.
As noted previously, the type of portlet you want the publishing service to return determines the type of URL that you send to the service. The two Portlet Publishing URL patterns are explained in Section 5.2, "Portlet Publishing URL Forms".
As explained previously, you formulate a specific kind of URL to ask the WLP publishing service for a library instance or for a desktop instance of a portlet. The publishing service then returns the portlet markup to the requesting consumer. The consumer can render the returned portlet markup in three ways:
Render the portlet in an HTML inline frame tag (an <iframe> tag). This is by far the simplest and safest technique. The <iframe> tag provides a loose coupling between the portlet and the rest of your rendered web page. Portlets rendered in <iframe> tags are effectively isolated from one another, reducing possible security risks and adverse side-effects. See also Section 5.3.1, "Inline Frame Integration."
Use a JavaScript API to integrate the portlet into the DOM. WLP provides a Disc API called PortletSource that lets you retrieve a portlet and render it directly into an HTML <div> tag. This technique provides greater flexibility and control to the web developer. For instance, integrated portlets can interact with and affect each other. Greater care is required on the part of the client-side developer to ensure that integrated portlets work and interoperate properly and securely. See also Section 5.3.2, "DOM Integration."
Use the <portalFacet> JSP tag. To surface a portlet in a JSP page, you can insert a portalFacet tag into a JSP page. For example:
<%@taglib uri="http://www.bea.com/servers/portal/tags/netuix/render" prefix="render"%> ... <render:portalFacet label="_myportlet" path="/myPortlet.portlet" />
The web application includes a file called myPortlet.portlet. The label tag attribute must be unique to all <portalFacet> tags on the page because it identifies the portlet instance. At runtime, the <portalFacet> tag renders the specified portlet on the page. You may include multiple portlets on a single page by inserting multiple <portalFacet> tags with unique label attributes. See also Section 5.3, "Consuming Published Portlets".
This section describes the two Portlet Publishing URL forms. The first form retrieves a library instance of a portlet. The second form retrieves a desktop instance. The WLP Portlet Publishing service processes these commands and returns the appropriate portlet to the consumer. Library and desktop portlet instances are explained in more detail in Section 5.1.2, "Asking the Portlet Publishing Service for Portlets".
To return a library instance of a portlet, use this URL form:
http://<domain_name>/<webapp_name>/<path_to_portlet>/<portlet_name>.portlet
For example:
http://foo.com/myWebapp/myPortlet.portlet
Note that the part of the URL that includes the web application name, the path to the portlet, and the portlet name is called the publishing context. The publishing context can be used as a parameter to certain Disc JavaScript API calls. See Section 5.3.2, "DOM Integration" for more information. See also Section 5.3.3, "Finding the Portlet Publishing Context".
Because a library instance is, by definition, not directly associated with a portal desktop, it does not include certain look and feel and other information associated with a desktop instance. The look and feel of a library instance consists of the default WLP look and feel and cannot be changed.
The desktop instance URL form is somewhat more complicated than the form used for library instances. The desktop instance URL is composed of these required parts and parameters:
Domain name and web application name. For example: http://foo.com/myWebapp
WLP REST API namespace identifier. For example: bea/wlp/api
Portlet Publishing service command. For example: portlet/publish
Context parameter. The context parameter value is the path to a streaming portal desktop. For information on obtaining the context path, see Section 5.3.3, "Finding the Portlet Publishing Context".
Tip:
The difference between streaming and file-based portals is explained in more detail in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.For example:
/myWebApp/appmanager/myPortal/myDesktop
Note that appmanager is a WLP servlet name that is part of every streaming desktop path.
Portlet parameter. This parameter specifies the instance label of the library portlet. You can determine the instance label from either Oracle Enterprise Pack for Eclipse or from the WLP Administration Console. For example, a portlet with instance identifier myPortlet_1 would appear as:
portlet=myPortlet_1
Putting it all together, here is an example URL to retrieve a desktop instance portlet from the publishing service:
http://foo.com/myWebApp/bea/wlp/api/portlet/publish? context=/myWebApp/appmanager/myPortal/myDesktop&portlet=myPortletInstanceLabel
There is one more optional parameter you can use in the desktop instance URL form. The decoration parameter is explained in the section Section 5.4, "Advanced Topics".
This section discusses two techniques for consuming published portlets: inline frame (<iframe> tag) integration and DOM integration. This section includes these topics:
The HTML <iframe> tag creates an inline frame that contains another HTML document. You can use an inline frame to include a WLP portlet in an HTML page. The value of the tag's src parameter can be a Portlet Publishing URL of either the library instance or desktop instance form as explained in Section 5.2, "Portlet Publishing URL Forms".
Figure 5-2 illustrates that inline frames are rendered as separate HTML documents within the parent document. The loose coupling between the parent page and the inline frame pages makes inline frames relatively secure. Inline frames are a good choice if you don't trust a portlet to interact securely with the rest of the page. Only limited interaction between the inline frame portlets and the rest of the page is possible. Note that some portlets will not work properly if they are embedded using the DOM integration technique, described in Section 5.3.2, "DOM Integration". In these cases, inline frame integration is the best option.
Figure 5-2 Inline Frames Provide Separation Between Portlets and the Rest of the Page
Example 5-1 shows an inline frame tag that includes a library instance portlet. Example 5-2 shows an example that embeds a desktop instance of a portlet. The value of the <iframe> src parameter is the Portlet Publishing URL of the appropriate form for a library instance and a desktop instance. See also Section 5.2, "Portlet Publishing URL Forms".
Example 5-1 Simple Inline Frame that Embeds a Library Instance Portlet
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<body>
<iframe src ="http://foo.com/myWebapp/myPortlet.portlet"> </iframe>
</body>
</html>
Example 5-2 Simple Inline Frame that Embeds a Desktop Instance Portlet
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<body>
<iframe src ="http://foo.com/myWebApp/bea/wlp/api/portlet/publish/?
context=myWebApp/appmanager/myPortal/myDesktop&
portlet=myPortletInstanceLabel"> </iframe>
</body>
</html>
You can use inline frames to embed either static or dynamic portlets, as explained in the following sections.
Inline frames offer a relatively safe and easy way to integrate legacy portlets into newly developed, static applications. Inline frames are ideal for portlets that use basic HTML, do not make extensive use of JavaScript, post navigation commands back to the server, and contain logic that is captured in Struts or Page Flow actions.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.Dynamic portlets make use of rich user interface technology and asynchronous browser-server communication. More and more sites are being built using mashups of content from one or more providers that are often not known and possibly not trusted by one another. Inline frames provide a convenient and relatively secure sandboxing mechanism in environments where rich widgets and portlets must be integrated together without mutual trust.
WLP provides a JavaScript API called Disc that lets you integrate portlets directly into the DOM of an HTML page.
Tip:
For a comprehensive introduction to Disc, see Chapter 3.DOM integration provides a level of integration and capability that exceeds the inherent limitations of inline frame integration. DOM integration allows a portlet to be treated as if it were a native part of the HTML page's DOM tree. This added capability increases both security risks and integration complexity. Portlets integrated using this approach have complete access to data and UI that exist in other parts of the page. In addition, the developer must take care to prevent collisions in the JavaScript global namespace. See also Section 6.2, "Avoiding Namespace Collisions".
The basic JavaScript coding steps for integrating a remote portlet into the DOM of an HTML page follow a consistent pattern. This section lists and explains each step and then provides a complete example.
Include the Disc Portlet Publishing JavaScript module in your page, as shown in the following fragment:
<script type="text/javascript" src="/<portal_web_app>/framework/scripts/bundles/disc-publishing.js"> </script>
This JavaScript module is contained in a WLP Shared J2EE Library, and is always addressed by the web application-scoped path shown in the fragment. You only need to include this module once per page, even if you are embedding portlets from several different web applications.
Build a variable to hold the publishing context of the portlet. The publishing context is either the path to a .portal file or a desktop of a streaming portal. See also Section 5.3.3, "Finding the Portlet Publishing Context".
For example, the following fragment specifies the context for a file-based portlet, where <portal_web_app> and <portal_name> are the names of the WLP web application and the portal that contain the portlet. The context for a file-based portlet is the physical path from the web application root to the .portal file.
var publishingContext = "/<portal_web_app>/<portal_name>.portal";
To embed a desktop instance of a portlet from a streaming portal, you construct the context variable as follows:
var publishingContext =
"/<portal_web_app>/appmanager/<portal_name>/<desktop_name>
Use the Disc API to retrieve a PortletSource instance for the publishing context. Pass the publishing context variable you constructed in Step 2 as the parameter in this call. For example:
var source = bea.wlp.disc.publishing.PortletSource.get(publishingContext);
Call the PortletSource object's render() function, passing it a JavaScript object with two properties. The first property, portlet, specifies the instance label of the portlet you want to embed. The second property, to, specifies the value of an id attribute for an HTML div tag in which to embed the portlet. For example:
source.render({ portlet: "<portlet_instance_label>", to: "<div_id_value>" });
The render() method also accepts an array of JavaScript objects. See Section 5.4, "Advanced Topics" for details.
Place the portlet in a <div> element on the HTML page. For example:
<div id="div_id_value"></div>
Putting it all together, Example 5-3 shows a complete example where a portlet library instance is embedded into the DOM of an HTML page. In this example, most of the code is wrapped in a JavaScript function called handleOnLoad() that is called when the page loads.
Tip:
Note that the text "Loading..." appears in the <div> tag. This text provides a visual cue to the user. "Loading..." appears momentarily in the page and is replaced by the portlet after the portlet markup is received.Example 5-3 Example Code for Portlet DOM Integration
<html>
<head>
<title>My Portlet</title>
<script type="text/javascript"
src="/myWebApp/framework/scripts/bundles/disc-publishing.js">
</script>
<script type="text/javascript">
function handleOnLoad() {
var publishingContext = "/myWebApp/portals/main.portal";
var source =
bea.wlp.disc.publishing.PortletSource.get(publishingContext);
source.render({ portlet: "myPortlet_1", to: "myPortlet" });
}
</script>
</head>
<body onload="handleOnLoad();">
<p>Basic tests for rendering portlets on a host page.</p>
<div style="border: 1px solid black;">
<div id="myPortlet">Loading...</div>
</div>
</body>
</html>
This section explains how to find the value of the context parameter for library and desktop instance portlets.
To find the publishing context for library instance portlet, in Oracle Enterprise Pack for Eclipse, right-click the .portal file and select Run As > Run On Server. The path shows up in the browser. For example, if the full URL to the portal is:
http://foo.com/myWeb/portal-1.portal
then the publishing context is:
/myWeb/portal-1.portal
The easiest way to obtain the context path for a desktop instance portlet, is to look it up in the WLP Administration Console. In the Portal Resources tree, navigate to the desktop and select it. The path shows up on the Details tab in the URL to Access Desktop field. A complete path looks like this, where the context part is everything from <webapp_name> on.
http://<domain_name>/<webapp_name>/appmanager/<portal_name>/<desktop_name>
Here is an example desktop URL with the publishing context highlighted:
This section discusses several advanced topics of interest to developers.
The desktop instance URL form, discussed in Section 5.2.2, "Desktop Instance URL Form", includes an optional decoration parameter. The decoration parameter lets you specify how the look and feel of the portlet will be rendered. The possible values for the decoration portlet are:
light – (default) Only the content of the portlet is rendered. Light decoration does not include a border or titlebar if they were part of the original desktop portlet instance. This style portlet tends to blend in more with the surrounding web page elements.
full – This option renders the portlet almost exactly it appears in its original desktop context. If defined in the original portlet, the border and title bar (with mode and state buttons) will be rendered. Essentially, the portlet is rendered with the same look and feel as the original portlet appeared in its host desktop.
For example, to remove the border using the Desktop URL Form, you can do this:
http://foo.com/myWebApp/bea/wlp/api/portlet/publish/?context=myWebApp/appmanager/myPortal/myDesktop&portlet=myPortletInstanceLabel&decoration=full
Or, if you want to use a library instance, you can use this form. This form is similar to the Desktop URL Form shown previously; however, with this option, the portlet must be placed in a .portal file.
http://foo.com/myWebApp/bea/wlp/api/portlet/publish?context=myWebApp/<path_to_portal>/my.portal&portlet=myPortletInstanceLabel&decoration=light
Or, you can specify a portlet directly using the Library Instance URL Form:
http://foo.com/myWebApp/<path_to_portlet>/my.portlet?_portlet.contentOnly=true&_portlet.contentMode=FULL
Note:
If you want to generate a decoration-free portlet URL from a JSP, use therender:standalonePortletUrl tag, which has contentOnly and contentMode attributes. If you want to generate the URL from a backing file, use the StandalonePortletURL class. For information on this class, see the Javadoc.For more information, see Section 5.2.2, "Desktop Instance URL Form".
Section 5.3.2, "DOM Integration" discussed how to use the Disc API to integrate a single portlet into the DOM. If you want to integrate multiple portlets onto a page, you can pass the render() function an array of {portlet: , to: } objects. In this case, Disc only makes one request to the server to retrieve all of the portlets.
For example, Example 5-4 illustrates how to integrate multiple desktop instances of portlets into the DOM by passing an array of objects to the Disc render() function.
Example 5-4 Embedding Multiple Portlets
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Portlet Publishing Example</title>
<script type="text/javascript" src="/publishingPortal/framework/scripts/bundles/disc-publishing.js">
</script>
<script type="text/javascript">
function handleOnLoad() {
var publishingContext = "/publishingPortal/appmanager/mainPortal/mainDesktop";
var source = bea.wlp.disc.publishing.PortletSource.get(publishingContext);
source.render([{ portlet: "myPortlet_1", to: "portlet1Div" },
{ portlet: "myPortlet_2", to: "portlet2Div" },
{ portlet: "myPortlet_3", to: "portlet3Div" },
{ portlet: "myPortlet_4", to: "portlet4Div" }]);
}
</script>
</head>
<body onload="handleOnLoad();">
<div style="border: 1px solid black;" id="portlet1Div">Loading...</div>
</br>
<div style="border: 1px solid black;" id="portlet2Div">Loading...</div>
</br>
<div style="border: 1px solid black;" id="portlet3Div">Loading...</div>
</br>
<div style="border: 1px solid black;" id="portlet4Div">Loading...</div>
</body>
</html>
You can integrate portlets from more than one Portlet Publishing context into page. If you are doing DOM integration, you must construct a separate PortletSource API call for each publishing context. If you are using inline frame integration, just use the appropriate Portlet Publishing URL form as the value of the <iframe> src tag.
Note that each PortletSource.render() call produces one interaction with the server. If you group several portlets into one render() call, the function will not return until all of the portlets are processed on the server. If one of the portlets requires excessive processing time on the server, users might experience a delay in the rendering of the entire group of portlets. In this case, consider placing the slower portlet in a separate render() call. This causes the portlet to be rendered in a separate, asynchronous call to the server.
When initiating a redirect response from a portlet that is published through Portlet Publishing, you might need to redirect to the URL of the referrer rather than to allow the portal Java API to construct the URL. For example, if you only want to refresh the current web page containing the portlet, a redirect to the referrer is appropriate. To allow for this case, add code to the backing file of your portlet to detect whether or not the portlet is to be rendered through the Portlet Publishing mechanism or the portal Java API. Sample code illustrating this technique is shown in Example 5-5. In this sample, if the portlet is consumed by a client through the Portlet Publishing mechanism, a refresh URL is obtained by using the value of the Referer request header. If the portlet is not being consumed through Portlet Publishing, the refresh redirect URL is obtained through the WLP PostbackURL API.
You can think of Portlet Publishing and WSRP (Web Services for Remote Portlets) as complementary technologies. Both technologies allow you to consume portlets deployed in remote portals.
In the case of WSRP, portlets from one or more portals, called producers, are aggregated into a common, unified portal, called the consumer. The consumer communicates with producers over a SOAP-based protocol. Because WSRP is an OASIS standard, the producers can use entirely different vendor technologies. Also, because the consumer and producer communicate through standard web services, UDDI registries and service busses can be used to locate portlets and route traffic. Traditional WSRP portlets are closely tied to the producer portals in which they are deployed.
Portlet Publishing, on the other hand, aggregates content (typically portlets) on the browser. Client-side developers make inline frame (iframe) or XMLHttpRequest calls to the server to retrieve content. Portlet Publishing is typically used to expose portlets in a non-portal applications, although you can also use Portlet Publishing techniques in a portal.
Tip:
The WSRP approach to creating federated portals is described in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.Figure 5-3 illustrates the fundamental differences between Portlet Publishing and WSRP. Portlet Publishing obtains content directly from a WLP application. WSRP aggregates content in a consumer portal from one or more producers. Because WSRP is a standard, producers can be from different vendors.
The New JSP Page and the New HTML Page wizards provide a page creation template for portlet publishing. These templates conveniently insert JavaScript code in the resulting JSP or HTML page to render the portlet referenced by a portlet publishing URL.
When you create a new JSP page in Oracle Enterprise Pack for Eclipse (by selecting New > JSP), the New JavaServer Page wizard includes an optional step that lets you pick a JSP template. The template options are:
New Portlet Publishing JSP – Creates a JSP that includes the content of an Oracle WebLogic Portal portlet. This JSP does not have to reside within a portal.
New Portlet Publishing JSP (in Portal WebApp) – Creates a JSP that includes the content of an Oracle WebLogic Portal portlet. This JSP does not have to reside within a portal, but only works in an Oracle WebLogic Portal web application.
The Select JSP Template wizard dialog is shown in Figure 5-4.
Figure 5-4 Select JSP Template Page Dialog in the New JavaServer Page Wizard
The basic procedure for inserting and configuring the template is:
Select New > JSP to bring up the New JavaServer Page wizard.
Enter a name for the JSP file and click Next.
In the Select JSP Template dialog, select New Portlet Publishing JSP (see Figure 5-4).
Click Finish.
Open the JSP file in the JSP editor. You will see that a JavaScript function has been inserted into the file.
Edit the JavaScript function so that it refers to the portlet you wish to consume in the JSP. You need to edit two items in the file: the publishingContext variable and the portlet parameter in the source.render function. Example 5-6 shows the JavaScript function that is inserted into the JSP. The items you need to edit, shown in bold, are described below.
Example 5-6 JavaScript Function Template Inserted Into a JSP File
<script type="text/javascript" src="<render:resourceUrl contextualPath='framework/scripts/bundles/disc-publishing.js'/>">
</script>
<script type="text/javascript">
function handleOnLoad() {
/* Enter your own publishing context instead of appmanager/p/d */
var publishingContext = "${request.contextPath}/appmanager/your_portal/your_desktop";
var source = bea.wlp.disc.publishing.PortletSource.get(publishingContext);
source.render({ portlet: "your_instance_label_here", to: "myPortlet" });
}
</script>
The items to edit in the JavaScript function are:
appmanager – Be sure to use the use the pattern mapped to the AppManagerServlet defined in your servlet descriptor for your application. Note that appmanager is only the default value, and that it might have been changed.
your_portal/your_desktop – Provide the name of the portal and desktop that contain the portlet you want to consume. For information on finding these names, see Section 5.3.3, "Finding the Portlet Publishing Context."
your_instance_label_here – Provide the instance label of the portlet you want to consume. For information on finding the instance label, see Section 5.2.2, "Desktop Instance URL Form."
For more information on this JavaScript function, see Section 5.3.2.1, "Basic JavaScript Coding Steps."Example 5-7 shows a completed JavaScript template for a sample portlet:
Example 5-7 Sample Template JavaScript
<script type="text/javascript"
src="<render:resourceUrl contextualPath='framework/scripts/bundles/disc-publishing.js'/>">
</script>
<script type="text/javascript">
function handleOnLoad() {
/* Enter your own publishing context instead of appmanager/p/d */
var publishingContext = "${request.contextPath}/appmanager/MyPortal/MyDesktop";
var source = bea.wlp.disc.publishing.PortletSource.get(publishingContext);
source.render({ portlet: "myportlet_1", to: "myPortlet" });
}
</script>
When you create a new HTML page in Oracle Enterprise Pack for Eclipse (by selecting New > HTML), the New JavaServer Page wizard includes an optional step that lets you pick an HTML template. The Select HTML Template wizard dialog is shown in Figure 5-5.
Figure 5-5 Select HTML Template Page Dialog in the New JavaServer Page Wizard
The basic procedure for inserting and configuring the template is:
Select New > HTML to bring up the New HTML Page wizard.
Enter a name for the HTML file and click Next.
In the Select HTML Template dialog, select New Portlet Publishing Page (see Figure 5-5).
Click Finish.
Open the HTML file in the editor. You will see that a JavaScript function has been inserted into the file.
Edit the JavaScript function so that it refers to the portlet you wish to consume in the HTML page. You need to edit three items in the file: the publishingContext variable, the portlet parameter in the source.render function. You also need to provide your context root in the indicated places. Example 5-8 shows the JavaScript that is inserted into the HTML page. The items you need to edit, shown in bold, are described below.
Example 5-8 JavaScript Function Inserted Into the HTML File
<script type="text/javascript" src="/your_context_root_here/framework/scripts/bundles/disc-publishing.js">
</script>
<script type="text/javascript">
function handleOnLoad() {
/* enter your own publishing context instead of appmanager/p/d */
var publishingContext = "/your_context_root_here/appmanager/your_portal/your_desktop";
var source = bea.wlp.disc.publishing.PortletSource.get(publishingContext);
source.render({ portlet: "your_instance_label_here", to: "myPortlet" });
}
</script>
The items to edit in the JavaScript function are:
appmanager – Be sure to use use the pattern mapped to the AppManagerServlet defined in your servlet descriptor for you application. Note that appmanager is only the default value, and that it might have been changed.
your_portal/your_desktop – Provide the name of the portal and desktop that contain the portlet you want to consume. For information on finding these names, see Section 5.3.3, "Finding the Portlet Publishing Context."
your_instance_label_here – Provide the instance label of the portlet you want to consume. For information on finding the instance label, see Section 5.2.2, "Desktop Instance URL Form."
For more information on the content of this JavaScript function, see Section 5.3.2.1, "Basic JavaScript Coding Steps."Example 5-7 shows a completed template for a sample portlet:
Example 5-9 Sample Template JavaScript Function
<script type="text/javascript" src="/your_context_root_here/framework/scripts/bundles/disc-publishing.js">
</script>
<script type="text/javascript">
function handleOnLoad() {
/* enter your own publishing context instead of appmanager/p/d */
var publishingContext = "/your_context_root_here/appmanager/MyPortal/MyDesktop";
var source = bea.wlp.disc.publishing.PortletSource.get(publishingContext);
source.render({ portlet: "myportlet_1", to: "myPortlet" });
}
</script>
Portlet Publishing does not support server-side interportlet communication. Portlets that implement IPC will not send or receive IPC events in the Portlet Publishing context. For more information on IPC, see the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
In some cases, the capabilities of the original host desktop will not be available to published portlets. For example, the host desktop's backing context will not be available.
In some cases, it is possible that some parts of the portal control tree are not available to published portlets.
Desktops with URL compression enabled should not be published. URL compression is discussed in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Disc context objects will not be available on the published page. See Chapter 3 for more information.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|