Portlet Development Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Portlet Planning

Proper planning is essential to portlet development. A properly planned portlet structure and organizational model can provide a cohesive and consistent portal interface, flexible scalability, and high performance without requiring frequent adjustments within your production system.

This chapter focuses on planning considerations and decisions that should precede the development of your portlets. Global portal-wide planning information is provided in the Oracle WebLogic Portal Overview, which summarizes the types of issues to consider in the architecture phase across your portal environment. The various WebLogic Portal feature guides, such as the Oracle WebLogic Portal Federated Portals Guide, describe architectural issues in detail for each feature area.

This chapter includes the following sections:


Portlet Development in a Distributed Portal Team

If you will be creating portlets within an environment that includes a remote (distributed) development team, you must carefully plan your implementation. Considerations for team development include:

Team development of a WebLogic Portal web site revolves around well-designed source control and a correctly configured shared domain for development. For detailed instructions on setting up your development environment, refer to the Team Development chapter of the Production Operations Guide.


Portlets in a Non-Portal Environment

In some cases, you might want to expose portlets in a web page even though that web application is not based on WebLogic Portal. For example, you might want to expose portlets with WSRP from a producer environment that does not include any WebLogic Portal components. You might be running a Struts web application in a basic WebLogic Server domain, or a Java page flow application in a basic Workshop for WebLogic domain. In either case, WebLogic Portal is not part of the server configuration. The exposed portlets can then be consumed by remote portlets running in a regular WebLogic Portal domain.

For more information on developing portlets for a non-WebLogic Portal environment, refer to the Federated Portals Guide.


Planning Portlet Instances

In the Development phase, you use Workshop for WebLogic to create portlets and place them onto a portal. In the Staging phase, you use the Administration Console to add portlets to portal desktops. Each time you add a portlet to a desktop, you create an instance of that portlet. Portlet instances allow for multiple variations of the same portlet definition. By using portlet instances, portal users and administrators can configure multiple views of the same portlet through the use of portlet preferences, and reduce the overall number of distinct portlets; this portlet reuse improves portal performance and management efficiency. A common example of portlet instances is a stock watch portlet in which there is a single or multi-valued preference for ticker symbols such as ORCL, which would configure the portlet to display Oracle stock information.

Try to plan your portal hierarchy to reuse portlets when practical. For more information about portlet instances and how portlet instances are related to portlets in the Administration Console’s portlet library, refer to Portlet Library.



You can control access to portlet resources for two categories of users:

During the architecture phase, you plan how to organize security policies and roles, and how that fits into your system-wide security strategy. You implement your security plans by setting up delegated administration and visitor entitlements using the WebLogic Portal Administration Console.

For an overall look at managing security for your portal environment, refer to the Security Guide. Specific security considerations for feature areas are contained in those documents; for example, recommendations for security in WSRP-enabled environments are contained in the Federated Portals Guide.


Interportlet Communication

Interportlet communication (IPC) allows multiple portlets to use or react to data. You can use interportlet communication within a single portal web application, or within federated portal applications.

For more information on interportlet communication within a single portal web application, refer to Local Interportlet Communication. For more information on interportlet communication within federated portal applications, refer to the Federated Portals Guide.


Performance Planning

Try to plan for good performance within your portlet architecture to minimize the fine-tuning that is required in a production environment.

Here are some examples of performance optimizations that you can plan into your overall portal strategy:

Plan your performance optimizations before you begin developing portlets so that you can implement any pre-requisites that are required. For detailed instructions on developing high-performance portlets, refer to Optimizing Portlet Performance. For post-development WebLogic Portal performance recommendations, refer to the Performance Tuning Guide.

  Back to Top       Previous  Next