|
Oracle® Application Server Portal Developer's Guide
10g Release 2 (10.1.2) B14134-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Developer's Guide
10g Release 2 (10.1.2) B14134-02 |
|
|
Previous |
Next |
This chapter describes portlet features, characteristics, technologies, and tools to help you decide which portlet building technology best suits your needs. It includes the following sections:
|
Note: This section discusses WSRP producers. OracleAS Portal supports the building of JPS portlets but does not yet support consumption of WSRP-enabled portlets. Hence, today you can only test your JPS portlets against the hosted OracleAS Portal Verification Service (http://portalstandards.oracle.com) or the Developer's Preview for OracleAS Portal available for download. Please note that both the Developer's Preview and the hosted OracleAS Portal Verification Service are provided for development purposes only and, as such, should not be used for production systems.
|
Table 2-1, "Portlet Building Technologies Comparison Matrix" summarizes the technologies and tools you can use with OracleAS Portal on one axis, and the features and characteristics on the other. The matrix describes those tools and technologies that are covered in further detail in this guide: OmniPortlet, Web Clipping, the Java Portlets (PDK-Java) including Standards, Portlet Builder as an appendix, and PL/SQL Portlets (PDK-PL/SQL) (in the matrix only).
|
Note: While these are the primary tools for building portlets, additional tools and technologies exist, such as other Oracle products, including Oracle Reports and Oracle Discoverer. These other tools are not covered in this guide. |
The other sections in this chapter provide further detail on the characteristics listed in Table 2-1. Use the table to quickly scan all the features and characteristics, then refer to the subsequent sections for more in-depth information.
Table 2-1 Portlet Building Technologies Comparison Matrix
| Web Clipping | OmniPortlet | PDK-Java | Standards | Portlet Builder | PDK-PL/SQL |
|---|---|---|---|---|---|
|
|
|||||
|
A simple wizard-based tool that helps you retrieve and present Web content, originating from other Web sites, in your portal. |
Wizard-based tool, accessible from the browser. Capable of retrieving and presenting data from a wide variety of data sources. |
APIs for portlets built specifically for OracleAS Portal. |
Portlets that should work with portals of other vendors. Oracle supports both WSRP and JSR-168. |
Wizard-based tool, accessible from the browser. Best suited for simple, DB-centric applications or portlets. |
APIs for portlets built specifically for OracleAS Portal. |
|
|
|||||
|
No expertise required. |
Basic understanding of one or more supported data sources and the concepts of portlet and page parameters and events. |
Java, Servlet, JSP knowledge. |
Java, Servlet, JSP knowledge. |
Basic understanding of relational DB concepts. Optionally SQL, PL/SQL. |
SQL, PL/SQL, PL/SQL Web Toolkit. |
|
Supported Data Sources (for details, see below Section 2.3, "Expertise Required") |
|||||
|
Any Web site accessible on the network over HTTP or HTTPS. |
CSV, XML, Web Service, SAP, SQL, Web site, JCA. |
No limitations. |
No limitations. |
SQL (local DB or remote DB via DB link) |
SQL (local DB or remote DB via DB link) |
|
|
|||||
|
Web provider |
Web provider |
Web provider |
WSRP |
Database provider |
Database provider |
|
|
|||||
|
Expiry-based caching, invalidation-based caching (auto invalidate when personalized). |
Expiry-based caching, invalidation-based caching (auto invalidate when personalized). |
Expiry-based, validation, and invalidation caching, ESI. |
Validation and expiry-based caching. |
Expiry-based caching. |
Expiry-based, validation, and invalidation caching. |
|
|
|||||
|
Browser - wizard. |
Browser - wizard. |
Oracle JDeveloper - Java Portlet Wizard (or any other Java development environment - without the Wizard). |
Oracle JDeveloper - Java Portlet Wizard (or any other Java development environment - without the Wizard). |
Browser - optionally PL/SQL development environment. |
PL/SQL development environment. |
|
|
|||||
|
Develop in place. |
No in-place portlet building experience. Add portlet to page, edit defaults, and personalize. |
No in-place portlet building experience. Add portlet to page, edit defaults, and personalize. |
Develop first, then add and develop in place. |
No in-place portlet building experience. Add portlet to page, edit defaults, and personalize. |
|
|
|
|||||
|
N/A |
Limited. |
Very flexible. |
Very flexible. |
Limited. |
Very flexible. |
|
Ability to Capture Content from Web Sites |
|||||
|
Yes, by its nature. |
Yes, by using the Web Data Source. |
Yes, by using the java.net package. |
Yes, by using the java.net package. |
No |
Yes, by using the UTIL_HTTP package. |
|
Ability to Render Content Inline |
|||||
|
Yes. (Supported by Web Clipping 9.0.4.0.2 or later.) |
No URL rewriting support, but can be achieved by using public portlet parameters and events. |
By using private portlet parameters. |
Include servlets and JSPs (using the PortletContext.getRequestDispatcher() method). |
Pagination in reports and charts is rendered inline. |
By using private portlet parameters. |
|
|
|||||
|
N/A |
Yes, 2D-3D charts. |
By using BI Beans. |
By using BI Beans. |
HTML charts. |
Programmatically, HTML charts. |
|
Public Portlet Parameters Support |
|||||
|
Yes. (Supported by Web Clipping 9.0.4.0.2 or later.) |
Yes |
Yes |
No |
Yes |
Yes |
|
Private Portlet Parameter Support |
|||||
|
N/A |
N/A |
Yes |
Yes |
No |
Yes |
|
|
|||||
|
Yes |
Yes |
Yes |
Portlet private events (actions). |
No |
No |
|
Ability to Hide and Show Portlets Based on User Privileges |
|||||
|
No, though it is possible to apply security managers that are not exposed through the UI. |
No, though it is possible to apply security managers that are not exposed through the UI. |
Yes, by using the Security managers. |
Yes, the Servlet security model is supported by using methods such as PortletRequest.isUserInRole() and PortletRequest.getUserPrincipal(). |
Yes |
Yes, by using the Security APIs. |
|
|
|||||
|
N/A |
Yes |
Yes |
Yes |
No |
Yes |
|
|
|||||
|
N/A |
No |
Programmatically |
Programmatically |
Yes |
Programmatically |
|
Single Sign-On and External Application Integration |
|||||
|
Web Clipping 9.0.4.0.2 and above supports external application integration. |
Basic authentication support if the data source requires it. |
External application integration supported. LDAP integration is supported when the portlet is running behind the same firewall as the LDAP server. |
No. (Feasible through custom user attributes.) LDAP integration is supported. |
No. (It runs in the OracleAS Portal repository; it does not require SSO integration.) |
SSO is enabled by using mod_oso. |
This section describes each portlet-building technology in terms of its usage characteristics (for example, wizard-based or programmatic).
Web Clipping is a simple wizard-based tool that helps you retrieve and present Web content, originating from other Web sites, in your portal. Web Clipping does not require you to have any technical background.
If you are looking for an easy-to-use, wizard-based tool to present information from a wide variety of data sources, you should consider OmniPortlet. OmniPortlet runs completely in the browser. All you need to do is drop your OmniPortlet on a portal page, and select your data source from a list of available data sources, which includes:
Spreadsheet
SQL
XML
Web Service
Web page
Although OmniPortlet does not require you to use an additional development tool or have a strong technical background, you can build reusable and high-performing portlets with it.
If the wizard-based portlet building tools do not satisfy your needs, you can build your portlets programmatically using Java. The Java Community Process standardized the Java portlet APIs in 2003. Portlets built against the Java Specification Request (JSR) 168 standard are interoperable across different portal platforms. The Java Portlet Wizard, an Oracle JDeveloper plug-in, helps you get started with your Java portlets.
|
Note: When building portlets in Java, you have full control over your portlet's functionality. For example, you can control what it looks like and how it behaves. |
Portlet Builder is a wizard-based tool to create data-driven portlets, where the data resides in an Oracle database. You can build interactive forms to insert, update, and delete database records. You can create flexible reports and HTML bar charts to display information from the database. Portlet Builder also enables you to pass parameters and navigate between your data-driven portlets by using dynamic links.
Similar to Java portlets, PL/SQL portlets provide a flexible approach to build Web applications that cannot be satisfied by built-in portlets. For example, your application may require implementation of special business rules or logic or meet custom-designed authorization requirements. PL/SQL portlets are commonly used when you need to perform data intensive operations by using SQL and PL/SQL. OracleAS Portal offers a rich set of PL/SQL APIs, such as programmatic provider registration, object level privilege management, user interface control, or multilingual support.
For example, any information provider can create custom portlets to display an application to users through OracleAS Portal. Developers simply build their portlets according to OracleAS Portal Developer Kit (PDK) specifications and register the provider with OracleAS Portal. Developers can use the OracleAS PDK to develop portlets to suit their needs.
While some of the portlet building tools do not require portlet development skills, others assume a strong technical background. This section describes each tool in terms of the level of knowledge required to use it effectively.
Web Clipping is a tool that does not require any technical background at all. However, if you want to parameterize the Web page content that you clipped, you need to have an understanding of public portlet parameters and page parameters.
OmniPortlet requires you to have basic knowledge of the data source you want to leverage in your portlet.
| Data source | What you need to know about the data source |
|---|---|
| Spreadsheet | The URL that points to the spreadsheet containing the data that you want to display in the portlet. |
| SQL | The connection information to the data source and the SQL query that retrieves the data from the database. |
| XML | The location of the XML source and optionally the address of the XSL filter and the XML schema. |
| Web service | The WSDL URL, the method of the Web service, and optionally the XSL filter URL and the XML schema URL. |
| Web page | The Web page data source uses the same environment as Web Clipping. No technical background is required. |
| J2EE Connector Architecture | Although not displayed on the Type page of the OmniPortlet Wizard, a J2EEtm Connector Architecture (JCA) 1.0 adapter is also available. JCA provides a mechanism to store and retrieve enterprise data such as that held in ERP systems (Oracle Financials, SAP, PeopleSoft, etc.). |
To build Java portlets, you must know at least a subset of J2EE. Knowing HTML, Java servlets, and XML is a must, and JSP experience is recommended. Additional Java knowledge is optional, depending on the task you want to perform. Using Java portlets you can access any data source (supported by the Java language).
If you want to use Portlet Builder, you must have a good understanding of relational database concepts. Depending on what you want to achieve, SQL and/or PL/SQL knowledge may be required, as well. Using Portlet Builder, you can consume data from the local (Oracle Application Server infrastructure) database or remote databases using database links.
To build PL/SQL portlets, you must know how to write SQL statements, code and debug PL/SQL program units using SQL*Plus or similar development tool that enables you to connect to Oracle database. You should also know HTML and PL/SQL Web Toolkit to generate the portlet content. Experience of coding the PL/SQL Server Pages (PSP) is optional.
As shown in Figure 2-1, portlets can be deployed to OracleAS Portal through three provider types: Web providers, WSRP producers, and database providers. Web providers are deployed to a J2EE application server, which is often remote and communicates with OracleAS Portal through Simple Object Access Protocol (SOAP) over HTTP. Web Services for Remote Portlets (WSRP), an OASIS standard, is supported in the Developer's Preview of OracleAS Portal. Database providers are implemented in PL/SQL and deployed in the Oracle database where OracleAS Portal is installed.
Web providers are the most commonly used and flexible type of provider. They may reside on the same application server as OracleAS Portal, on a remote application server, or anywhere on the network. A Web provider could be implemented using virtually any Web technology. However, the Oracle Application Server Portal Developer Kit provides a Java framework that simplifies the task of building Web providers.
Web providers use open standards, such as XML, SOAP, HTTP, or J2EE for deployment, definition, and communication with OracleAS Portal. Also, because Web providers can be deployed to a J2EE container, they do not put an additional load on the OracleAS Portal Repository database.
There are several benefits when developing portlets and exposing them as Web providers. you can:
Deploy portlets remotely.
Leverage existing Web application code to create portlets.
Specify providers declaratively.
Take advantage of more functionality than that with database providers.
Use standard Java technologies (for example, servlets and JSPs) to develop portlets of Web providers.
To expose your portlets using a Web provider, you must create a provider that manages your portlets and can communicate with OracleAS Portal using SOAP. To learn how to expose your portlets using a Web provider, refer to Section 6.5, "Building JPS-Compliant Portlets with Oracle JDeveloper".
Web Services for Remote Portlets (WSRP). Web services standard that allows the plug-and-play of visual, user-facing Web services with portals or other intermediary Web applications. Being a standard, WSRP enables interoperability between a standards-enabled container based on a particular language (such as JSR 168, .NET, Perl) and any WSRP portal. So, a portlet (regardless of language) deployed to a WSRP-enabled container can be rendered on any portal that supports this standard. From an architecture perspective, WSRP producers are very similar to Web providers. For more information on the WSRP portal architecture, see Section 6.4.1, "The Relationship Between WSRP and JPS".
You can also create a database provider that owns one or more PL/SQL portlets. Database providers and their PL/SQL portlets reside in the Oracle Application Server Metadata Repository database and are implemented as PL/SQL packages. To access database providers on remote servers, you can use the Federated Portal Adapter. For more information, see the "Understanding the Federated Portal Adapter" article on Portal Center (http://www.oracle.com/technology/products/ias/portal/portlet_development_10gr2.html).
Database providers are ideal when you need to perform data-intensive operations using PL/SQL. An example of this is when you are building forms or charts with the OracleAS Portal user interface or the PL/SQL APIs provided in the PDK.
To learn how to expose your PL/SQL portlets using a database provider, refer to Section 8.13, "Registering Providers Programmatically".
Figure 2-4 illustrates the basic architecture of portlet providers. When users display the portal page in their Web browsers, the flow of the request works like this:
The user requests a portal page from the Web browser by entering a URL in the browser's address field.
The Parallel Page Engine (PPE), which resides in the Oracle Application Server's middle tier, retrieves the portal page layout, portlet, and provider information (also called the page metadata) from the OracleAS Portal Repository.
|
Note: The PPE is responsible for constructing the requested portal page based on the page metadata. |
The PPE contacts all the providers for the portlet content.
The providers make the necessary calls to their portlets so that the portlets generate the portlet content in the form of HTML or XML code.
The providers return the portlet content back to the PPE.
The PPE assembles the portal page, and the Oracle Application Server returns the page to the Web browser.
|
Note: For more information about the portlet and provider architecture, visit the Portlet Development page on Portal Center (http://portalcenter.oracle.com).
|
Web Clipping, OmniPortlet, and Java portlets communicate with OracleAS Portal through Web providers. After you install OracleAS Portal, Web Clipping and OmniPortlet are ready to use; their providers are registered with OracleAS Portal out of the box. You have to register the provider of your Java portlets explicitly.
|
Note: Web Clipping and OmniPortlet are developing very rapidly. The most recent versions of these portlets are available for download on OTN. If you decide to go with the downloaded version of these tools, you must deploy them to OC4J and register them with OracleAS Portal as Web providers. For more information, refer to the Oracle Application Server Portal Configuration Guide available on the Documentation on OTN (http://www.oracle.com/technology/products/ias/portal/documentation.html). |
Data-driven portlets, built with Portlet Builder, communicate with OracleAS Portal through database providers. You do not need to register the Portlet Builder providers with OracleAS Portal explicitly; they are automatically registered for you.
PL/SQL portlets communicate with OracleAS Portal through a database provider. You have to register the database provider explicitly.
OracleAS Portal includes a provider registration wizard, accessible from the Providers tab in the Navigator. The registration screen contains the following sections:
Provider Information: Contains the provider name, time-out details, and the implementation style.
User/Session Information: Contains information on how session information is communicated to the providers.
Database Providers: Contains information specific to database providers, such as the implementation owner and name.
Web Providers: Contains information specific to Web providers, such as the URL of the provider, the user's identity communicated to the provider, and proxy information.
WSRP Producers: Contains information specific to WSRP producers, such as the WSDL URL and the session handling information supplied by the producer.
The sections that impact session handling are the User/Session Information section and the cookie domain check box on the Web provider registration page of the wizard. For more information on using the same cookie domain, refer to the "Sharing Session Cookies Not Allowed in PDK-Java Release 2" article, which can be accessed from the Portlet Development page on Portal Center (http://www.oracle.com/technology/products/ias/portal/portlet_development_10gr2.html).
In the User/Session Information section, you can choose one of two options, depending on the session-related information you want the providers to receive from OracleAS Portal:
Public: Choosing this option sets the name of the user to Public. The providers will not receive any session-related information like the session ID or the time the user logged in. This option is the equivalent of the LOGIN_FREQUENCY_PUBLIC in the provider registration API (see Section 8.13, "Registering Providers Programmatically").
User: Choosing this option sends the name of the OracleAS Portal user to the providers. This section contains two options:
Login Frequency: Here, you can select one of three options (always, once per user session, and never) to determine how often the session information must be sent to the provider, and thus how often the user needs to log in.
Require Portal user-specific session information: Here, you can specify whether the session information will be sent in the provider calls.
Caching plays an essential role in ensuring that your portal is highly performant. OracleAS Portal supports caching on various levels, such as caching pages, portlets, styles, and page metadata. Caching portlets is key to delivering accurate information in a timely manner to your users. All portlet building technologies, available with OracleAS Portal, support caching.
As OracleAS Portal supports user personalization of pages and portlets, the view of a page can vary from user to user. OracleAS Portal's caching is designed to allow content to vary on a per-user basis. Therefore, portal objects, including portlets, can be cached at two levels: user level and system level.
User-level caching is for a specific user; the cache entries stored are unique for that user and cannot be accessed by other users. Good candidates for user-level caching are portlets supporting personalization, such as e-mail or stock ticker portlets.
System-level caching allows users to share a single cache entry and, therefore, there is no need to cache a copy of the object for every user. Examples of content that might be suitable for system-level caching are news portlets that are not personalizable, or custom-built navigation portlets.
When not using caching, you may find accessing various data sources with Web Clipping, OmniPortlet, and Portlet Builder to be time consuming. When you enable caching, you instruct OracleAS Portal or OracleAS Web Cache to maintain a copy of the portlet content. If the portlet is requested and the content was cached previously, the portlet does not have to spend time contacting the data source and regenerating its content again. Simply, the previously cached portlet content is returned.
Expiry-based caching: You can use expiry-based caching when the portlet content is static or when it is not critical that the most up-to-date content be displayed. When using expiry-based caching, you must specify the caching period.
Validation-based caching: You can use validation-based caching for portlets with dynamic content that changes frequently or unpredictably. The portlet associates its content with a caching key and returns the key value along with the content. When the portlet content is requested, the portlet decides, based on the caching key, if the current content is valid. If the portlet content is valid, then it returns a response indicating that the cached content can be used (that is, the content is valid) or generates the new portlet content and returns it along with a new caching key for that content.
Invalidation-based caching: Invalidation-based caching is the most complex, but also the most flexible, form of caching. It combines the efficiency of expiry-based caching with the ability to invalidate the cache content any time. Objects in OracleAS Web Cache are considered valid until they are invalidated explicitly.
For portlets built with Web Clipping, OmniPortlet, and Portlet Builder you can specify a period of time for which they are cached (expiry-based caching). In addition to this, portlets built with Web Clipping and OmniPortlet are refreshed automatically when the end user personalizes them.
Java portlets support three types of caching: expiry-, validation-, and invalidation-based caching. With Java portlets, you can combine invalidation-based caching with either expiry-based or validation-based caching.
In addition to caching all your portlet's content, you can also cache fragments of your portlets by using Edge Side Includes (ESI).
This section describes the type of development tool you may use to build the portlet. For example, OmniPortlet is built in a browser-based wizard while Java portlets may be built in a tool like Oracle JDeveloper.
OmniPortlet, Web Clipping, and Portlet Builder use a browser-based wizard as the development tool.
To build Java portlets, the only requirement is the PDK-Java. It is highly recommended, though, that you use Oracle JDeveloper, a professional, integrated development environment (IDE). While you can consider other IDEs, the PDK contains an Oracle JDeveloper plug-in that includes the Java Portlet Wizard, to minimize your Java portlet development efforts.
The Java Portlet Wizard generates a starting skeleton and file structure for both JSR 168 and PDK-Java portlets. You need to add only your own business logic to the skeleton. JDeveloper can also package and deploy your applications to your J2EE container, such as OracleAS Containers for J2EE (OC4J). Also, Oracle JDeveloper helps you test your portlet provider. You can use the integrated stand-alone OC4J that is shipped with Oracle JDeveloper as your development Java portlet runtime environment, if the version matches that of the platform on which you plan to deploy.
When developing a PL/SQL portlet, you create PL/SQL program units that access OracleAS Portal by calling OracleAS Portal PL/SQL APIs. To enable this access, you create a schema, the provider schema, to store the provider and portlet PL/SQL packages in the same database in which OracleAS Portal is installed. The provider schema must be granted execute privileges on the OracleAS Portal PL/SQL APIs.
To facilitate the development of database providers and PL/SQL portlets, you can use the PL/SQL Generator, a hosted utility that creates installable PL/SQL code for a database provider and its PL/SQL portlets. The PL/SQL Generator is a Web application that receives the provider and portlet definitions in the form of an XML file. The syntax of the XML tags that are used for the provider and portlet definition is a subset of the XML tags that are used for defining Web providers with the PDK-Java. The output of the PL/SQL Generator is a SQL script that can be run from SQL*Plus. The script contains SQL commands for installing the provider and portlet packages.The hosted PL/SQL Generator is available on the Oracle Application Server Portal Developer Kit page of OTN (http://www.oracle.com/technology/products/ias/portal/pdk.html).
OracleAS Portal supports two types of portlet creation as shown in the figure below:
The figure also indicates that the "Develop first, add later" portlet creation is usually the task of the portlet developer, while the "Develop in-place" portlet creation is the page designer's responsibility.
OmniPortlet and Web Clipping offer the same approach to creating portlets. First you add the portlets to a portal page and then you define them in place on the page.
Java portlets do not tend to provide a develop-in-place experience. You can easily add edit defaults and personalization to your Java portlets.
|
Note: With extensive coding, you can create develop in place Java portlets. For example, Web Clipping and OmniPortlet are both Java portlets. |
With Portlet Builder you define the portlets first. The previously defined portlets are then made available to you in the portlet repository so you can add them to your pages. For simple portlets, though, Portlet Builder offers you the develop in place experience, similar to OmniPortlet and Web Clipping.
|
Note: Portlets built with Portlet Builder's develop-in-place technology are somewhat limited as compared to those built using the Navigator. |
This section describes the portlet building tools in terms of the control you have over the user interface.
Because of its nature, Web Clipping always displays the remote Web site content, therefore UI flexibility is not a requirement for this portlet.
While you can be very productive in building portlets with OmniPortlet and Portlet Builder, they are somewhat limiting with respect to the user interface.
OmniPortlet allows you to select from a few layout styles, including tabular, chart, news, bullet, and form. Depending on the layout styles, you can fine-tune the appearance of your portlet. For example, you can opt for alternating vs. plain table row background, choose from three types of charts (bar, pie, and line), or specify the bullet style (disc, circle, square, numeric, etc.). You can also specify the column labels, as well as their alignment.
This section describes the portlet building tools in terms of their ability to include content from other sources.
In the event that you have to create a portlet that displays the content from a remote Web site as it is presented at the source location, the best tool to use is Web Clipping. Web Clipping can tolerate the changes of the source HTML page to some extent. If a clipped table moves from one place to another in the source page, the Web Clipping engine can find the table again using the internal "fuzzy match" algorithm. Portlets built with Web Clipping can also maintain sessions to the remote Web sites. Web Clipping also supports the end user personalization of HTML form values.
Another possible scenario is that you are interested in the data only, not in the way it is presented on the remote Web site. You want to retrieve the data, process the data (format, filter, etc.), and present it in a portlet in a tabular, chart, or news format. For this purpose, OmniPortlet is the best choice. OmniPortlet is a powerful tool that extracts data from Web pages by using its Web data source.
In your Java portlets, similarly to other Java applications, you can always take advantage of the low-level Java networking APIs to retrieve and process content from remote Web sites. To avoid unnecessary development efforts, before choosing Java always make sure that Web Clipping or OmniPortlet are not viable options for you.
PL/SQL portlets can communicate with Web servers to access data on the Internet by using procedures and functions from the UTL_HTTP package. The package makes HTTP callouts from SQL and PL/SQL. The package also supports HTTP over the Secured Socket Layer protocol (SSL), also known as HTTPS, directly or through an HTTP proxy. Other Internet-related data-access protocols (such as the File Transfer Protocol (FTP) or the Gopher protocol) are also supported using an HTTP proxy server that supports those protocols.
Active elements in your portlets, such as links or form buttons, enable your users to navigate to remote URLs. In a News portlet, for example, you can click a hyperlink to navigate to a news site with detailed information about the news you are interested in. You leave the portal page; the News site replaces it in your browser.
However, you may be required to keep your users within the context of the portal page by rendering the requested content within the same portlet container. In the News portlet, for example, you have to display the detailed news on the portal page within the boundaries of the same portlet.
Web Clipping has URL rewriting support to achieve this functionality: it can process the links, originating from the source Web site, and modify (rewrite) them to achieve the desired functionality.
You can choose from the following three options:
You can select not to rewrite the URLS within the portlet, in which case clicking the links takes the users out of Portal to the Web site providing the clipping. If the Web Clipping provider is registered with an External Application, this may require that the user enter login information before navigating the Web site.
If the Web Clipping provider is registered with an External Application and the clipping requires authentication, you can instruct Web Clipping to rewrite all URLs within the portlet to point to the Login Server. In this case, navigation will cause the user to leave OracleAS Portal, while also using the Login Server to log the browser into the External Application.
You can select to rewrite all URLS within the portlet (inline rendering) to point back to the portal page so that all browsing within the Web Clipping portlet remains within OracleAS Portal. If the Web Clipping provider is registered with an External Application, this will cause the Web Clipping provider to log itself into the External Application. In this case, the navigation within Portal through the Web Clipping provider is authenticated in the External Application.
OmniPortlet does not offer URL rewriting directly, but you can achieve the inline rendering functionality by using public portlet parameters and events. Then you have to map the events to the same portal page where your OmniPortlet resides.
Since you have full control over the links and buttons in Java portlets, you can easily implement the inline rendering functionality. You have to append the private portlet parameters to the page URL.
If you use Struts in your portlet, the PDK-Struts integration framework renders your content always in the same portlet container.
If your portlet consists of multiple JSPs (for example, several steps in a survey, or in a Wizard), your portlet can make use of a special parameter to specify at runtime the JSP to use to render the content.
Portlets built with Portlet Builder do not have inherent inline rendering support. You can, however, construct your links in SQL-based reports and charts so that they point to specific portal pages. If required, you can also pass parameters to portal pages, which in turn can be mapped to portlet parameters.
This section describes the portlet building tools in terms of their charting functionality.
Because of its nature, Web Clipping can retrieve and present HTML content containing charts, but it does not support the creation of charts.
OmniPortlet supports the following three chart types: bar, line, and pie. Charts in OmniPortlet are dynamically generated images with, optionally, event-enabled hyperlinks.
You can create more sophisticated chart portlets programmatically in your Java portlets using Oracle's Business Intelligence (BI) Beans.
|
Note: Oracle Reports and Oracle Discoverer portlets use BI Beans to create professional graphs. |
With Portlet Builder, you can build HTML-based bar chart portlets. Among other features, you can specify the color and orientation of the bars.
There are three types of parameters in OracleAS Portal: page parameters, public portlet parameters, and private portlet parameters.
Page parameters: You can use a page parameter to pass a value to a page. Using page parameters, the information that is displayed on a page can vary depending on where the page is called from and who is viewing the page. Using page parameters, page designers can synchronize the portlets on a page by passing them the same values. This provides the ability to reuse and tailor portlets on pages by merely integrating them with page parameters. Without this functionality, you would have to code portlets individually to use different parameter values.
Public portlet parameters: You can use a public portlet parameter to pass a value to a portlet. Using portlet parameters, the information that is displayed in a portlet can be specific to a particular page or a user. Portlet parameters are created by the portlet developer and are exposed to the page designer, through the user interface. After adding a portlet to a page, page designers can assign values to the public portlet parameters to make the information displayed in the portlet specific to the page.
Page designers can assign values to public portlet parameters by providing a specific value (constant), a system variable (for example, the portal user name), or a page parameter. At run time, the portlet receives the values from the sources specified. In this way, page designers have complete control over the source of the parameter, whereas you have complete control over how the data is used after it is transmitted to the portlet.
Private portlet parameters: You can use private portlet parameters to implement internal navigation in your portlet. You can pass parameters to your portlets every time the page is requested. Private portlet parameters can be passed exclusively from the portlet instance to the same portlet instance.
Portlets supporting public portlet parameters enable page designers to tailor the portlets' data input for each portlet instance. In this case, the portlet developer can focus on the portlet logic, while page designers can easily reuse portlets and address the interaction between the page and the portlets.
All five portlet building technologies discussed in this chapter (OmniPortlet, Web Clipping, Java portlets, Portlet Builder, and PL/SQL portlets) support public portlet parameters. OmniPortlet, Web Clipping, and Portlet Builder provide complete support through their wizard interface. You can add public portlet parameter support to your Java portlets programmatically or with the Java Portlet Wizard. PL/SQL portlets support public parameters only programmatically.
|
Note: The JSR 168 standard does not cover the notion of public portlet parameters. If you want to utilize public portlet parameters in your Java portlets, you have to use PDK-Java. |
This section describes the portlet building tools in terms of their support for private parameters.
OmniPortlet, Web Clipping, and Portlet Builder do not provide access to the portlet developer to private portlet parameters.
In your Java portlets and PL/SQL portlets, you can implement internal navigation by using private portlet parameters.
|
Note: PL/SQL portlets do not support private and public parameters simultaneously. You need to decide which parameter type to support before coding your PL/SQL portlet. |
An event is a user action that you define to display a Portal page. User actions include clicking a link or a button in a portlet. Page designers specify what to do when an event occurs in a portlet on a page. When an event occurs, page designers can either redisplay the current page or navigate the user to another portal page, optionally passing values to that page's parameters.
This section describes the portlet building tools in terms of their support for authorization functionality.
You can hide and show portlets built with Web Clipping and OmniPortlet on portal pages dynamically by using security managers. Although Web Clipping and OmniPortlet do not expose security managers through the user interface, you can apply them by editing their XML provider definition file.
The PDK provides a number of security managers for Java portlets. For example:
Group security manager: The group security manager makes the portlet appear to users who are members of a specified group, while hiding it from those who are not members.
Authentication level security manager: You can use the authentication level security manager to control access to the portlets based on the user's authentication level. For example you may hide the portlet from public users but display it to authenticated users.
JSR 168 portlets support the standard servlet mechanisms.
Portlet Builder provides a declarative user interface to control access to portlets.
This section describes the portlet building tools in terms of their support for other languages.
Support for pagination is useful when you are required to display a relatively large set of records in your portlets.
This section describes the portlet building tools in terms of authentication for external application.
Web Clipping's integration with the external application framework provides a fully automated mechanism to store passwords to external Web sites. All you have to do is to associate an External Application ID to the Web Clipping provider when registering the provider.
OmniPortlet allows you to store connection information when the data source is password protected. The credentials to access the data source can either be shared across all users, or saved on a per user basis. OmniPortlet is capable of storing database credentials, as well as HTTP basic authentication user name-password pairs. The credentials are stored in the secured data repository of OmniPortlet, in an Oracle database.
Java portlets can integrate with the external application framework as well as any LDAP server, such as Oracle Internet Directory, programmatically.
You can build PL/SQL portlets that enable single sign-on by using mod_osso, an authentication module on the Oracle HTTP Server. mod_osso is a simple alternative to the single sign-on SDK, used in earlier releases to integrate partner applications. mod_osso simplifies the authentication process by serving as the sole partner application to the Single Sign-On server.
PL/SQL portlets can integrate with the external application framework programmatically.
