Portals

BEA WebLogic

A

Portal

ET

™

B

Portal Development Guide

Version 9.2 BETA Document Revised: April 3, 2006

Copyright Copyright © 1995-2006 BEA Systems, Inc. All Rights Reserved.

Restricted Rights Legend This software is protected by copyright, and may be protected by patent laws. No copying or other use of this software is permitted unless you have entered into a license agreement with BEA authorizing such use. This document is protected by copyright and may not be copied photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form, in whole or in part, without prior consent, in writing, from BEA Systems, Inc.

Trademarks and Service Marks

A

Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems. THE DOCUMENTATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA SYSTEMS DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE DOCUMENT IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.

B

ET

Copyright © 1995-2006 BEA Systems, Inc. All Rights Reserved. BEA, BEA JRockit, BEA WebLogic Portal, BEA WebLogic Server, BEA WebLogic Workshop, Built on BEA, Jolt, JoltBeans, SteelThread, Top End, Tuxedo, and WebLogic are registered trademarks of BEA Systems, Inc. BEA AquaLogic, BEA AquaLogic Data Services Platform, BEA AquaLogic Enterprise Security, BEA AquaLogic Interaction, BEA AquaLogic Interaction Analytics, BEA AquaLogic Interaction Collaboration, BEA AquaLogic Interaction Content Services, BEA AquaLogic Interaction Data Services, BEA AquaLogic Interaction Integration Services, BEA AquaLogic Interaction Process, BEA AquaLogic Interaction Publisher, BEA AquaLogic Interaction Studio, BEA AquaLogic Service Bus, BEA AquaLogic Service Registry, BEA Builder, BEA Campaign Manager for WebLogic, BEA eLink, BEA Kodo, BEA Liquid Data for WebLogic, BEA Manager, BEA MessageQ, BEA Salt, BEA WebLogic Commerce Server, BEA WebLogic Communications Platform, BEA WebLogic Enterprise, BEA WebLogic Enterprise Platform, BEA WebLogic Enterprise Security, BEA WebLogic Express, BEA WebLogic Integration, BEA WebLogic Java Adapter for Mainframe, BEA WebLogic JDriver, BEA WebLogic Log Central, BEA WebLogic Mobility Server, BEA WebLogic Network Gatekeeper, BEA WebLogic Personalization Server, BEA WebLogic Personal Messaging API, BEA WebLogic Platform, BEA WebLogic Portlets for Groupware Integration, BEA WebLogic Real Time, BEA WebLogic RFID Compliance Express, BEA WebLogic RFID Edge Server, BEA WebLogic RFID Enterprise Server, BEA WebLogic Server Process Edition, BEA WebLogic SIP Server, BEA WebLogic WorkGroup Edition, BEA Workshop for WebLogic Platform, BEA Workshop JSP, BEA Workshop JSP Editor, BEA Workshop Struts, BEA Workshop Studio, Dev2Dev, Liquid Computing, and Think Liquid are trademarks of BEA Systems, Inc. Accelerated Knowledge Transfer, AKT, BEA Mission Critical Support, BEA Mission Critical Support Continuum, and BEA SOA Self Assessment are service marks of BEA Systems, Inc. All other names and marks are property of their respective owners.

Contents

1. Introduction to Portals What is a Portal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 What is the Portal Framework? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Portal Development and the Portal Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

A

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Staging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

ET

Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Related Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

B

Part I. Architecture

2. Planning Your Portal

Production Operations (Propagation and Deployment) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Portal Development in a Distributed Portal Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Federated Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Administration Console Library of Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 WebLogic Portal Content Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

BEA WebLogic Portal Portal Development Guide

iii

Portals and Mobile Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Part II. Development 3. Understanding Portal Development Portal Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Portal Development Environment in Workshop for WebLogic . . . . . . . . . . . . . . . . . . . . 3-3 Portal Resources in the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 About Library Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 Content Management in Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 File-Based Portals and Streaming Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

A

Java Controls in Portals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 JSPs and JSP Tags in Portals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

ET

Page Flows in Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 Why are Page Flows Useful? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 State/Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

4. The Portal Framework

B

Framework Terms, Acronyms, and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Anatomy of a Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Portal Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Netuix Framework for Rendering Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6 Portal Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 Interacting With UI Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Backing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 Skeletons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13 Netuix File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

iv

BEA WebLogic Portal Portal Development Guide

How Portals are Rendered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16 The PortalServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16 The Portal Rendering Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

5. Setting up Your Portal Development Environment WebLogic Domain Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Portal EAR Project Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Add and Remove Projects Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 Portal Web Project Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 New Portal Web Project – Portal Web Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10

A

New Portal Web Project – Select Project Facets dialog . . . . . . . . . . . . . . . . . . . . . . 5-12 New Portal Web Project - Web Module Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14 New Portal Web Project - WebLogic Web Module Dialog . . . . . . . . . . . . . . . . . . . 5-15

ET

Portal Datasync Project Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17 Portal Datasync Project Wizard - Create New Datasync Project Dialog . . . . . . . . . 5-18 Create New Datasync Project – EAR Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19 Using the Merged Projects View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21 Running a Project on the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23

B

Customizing a Workbench Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23 Setting WebLogic Portal Preferences in Workshop for WebLogic. . . . . . . . . . . . . . . . . 5-24 Preferences in the WebLogic Portal Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24 Preferences in the General Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

6. Upgrading WebLogic Portal Projects to Version 9.2 Version 8.1 Features Not Supported in Version 9.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 Using the Import Wizard to Upgrade Version 8.1 Portal Applications. . . . . . . . . . . . . . . 6-2 Log File for Upgrade Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

BEA WebLogic Portal Portal Development Guide

v

Using the Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Upgrading Look & Feels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

7. Integrating Web Applications into Portals Integrating an Existing Web Application into Workshop for WebLogic . . . . . . . . . . . . . 7-1

8. User Interface Development with Look & Feel Features Portal Rendering and Look & Feel Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Genes & Chromosomes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 Using Genes in Look & Feels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

A

Gene Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 Creating a Chromosome and Genes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

ET

Guidelines for Using Genes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 Using the Genes API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 Creating a Look & Feel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5 The Look & Feel Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5

B

9. Developing Portals Using Workshop for WebLogic Creating a Portal File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 Add a Page to Your Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Portal Component Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5 Editing Portal Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6 Tips for Using the Properties View in the Workbench. . . . . . . . . . . . . . . . . . . . . . . . 9-7 Copying Library Module Files into a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7 Viewing Files that Override Library Module Files . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8 Deploy and View a Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8 Federating Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10 Working with URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

vi

BEA WebLogic Portal Portal Development Guide

Enabling Desktop Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

10.Creating Portals for Multiple Device Types Adding Multichannel Features to a Portal Web Application. . . . . . . . . . . . . . . . . . . . . . 10-1 Defining Multichannel Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 Building Multichannel Portals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

11.Configuring Visitor Tools Adding Visitor Tools to a New Portal Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

12.Designing Portals for Optimal Performance

A

Control Tree Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2 How the Control Tree Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2 How the Control Tree Affects Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

ET

Using Multiple Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4 Why This is a Good Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4 Design Decisions for Using Multiple Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6 Optimizing the Control Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

B

Enabling Control Tree Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7 How Tree Optimization Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10 Limitations to Using Tree Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11 Disabling Tree Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13 Pluggable Framework Cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13 Other Ways to Improve Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13 Use Entitlements Judiciously . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14 Limit User Customizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15 Optimize Page Flow Session Footprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15 Use File-Based Portals for Simple Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16 Create a Production Domain in Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17

BEA WebLogic Portal Portal Development Guide

vii

Optimize Portlet Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18

Part III. Staging 13.Creating Portal Desktops Administration Console Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2 Administration Console Library of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2 Starting and Logging In to the Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . 13-3 Opening the Administration Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3 Logging In to the Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5 Portals and Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6

A

Creating a Portal and Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7 Creating Desktop Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11

ET

Create a New Page on the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12

14.Deploying Portals to Production Part IV. Production

B

15.Creating and Managing Portals

viii

BEA WebLogic Portal Portal Development Guide

CHAPTER

1

A

Introduction to Portals

This chapter introduces portal concepts and describes how the content of this guide relates to the portal life cycle.

What is a Portal?

ET

This chapter contains the following sections:

What is the Portal Framework?

Portal Development and the Portal Life Cycle

B

Getting Started

What is a Portal?

A portal represents a web site that provides a single point of access to applications and information. From an end user perspective, a portal is a web site with pages that are organized by tabs or some other form of navigation. Each page contains a nesting of sub-pages, or one or more portlets— individual windows that display anything from static HTML content to complex web services. A page can contain multiple portlets, giving users access to different information and tools in a single place. Users can also customize their view of a portal by adding their own pages, adding portlets of their choosing, and changing the Look & Feel of the interface. Technically speaking, a portal is a container of resources and functionality that can be made available to end users. These portal views, which are called desktops in WebLogic Portal, provide the uniform resource location (URL) that users access. A portal presents diverse content and BEA WebLogic Portal Portal Development Guide

1-1

I n tr o d uct i o n t o P o r t al s

applications to users through a consistent, unified web-based interface. Portal administrators and users can customize portals, and content can be presented based on user preferences or rule-based personalization. Each portal is associated with a web application that contains all of the resources required to run portals on the web. Portals provide the following benefits to the user: Aggregation – The user can go to a single place for all content and applications. Customization – The preferences for a user determine how the portal looks and feels. Personalization – The user can obtain content that is specific to their interests and needs. Organization – The user can arrange the content and applications to make better sense of the information.

A

Integration – The user can work with multiple applications and content sources in a unified fashion. Portals typically include the following features and benefits:

ET

Search – Enterprise and web-based search facilities

Content Management – Creation, management, and delivery of content Content Repurposing – Including content from multiple disparate data sources Portals optionally include the following features and benefits:

B

Workflow – Business process management

Single Sign-On – Allows users to log on once for all applications within the portal WebLogic Portal supports development of portals through BEA Workshop for WebLogic Platform, which is a client-based tool. You can also develop portals without Workshop for WebLogic through coding in any tool of choice such as JBuilder, VI or Emacs. Portals can be written in Java or JSP, and can include JavaScript for client-side operations. Although you can create portals outside of Workshop for WebLogic, to realize the full development-time productivity gains afforded to the WebLogic Portal customer, use Workshop for WebLogic as the portal and portlet development platform. After you create the parts of a portal using Workshop for WebLogic, you assemble it into a desktop using the WebLogic Portal Administration Console. From an administrative standpoint, a portal is a container that defines a portal application. When you create a new portal using the Administration Console, you are really creating an empty portal to hold different versions of the

1-2

BEA WebLogic Portal Portal Development Guide

What is the Portal Framew ork?

portal (desktops) that can be targeted to specific users. A portal can contain one or more desktops, or views, of a portal. It is the desktops to which you add the portal resources and navigation such as books, pages, and portlets that make a dynamic portal. Each portal is associated with a web application that contains all of the resources required to run portals on the web.

What is the Portal Framework? The portal framework is the portion of WebLogic Portal that is responsible for the rendering and customization of the portal.

A

The portal framework turns a portal that you develop in Workshop for WebLogic into the portal that desktop visitors see in a browser. When you are familiar with the portal framework tools provided in WebLogic Portal, you can look at a rendered portal in a browser and understand which pieces of the underlying framework you need to modify to obtain the results you want.

ET

A detailed explanation of the portal framework components is provided in Chapter 4, “The Portal Framework.”

Portal Development and the Portal Life Cycle The creation and management of a portal flows through a portal life cycle. The portal life cycle contains four phases: Architecture

B

Development Staging

Production

The tasks described in this guide are organized according to the portal life cycle, which includes best practices and sequences for creating and updating portals. For more information about the portal life cycle, refer to the BEA WebLogic Portal Overview. Figure 1-1 shows a sampling of portal development tasks that occur at each phase.

BEA WebLogic Portal Portal Development Guide

1-3

I n tr o d uct i o n t o P o r t al s

Figure 1-1 Portals and the Four Phases of the Portal Life Cycle Architecture – Determine the basic configuration of the portal

Production – Roll out your portals to a production environment, making changes as needed

Development – Use Workshop for WebLogic to create portals, portlets, pages, and books

Architecture

ET

A

Staging – Use the WebLogic Portal Administration Console to create and configure desktops

B

During the architecture phase, you design and plan the configuration of your portal. For example, you can create a detailed specification outlining the requirements for your portal, the specific portlets you require, where those portlets will be hosted, and how they will communicate and interact with one another. You might also consider the deployment strategy for your portal. Security is another consideration for the portal architect. The chapter describing tasks within the Architecture phase include: Chapter 2, “Planning Your Portal”

Development Developers use WebLogic Workshop to create portals, portlets, pages, and books. During development, you can implement data transfer and interportlet communication strategies and consider the security of the components. In the development stage, careful attention to best practices is crucial. Wherever possible, this guide includes descriptions and instructions for adhering to these best practices. The chapters describing tasks within the Development phase include:

1-4

BEA WebLogic Portal Portal Development Guide

Po rtal Deve lopment and the Portal Life Cyc le

Chapter 3, “Understanding Portal Development” Chapter 4, “The Portal Framework” Chapter 5, “Setting up Your Portal Development Environment” Chapter 6, “Upgrading WebLogic Portal Projects to Version 9.2” Chapter 7, “Integrating Web Applications into Portals” Chapter 8, “User Interface Development with Look & Feel Features” Chapter 9, “Developing Portals Using Workshop for WebLogic” Chapter 10, “Creating Portals for Multiple Device Types”

A

Chapter 11, “Configuring Visitor Tools” Chapter 12, “Designing Portals for Optimal Performance”

ET

Staging

BEA recommends that you deploy your portal to a staging environment where it can be assembled and tested before going live. In the staging environment, you use the WebLogic Portal Administration Console to assemble and configure desktops. You also test your portal in a staging environment before propagating it to a live production system. In the testing aspect of the staging phase, there is tight iteration between staging and development until the application is ready to be released.

B

The chapters describing tasks within the Staging phase include: Chapter 13, “Creating Portal Desktops” Chapter 14, “Deploying Portals to Production”

Production A production portal is live and available to end users. A portal in production can be modified by administrators using the WebLogic Portal Administration Console and by users using Visitor Tools. For instance, an administrator might add additional portlets to a portal or reconfigure the contents of a portal. The chapter describing tasks within the Production phase is: Chapter 15, “Creating and Managing Portals”

BEA WebLogic Portal Portal Development Guide

1-5

I n tr o d uct i o n t o P o r t al s

Getting Started This section describes the basic prerequisites to using this guide and lists guides containing related information and topics.

Prerequisites In general, this guide assumes that you have performed the following prerequisite tasks before you attempt to use this guide to develop portlets: Review the Related Guides and become familiar with the basic operation of the tools used to create portals, portlets, and desktops,

A

Review the Workshop for WebLogic tutorials and documentation to become familiar with the Eclipse-based development environment and the recommended project hierarchy. Complete the tutorial Getting Started with WebLogic Portal.

ET

Related Guides

BEA recommends that you review the following guides: BEA WebLogic Portal Architecture Guide BEA WebLogic Portal Overview

BEA WebLogic Portal Portlet Development Guide

B

Whenever possible, this guide includes cross references to material in related guides.

1-6

BEA WebLogic Portal Portal Development Guide

Architecture

A

Part I

Introduction TBD.

B

ET

For a view of how the tasks in this section relate to the overall portal life cycle, refer to the BEA WebLogic Portal Overview.

Part I includes the following chapters: Chapter 2, “Planning Your Portal”

BEA WebLogic Portal Portal Development Guide

A ET B 1-2

BEA WebLogic Portal Portal Development Guide

CHAPTER

2

A

Planning Your Portal

ET

Proper planning is essential to portal development. While bypassing planning and moving straight to development might reap short-term benefits in development speed, your projects may suffer from confusion and inconsistency, have poor scalability and performance, and require more time to manage. The planning and design tasks that mark the architecture phase occur at multiple levels: the domain and enterprise application, the web application, and the individual WebLogic Portal feature areas.

B

Global inter-portal planning information is provided in the BEA WebLogic Portal Overview, which summarizes the types of issues to consider in the architecture phase at all levels. The various WebLogic Portal feature guides describe planning issues in detail for each feature area. This chapter includes the following sections: Production Operations (Propagation and Deployment) Portal Development in a Distributed Portal Team Federated Portals Administration Console Library of Resources Internationalization Security WebLogic Portal Content Repository

BEA WebLogic Portal Portal Development Guide

2-1

Pl an nin g You r Po rt al

Performance Portals and Mobile Devices

Production Operations (Propagation and Deployment)

ET

A

Production operations encompasses the tools, procedures, methodologies, and best practices that provide the backbone for managing the portal life cycle, from portal development to staging and testing to live production environments. As Figure 2-1 shows, portals are typically developed in a team development environment by developers using WebLogic Workshop. Portal components are then moved to a staging environment, where portal administrators use the WebLogic Portal Administration Console to create desktops, add entitlements, set up content repositories, and perform testing. The production environment is the live environment, where users access and interact with portal applications. The arrows between environments indicate that you can move portals and portal resources back and forth between each of these environments using utilities provided by BEA. WebLogic Portal Utilities such as the Propagation Utility and the Export/Import Utility allow you to easily and reliably move and merge changes between environments.

B

Figure 2-1 Typical WebLogic Portal Environments

Just as you consider the architecture of a network or a software system, also consider and carefully plan how you will address production operations for your portal system. It is important to consider your particular portal system configuration, how your development team is organized, how you will test and configure portals, how your server is configured, and how you plan to manage the life cycle of your portal applications. The Production Operations Guide describes the specific methodologies, tools, and best practices to help you achieve the goal of creating solid, manageable environments for portal development, staging, and production.

2-2

BEA WebLogic Portal Portal Development Guide

P o r ta l D e v e l o p m e n t i n a D i s tr i b ut e d P o rt a l T e am

Portal Development in a Distributed Portal Team If you will be creating portals within an environment that includes a remote (distributed) development team, you must carefully plan your implementation. Considerations for team development include: Use of shared resources – You share common portlets, such as the login portlet. Sharing a common domain – Several techniques exist for sharing a common domain among team members with different BEA home directories. Integrating remotely developed portlets into the portal – Settings that are common to the portal application must match across the entire development project.

ET

Federated Portals

A

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 BEA WebLogic Portal Production Operations User’s Guide.

A federated portal is a portal that includes remotely distributed resources, such as remote portlets. These remote resources are collected and brought together at runtime to a portal application called a consumer, which presents the federated portal to end users.

B

To implement a federated portal environment, you need to make decisions about how to organize your applications. For example, rather than bundling all of a portal’s portlets into a single application, you can deploy portlets in separate web applications running on remote systems while the federated portal consumes them using WSRP. Because the federated portal is decoupled from its portlets, you do not need to redeploy the portal every time a portlet changes. For most WebLogic Portal projects, this decoupling represents an immediate and significant savings in time and money. The Federation Guide provides detailed instructions on how to set up a federated portal environment.

Administration Console Library of Resources When you create a new desktop using the Administration Console, you can use an existing portal template. Using a template means that you take the portal resources for your desktop directly from a .portal file that was created in Workshop for WebLogic. When you create a desktop,

BEA WebLogic Portal Portal Development Guide

2-3

Pl an nin g You r Po rt al

the portal assets are copied from the .portal file into a database, and surfaced in both the Library and Desktop trees of the Administration Console. Taking the assets from a new desktop instance and placing them in the Library is called disassembling. Plan your implementation to make the best use of this WebLogic Portal functionality. Refer to the Production Operations Guide for more details about disassembling and decoupling of resources in the Administration Console.

Internationalization Pending - Internationalization documentation is TBD.

Security

A

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

Portal visitors – You control access to portal resources using visitor entitlements. Visitor access is determined based on visitor entitlement roles.

ET

Portal administrators – You control portal resource management capabilities using delegated administration. Administrative access is determined based on delegated administration roles.

B

During the Architecture phase, you plan how to organize security policies and roles, and how that fits into your overall security strategy. 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 BEA WebLogic Portal Federated Portals Guide.

WebLogic Portal Content Repository WebLogic Portal’s content management system allows you to store content, track its progress, and incorporate content in your portal applications. It provides an easy integration between creating content and delivering that content to your users. Content creators can use WebLogic Portal’s repositories to create content and portal developers use the content API and JSP tools to deliver content to portal visitors. You can use either a BEA repository or a third-party repository with your portal. BEA provides a set of Java classes called the WebLogic Portal Content Service Provider Interface (SPI), which many enterprise content management (ECM) vendors have implemented. If the vendor of your ECM system has implemented the SPI, then adding your repository to the Virtual Content

2-4

BEA WebLogic Portal Portal Development Guide

Performan ce

Repository will simply require a configuration within the WebLogic Portal Administration Console. If your vendor has not implemented BEA's SPI, then you can do so yourself. When you use a third-party repository to store content, you also continue to use that repository’s content tools to add and modify content, or you might be able to use BEA's content tools, depending on your desired implementation. To decide whether to use BEA’s repository with your portal, compare the features provided by WebLogic Portal and other vendors. For more information about the features that WebLogic Portal‘s content management system provides, refer to the Content Management Guide.

Performance

A

Try to plan for good performance within your portal architecture to minimize the fine-tuning that is required in a production environment. Many performance issues can be resolved and significant performance improvement can be realized by making just a few critical design decisions.

ET

Here are some examples of performance optimizations that you can plan into your overall portal strategy: Enable control tree optimization.

Use entitlements judiciously; too many can impact performance. Avoid the temptation of granting a different role to every user. Instead, use WebLogic Portal’s personalization capabilities to focus the user experience.

B

If your portal is small or relies only on static resources, you might experience some performance boost by using a file-based portal rather than a streaming portal. If you are using Page Flows in your portal, ensure their session footprint is optimized to deliver the best performance. Develop your portal in a production domain. This way, you can actually see what issues might arise once the portal is propagated to production. Plan performance optimizations before you begin developing your portal so that you can implement any pre-requisites that are required. For detailed instructions on developing a high-performance portal, refer to Chapter 12, “Designing Portals for Optimal Performance.” For overall WebLogic Portal performance recommendations that you can implement in a production environment, refer to the BEA WebLogic Portal Performance Tuning Guide.

BEA WebLogic Portal Portal Development Guide

2-5

Pl an nin g You r Po rt al

Portals and Mobile Devices WebLogic Portal can provide specific Portal views based on device and browser detection, allowing a single Portal application to serve content to diverse browsers and devices. The Portal’s campaign and personalization features can also detect device types, directing users to device- or channel-specific business processes and content (or restrict access). Device specific content operates in tandem with the portal user interface to provide device-specific views of applications.

B

ET

A

For instructions on how to implement your portal for use on mobile devices, refer to Chapter 10, “Creating Portals for Multiple Device Types.”

2-6

BEA WebLogic Portal Portal Development Guide

A

Part II Development

B

ET

Introduction TBD.

For a view of how the tasks in this section relate to the overall portal life cycle, refer to the BEA WebLogic Portal Overview. Part II includes the following chapters: Chapter 3, “Understanding Portal Development” Chapter 4, “The Portal Framework”

BEA WebLogic Portal Portal Development Guide

Chapter 5, “Setting up Your Portal Development Environment” Chapter 6, “Upgrading Version 8.1 WebLogic Portal Projects to Version 9.2” Chapter 7, “Integrating Web Applications into Portals” Chapter 8, “User Interface Development with Look & Feel Features” Chapter 9, “Developing Portals Using Workshop for WebLogic” Chapter 10, “Creating Portals for Multiple Device Types” Chapter 11, “Configuring Visitor Tools”

B

ET

A

Chapter 12, “Designing Portals for Optimal Performance”

2-2

BEA WebLogic Portal Portal Development Guide

CHAPTER

3

A

Understanding Portal Development

Some sections are not updated for Version 9.2

ET

This chapter provides conceptual and reference information that you might find useful as you begin to develop portals. This chapter contains the following sections: Portal Hierarchy

Portal Development Environment in Workshop for WebLogic Portal Resources in the Database

B

About Library Modules

Content Management in Portals File-Based Portals and Streaming Portals Java Controls in Portals JSPs and JSP Tags in Portals Page Flows in Portals State/Session Management

BEA WebLogic Portal Portlet Development Guide

3-1

Understanding Portal Devel opme nt

Portal Hierarchy Whether you are building portal resources and templates in WebLogic Workshop or creating and administering portals with the WebLogic Administration Portal, you work with individual components that are then unified by the portal framework. Figure 3-1 illustrates the flexibility and extensibility of the WebLogic Portal architecture. In the figure, the indicator (1...n) means one or more, and (0...n) means zero or more. For example, a portal can contain one or more desktops. For resources that occur only once, like Look & Feel and Shell, you can still develop multiple versions even though only one at a time is allowed. For more detailed information about the hierarchy depicted here, refer to Chapter 4, “The Portal Framework.”

B

ET

A

Figure 3-1 Portal Hierarchy

3-2

BEA WebLogic Portal Portlet Development Guide

Po rtal Deve lopment Env iro nment in Wo rk sho p for WebL ogic

Portal Development Environment in Workshop for WebLogic BEA Workshop for WebLogic Platform is implemented as a plugin to the Eclipse Platform, specifically including the Eclipse Workbench, Java Development Tools (JDT), a customized version of the Web Tools Platform Project (WTP), and a Workshop for WebLogic-specific plugin. Specific instructions on using the generic Eclipse Workbench are available at the Eclipse web site. WebLogic Portal provides additional features the workbench to facilitate portal and portlet development. Before continuing, familiarize yourself with the features of Workshop for WebLogic by reviewing the tutorial “Getting Started with BEA Workshop for WebLogic Platform,” which is available in the Help under BEA Workshop for WebLogic Programmer’s Guide.

A

This section describes WebLogic Portal features in the workbench from the perspective of the portal developer.

B

ET

WebLogic Portal uses a combination of standard Eclipse and Workshop for WebLogic views, plus its own customized view, to simplify portal construction. Figure 3-2 shows an example of how your Workshop for WebLogic workbench might look during development of a portal.

BEA WebLogic Portal Portlet Development Guide

3-3

Understanding Portal Devel opme nt

ET

A

Figure 3-2 WebLogic Portal Portal Displayed in Workshop for WebLogic Portal Perspective

B

1. Package Explorer view – Shows the hierarchy of directories for the open project, and the WebLogic Portal library modules being referenced by the project. 2. Merged Projects view – Shows a combined list of the actual files and referenced files in your project; library module files are shown in italic text. This view provides important reference information for your portal development project. 3. Editor – Shows the primary visual working area for designing a portal. 4. Properties view – Shows properties for the portal component that is currently selected and allows you to set or change them. 5. Palette view – Shows more detailed information that you can manipulate, based on the current selection in the editor.

3-4

BEA WebLogic Portal Portlet Development Guide

P o r ta l R e s o u rc e s i n t he D at a ba s e

6. Outline view – Shows the components of the portlet interface in a hierarchical structure. To see an example using the Outline view with style sheet development, refer to Chapter 8, “User Interface Development with Look & Feel Features.”

Portal Resources in the Database A database stores information for the WebLogic Portal application; separate database tables exist to store portal-specific resources including the following: Definitions – Portal definition properties including creation date, content URI, whether the portal is forkable or cacheable, whether it has a backing file, and so on. TBD

About Library Modules

A

For detailed information about the content of WebLogic Portal database tables, refer to the BEA WebLogic Portal Database Administration Guide.

ET

WebLogic Portal library modules are packages of WebLogic Portal-specific resources that are shared throughout the product. Library modules let you deploy and use a single set of resources rather than having to duplicate those resources in every EAR project and portal web project. BEA recommends that you use library modules because of their significant advantages in source control, file sharing, and patch application.

B

You can override a resource in library modules by copying it from the library module into your portal web project and then customizing it. For example, if you want the default Look & Feel to look different in a particular portal web project, you can copy the default Look & Feel from the library module into the portal web project and make your modifications. When you copy a resource, WebLogic Portal puts that resource into the “matching” location within your portal web project. When you deploy the project, WebLogic Server sees the copied resource and uses that instance instead of the resource in the library module. For information on how to copy library module resources into a project, refer to “Copying Library Module Files into a Project” on page 9-7. Caution: If you copy library module 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.

BEA WebLogic Portal Portlet Development Guide

3-5

Understanding Portal Devel opme nt

Content Management in Portals Managing portal content typically falls into two categories: Personalization – Dynamic content that you specify using a set of criteria Customization – Content and appearance changes that users can make, if you allow it Personalization is primarily security-related. You control who sees what, limiting access to systems and resources. Personalization criteria can be applied at these levels: portlet, book, page, desktop, or for the entire portal.

A

Personalized content is content that matches a particular context, generally centered around a user. Personalization takes into account information contained in the context to correctly generate search queries that retrieve the content most appropriate to the context. For example, if you have red, green, and blue images, and you have determined that a particular user prefers green, you would probably want to display green images to the user.

ET

In WebLogic Portal, the context to match against includes at least the user's profile, the user's current request, the user's current session, and the current date and time. Additionally, WebLogic Portal supports writing business rules that can classify users into various segments; these segments support the same contextual information. For example, you could define a business rule that defines who your “Premier Users” are. In some cases, you can also use these segments when personalizing content.

B

Personalization and campaign development involves interrelated tasks. For example, if you want to present users with personalized content in a campaign, you must perform the tasks summarized here: 1. Add content to the Virtual Content Repository. 2. Create one or more placeholders that display the content. 3. Set up properties (such as a user profile or session properties) that are used to define the conditions under which users are targeted with campaign content. 4. Create the campaign. For more information about personalized portals, refer to the BEA WebLogic Portal Interaction Management Guide.

3-6

BEA WebLogic Portal Portlet Development Guide

F i l e - B a s e d Po rt al s a nd St r e a mi ng Po rt a l s

File-Based Portals and Streaming Portals The .portal file you create in WebLogic Workshop is a template. In this template you create books, pages and portlets and define defaults for them. When you view the .portal file with your browser the portal is rendered in “single file mode,” meaning that you are viewing the portal from your file system as opposed to a database. The .portal file's XML is parsed and the rendered portal is returned to the browser. The creation and use of a .portal is intended for development purposes, but you can access a .portal file in production. Because there is no database involved you cannot take advantage of features such as user customization or entitlements. Once you have created a .portal file you can use it to create desktops for a production environment, using the WebLogic Portal Administration Console.

A

A desktop is a particular view of a portal that visitors access. A portal can be made up of multiple desktops, making the portal a container for desktops. A desktop contains all the portlets, content, shells, layouts, and Look & Feel elements necessary to create individual user views of a portal.

B

ET

When you create a desktop based on the .portal file in the WebLogic Portal Administration Console, the .portal and its resources are placed into the database. The settings in the .portal file, such as the Look & Feel, serve as defaults to the desktop. Once a new desktop is created from a .portal template, the desktop is decoupled from the template, and modifications to the .portal file do not affect the desktop, and vice versa. For example, when you change a desktop's Look & Feel in the WebLogic Portal Administration Console, the change is made only to the desktop, not to the original .portal file. When you view a desktop with a browser it is rendered in “streaming mode” (from the database). Now that a database is involved, desktop customizations can be saved and delegated administration and entitlements can be set on portal resources. System performance is not significantly different between streamed portals and file-based portals. The advantages of each portal type depend more on how many portlets you plan to produce, the functionality you want to provide portal end users, and how you want to manage your portal. Table 3-1 compares streamed and file-based portals in more detail:

BEA WebLogic Portal Portlet Development Guide

3-7

Understanding Portal Devel opme nt

Table 3-1 Performance Comparison of File-Based Portals and Streaming Portals File-Based Portals

Streamed Portals

Adding Entitlements

Run-time check only

Yes—More easily set and configured

Setting Preferences

In portal definition

For individual portal instances

Number of Instances

Limited

More than file-based portals

No

Yes

Customization

No

Yes (through Visitor Tools and the Administration Console)

Internationalization

Difficult—requires changes to skeleton files.

Easier

Performance

Slight advantage

Propagation (from test to production environments)

Easy to accomplish by moving the .portal file

Requires proper planning but easy to implement with Propagation feature.

Development Process

Easiest

More complex

A

Portal Feature

ET

Slightly less than file-based portals

B

For performance-related recommendations, refer to “Use File-Based Portals for Simple Applications” on page 12-16.

Java Controls in Portals TBD

JSPs and JSP Tags in Portals WebLogic Portal provides JSP tags that you can use within JSPs. Portlets can use JSPs as their content nodes, enabling reuse and facilitating personalization and other programmatic functionality. You can create JSPs with Workshop for WebLogic to provide a structure for other elements to be added to a portlet.

3-8

BEA WebLogic Portal Portlet Development Guide

P ag e F l o ws i n Po rt a l s

To view the JSP tags available as you develop a portal, select Window > Show View > JSP Design Palette. For detailed information about using JSPs and JSP tags within portals, see .

Page Flows in Portals Java Page Flow is a feature set built on a Struts-based web application programming model. Java Page Flow leverages the power and extensibility of Struts while also eliminating the difficulties and challenges of building Struts-based applications. Java Page Flow features include runtime support for the web application programming model and tools that enable developers to quickly and easily build applications based upon the model.

A

Basically, a Page Flow is a directory of web application files that work together to implement a user interface feature. For example, a page flow could implement a web application’s user registration wizard feature.

ET

You can manage state, data and navigation flow between pages using Java Page Flow (JPF) files. Page flows use the same programming model as other Workshop for WebLogic applications, include one-click generation of Java Controls, and offer a standard Struts framework plug-in. JPFs also offer “WYSIWYG” development with a two-way JSP/HTML editor. JPFs can bind to data, web services using controls & data binding tags, drag and drop controls and data to create forms and data-bound web pages. For more information on page flows in portals, refer to .

B

Why are Page Flows Useful?

You might be familiar with the Struts framework, which is a part of the Jakarta™ Project by the Apache Software Foundation™. Struts is an open-source framework for building web applications based on the model-view-controller (MVC) design paradigm. Workshop for WebLogic page flows extend the Struts framework to provide a simplified development model with numerous additional features, se described in the following sections.

Ease of Use Typically, native Struts development requires management and synchronization of multiple files for each Action, form bean, and the Struts configuration file. Even in the presence of tools that help edit these files, developers are still exposed to all the underlying plumbing, objects, and configuration details. Page flows provide a dramatically simpler, single-file programming model that allows you to focus on the code you care about, see a visual representation of the overall

BEA WebLogic Portal Portlet Development Guide

3-9

Understanding Portal Devel opme nt

application flow, and easily navigate between pages, actions, and form beans. Page flows also provide a number of wizards to automate common tasks and visualize tag libraries. Furthermore, page flows provide key programming model benefits like thread safety. As a developer, this means that you can be insulated from some of the complexities that are pervasive in other web development models today like Struts and servlets. The result is that page flows enable you to become immediately productive in building sophisticated web applications, without the learning curve typically associated with Struts.

Nested Page Flows

State Management

ET

A

Struts provides a useful framework for smaller applications, but has trouble scaling to larger applications. Every page and action is referenced from a single configuration file, and the manageability of applications and projects quickly degrades as the size of the application increases. But with the nesting feature of page flows, you can easily create smaller nested applications that are linked together, helping to enforce a modular design paradigm and supporting larger team development projects. Importantly, nested page flows automatically manage session state as a user moves between them, ensuring that the minimum possible level of system resources is used.

B

Page flows make state management easy. You can put data in session state simply by using a variable in your JPF controller class, unlike with Struts action classes. Or you can easily pass data (as Java beans) to individual pages. Data stored in the session state is automatically freed as a user leaves the page flow for efficient use of session data.

Rich Data Binding Features

The WebLogic Workshop data binding tags and wizards make it easy to create rich, dynamic pages within a page flow. These features enable binding of user interface (UI) components to numerous data contexts (not just limited to form beans) and the data can come from any source: a database, a web service, an EJB, a custom application, and so on. In the IDE, you can drag-and-drop the data binding tags to your JSP page and bind to data, including complex types such as method invocations, repeating data, and grids. For more information, see Using Data Binding in Page Flows and Presenting Complex Data Sets in JSPs.

Service-oriented Design with Java Controls Page flows have full support for Java controls, a simple programming model abstraction for accessing enterprise resources and packaging business logic. Java controls give developers

3-10

BEA WebLogic Portal Portlet Development Guide

P ag e F l o ws i n Po rt a l s

access to the powerful features of the J2EE platform (security, transactions, asynchrony) in a simple, graphical environment with methods, events and properties, and enable developers to build web applications conforming to best practices for service-oriented architecture. For more information, see Tutorial: Java Control.

Integration with Portal Have a page flow? You can easily also have a portlet! Page flow applications can be instantly turned into portlets using the New Portlet Wizard. For more information, see the Portlet Development Guide.

Strong Data Typing

Powerful Exception Handling

A

Struts treats all data as a String, making it difficult to work with rich form data. Page Flows, on the other hand, allow developers much easier access to strongly-typed data, making it a lot easier to work with form information.

B

ET

You can handle exceptions by pointing to local actions in your page flows, Page Flows, and handle not-logged-in errors globally across a set of page flows. This makes it much easier to manage errors and centralized login processes for your entire application versus managing a cloud of exception handler classes in Struts. WebLogic Workshop provides a number of exception types that represent common exception scenarios for page flow applications, such as ActionNotFoundException, LoginExpiredException, and UnfulfilledRolesException. For more information, see Handling Exceptions in Page Flows.

Iterative Development Experience With the WebLogic Workshop IDE and page flows, you do not need to go through the tedious development cycle of edit, build, deploy, and test. Simply make a change in the IDE and click the Run button. The WebLogic Workshop model for automated deployment and integrated testing displays the results of your code change immediately. Plus, more errors are caught up-front through the WebLogic Workshop page flow compiler, instead of discovering the errors at runtime through exceptions or unintended behavior.

Built on the Open-source Struts Framework While page flows provide a number of compelling advantages relative to Struts, keep in mind that page flows are based on Struts. This means that page flows can interoperate with existing Struts applications. You can always use the Struts Merge feature of page flows to obtain full access to

BEA WebLogic Portal Portlet Development Guide

3-11

Understanding Portal Devel opme nt

underlying Struts artifacts and their configuration details. And page flows can interoperate with existing Struts applications, with both residing in the same web project. Also, with the page flow portability kit, you can run a page flow application on Apache Tomcat™ and any J2EE-compliant Servlet/JSP 2.3 container. For more information about this kit, see the BEA dev2dev.bea.com web site.

State/Session Management

B

ET

A

WebLogic Portal provides multiple mechanisms for managing state, including the HTTP Session, HTTP Request and Sessions. WebLogic Portal’s Java Page Flow also provides flexible, powerful state management capabilities within a Struts-based framework. Page Flow state management bridges the chasm between request and session state management. For many projects the request lifetime is too short and the session lifetime too long and heavy to meet the needs of the application. With Page Flow, state lifetime lasts only as long as necessary.

3-12

BEA WebLogic Portal Portlet Development Guide

CHAPTER

4

This chapter will be reorganized for GA

A

The Portal Framework

ET

The portal framework is the portion of WebLogic Portal that is responsible for the rendering and customization of the portal. The portal framework turns a portal that you develop in Workshop for WebLogic into the portal that web site visitors see in a browser. When you are familiar with the portal framework tools provided in WebLogic Portal, you can look at a rendered portal in a browser and understand which pieces of the underlying framework you need to modify to obtain the results you want.

B

The portal framework employs several technologies in defining the visual appearance of the overall portal page. Out of the box, the portal framework provides a standard set of Look & Feels and portal layouts. These Look & Feels and layouts are based on standard web technologies – primarily HTML and Cascading Style Sheets (CSS). The Look & Feels and layout mechanisms in WebLogic Portal are XML-based, and are extensible so that you can define new, unique portal structures that meet your particular needs. This chapter is intended to give a detailed description of the technical underpinnings of the portal framework. Before reading this chapter you should already be familiar with the concepts described in the Portal Overview document and in Chapter 3, “Understanding Portal Development.” This section discusses only portal framework and does not directly describe the interaction with Workshop for WebLogic Platform, the WebLogic Portal Administration Console or any of the other features that come with WebLogic Portal; namely: Personalization, Campaigns, Content Management, Commerce Components, Entitlements and User Management.

BEA WebLogic Portal Portal Development Guide

4-1

The Portal Frame work

This chapter contains the following sections: Framework Terms, Acronyms, and Abbreviations Anatomy of a Portal Netuix Framework for Rendering Applications Interacting With UI Controls Netuix File Structure How Portals are Rendered

Framework Terms, Acronyms, and Abbreviations

A

It is important that we first define a set of terminology, as these terms occur throughout the document. Please take the time to become familiar with these concepts. Netui

Netuix

ET

Also called Page Flows, a programming model for building model 2 type applications. Netui is built on top of the popular Struts framework.

B

An XML framework for rendering applications. Netuix was originally contrived as an extension to Netui. However, today netuix is no longer based on Netui nor dependant on it. They are completely different technologies. Only the names are similar. With that said, netuix can seamlessly host netui applications. Customization Customization is the term used to describe Administrators and End Users making modifications to a desktop. Normally this is done through the Administration tools or the Visitor Tools web application. However, these APIs can be called directly from within the developer’s code. For additional information on these API refer to the Javadoc. The API provides all the CRUD operations needed to modify a desktop and all of its components (Portlets, Books, Pages, Menus, and so on). Customization is different from Personalization. With Customization, someone is making a conscious decision to change the makeup of the desktop. With Personalization, changes are made based on rules and behavior (display an ad for Broncos tickets because it’s Friday and the visitor lives in Denver). Portal Framework The portion of Weblogic Portal that is responsible for the rendering and Customization of the portal–what this chapter is all about. 4-2

BEA WebLogic Portal Portal Development Guide

An at o m y o f a P o r ta l

Light Portal (file-based portal) A stripped down version of WebLogic Portal that does not deploy any EJBs or database. The light portal supports all the functionality in the portal framework with the exception of customization. Light Portal can only render portal files, it cannot go to the database for a customized desktop. Light Portal rendering occurs in Workshop for WebLogic in the development environment, but you can use file-based rendering in production systems also. UIControl A netuix user interface control, not to be confused with business controls in Workshop for WebLogic Platform. Each element in the XML document (.portal, .portal, .shell, .layout, .laf and .menu) represents an instance of a UI control. Typical controls are Books, Pages, Menus, Portlets, and so on.

ET

A

Library The library is a home for a set of public controls that are not associated with a desktop. In other words Books, Pages, Portlets, can be created and modified outside the scope of a desktop and then later added to a desktop. Changes to objects in the library are cascade down through the desktops and user customizations.

Anatomy of a Portal

In WebLogic Portal, a portal definition is a single XML file. The XML file is created automatically as you build a portal with the Portal Designer that is provided as part of the Workshop for WebLogic Platform Portal Extensions.

B

Portal Components

The portal file contains all the components that make up that particular instance of the portal, such as books, pages, portlets, and look and feel components. Many components have a hierarchical relationship to each other. For example, a book contains pages and pages contain portlets.Following are descriptions of the components that make up a portal interface.

Desktop A desktop is an audience specific view of portal components. It contains the portal header, footer, and body. The body contains the bulk of the portal content: books, pages, portlets, and look and feel elements. A portal can support one or more desktops. After a portal administrator sets entitlements on the desktop and makes it ready for public consumption, the desktop is the view

BEA WebLogic Portal Portal Development Guide

4-3

The Portal Frame work

of the portal accessed by end users. From there, users may configure their own views through customization of the desktop. Think of a desktop as a user view of a web site or a portal, exposing a different set of information or tools based on user context. For example, each department in an organization (Human Resources, Accounting, Legal, Sales) can define a portal desktop containing its own portlets, navigation, and look and feel, yet these desktops are all supported by a single portal definition.

Shell A desktop's header and footer, controlled by a portal shell (.shell file), are the areas that are typically above and below the main body. These areas usually display such things as personalized content, banner graphics, legal notices, and related links.

A

A shell represents the rendered area surrounding a portal desktop's main content area (books, pages, and portlets) and controls the content that appears in a desktop's header and footer regions. Shells include the header and a footer along with optional components, such as a navigation column on the left or right side. When a portal is accessed by a user, each of the components in the shell are rendered to form the frame that contains the books, pages, and portlets.

ET

You can configure a shell to use specific JSPs or HTML files to display content—especially personalized content—in a header or footer. Each set of different header/footer combinations requires a new shell.

Book

B

A Book is a component that provides high-level content organization and navigation. Books contains pages or other books, providing a mechanism for hierarchical nesting of pages and content. Books are identified by a control such as a tab set. A Book aggregates a set of navigables; that is, a Book or a Page (or, from a code standpoint, an interface that Books and Pages implement). A Book can have an optional menu control that provides navigation among its navigables.

Page Pages contain the portlets that display the actual portal content. Pages can also contain books and other pages. Pages are identified by a control such as a tab set. A Page is used to display a set of Placeables; that is a Portlet or Book. A Page layout has one or more Placeholders (see Layouts and Placeholders) which can host zero or more Placeables.

4-4

BEA WebLogic Portal Portal Development Guide

An at o m y o f a P o r ta l

Menus Menus are optional components that are loosely coupled to books and pages. A menu is responsible for displaying some type of navigation component, whether it is a set of tabs, a set of links, or some tree structure. The menu fires PageChangeEvents that the Pages themselves listen to and activate accordingly. WebLogic Portal provides two types of menus: single-level and multi-level. You can create you own menus by using JSPs and the tag, or from a backing file call the setupPageChangeEvent() method an a Book, Page or Portlet backing context before the preRender method.

Single-Level Menu

A

Provides a single row of tabs for the book’s immediate pages and child books.

Multi-Level Menu

ET

Recursively provides a hierarchical menu for all the books and pages contained within a book. This menu does not stop at the first set of children. It continues down the tree. If the parent book uses a multi-level menu, then the child books should not use a menu as the multi-level menu covers them.

Layout and Placeholder

Layouts and Placeholders (not to be confused with personalization placeholders) are used to structure the way portlets and books are displayed on a page.

B

A layout is an HTML table definition used by a page to determine the physical locations of portlets on the page. Administrators and users can choose different available layouts for pages. Placeholders are the individual cells in a layout in which portlets are placed. WebLogic Portal ships with some predefined layouts and the ability to create your own custom layouts. If the supplied layouts do not meet your needs, you can create your own custom layout.

Portlet Portlets are the windows that surface your applications, information, and business processes. They can contain anything from static HTML content to Java Controls to complex web services and process-heavy applications. Portlets can communicate with each other and take part in Java Page Flows that use events to determine a user's path through an application. You can have multiple portlets on a page. You can also have multiple instances of a single Portlet. For example, you can put instances of a portlet on multiple pages; so that if users don't have rights to view one

BEA WebLogic Portal Portal Development Guide

4-5

The Portal Frame work

page with that portlet on it, they can see the portlet on a page they do have rights to view. Portlets can have different modes, such as minimize, maximize, edit, delete, configure, and help, selectable from their title bars. Portlets are used as windows to host many different types of applications. As of this writing the applications can be any one of following: HTML pages, JSP files, JSF files, .pinc files, Page Flows, Struts, JSR 168 Portlets, and WSRP remote (or “proxy”) portlets.

Netuix Framework for Rendering Applications

A

As stated earlier, netuix is an XML framework for rendering applications, whether these applications look like portals or not. Many customers who use our product today create applications from our framework that look nothing like a portal. Typically when people think of portals they think of “My Yahoo!”. While many applications developed with netuix look like My Yahoo!, many do not.

ET

A netuix application is represented by one or more XML documents, the most familiar being the .portal file (an XML file with a .portal extension). This portal file may or may not include other portal include files, called .pinc files for short (files with the extension .pinc). Just like a JSP can include other JSP files to distribute functionality, a portal file can include other portal files.

B

A .pinc file is different from a portal file in that a portal includes the root elements or controls while the .pinc file does not. We will discuss this in more detail later. However, for this discussion the portal file is the parent, and it can in turn include one or more .pinc files, which in turn can include other .pinc files. One other important note: a .pinc file must begin with a Book or a Page element as the root element. More on what Books and Pages are in a bit. In the portal file, you can think of each element representing an instance of a UI control. (UIControls are not to be confused with business controls in Workshop.)These controls are wired in a hierarchical tree. In other words, each control has a parent and zero or more children. The controls can discover each other at runtime and can modify the tree by adding new children or removing existing children. All controls run through a life cycle (a set of methods called on the control in a particular order). All the methods are called in turn in a depth first order. To best illustrate this, let’s walk through the sequence of events that happen when a person requests a portal in single file mode from the browser. But before we do that, we first need to cover a few architectural issues with the portal framework. All requests for a portal or desktop come in through the PortalServlet. The PortalServlet is registered in the web.xml file under the url-patterns appmanager and *.portal. If the PortalServlet detects a request ending with .portal it knows the request is for a locale file and does not need to go to the persistence API for the XML.

4-6

BEA WebLogic Portal Portal Development Guide

Netuix Framewo rk for Rendering Applic ations

The first thing the PortalServlet must do is parse the XML file (.portal) and generate a control tree from it. Every element in the portal file represents a control in the control tree, and every attribute on the element represents an instance variable on the control. The same hierarchy is maintained in the XML document as in the control tree. A control is simply a Java class that extends another Java class, namely the UIControl class. In this release we do not explicitly expose controls to developers, but developers can interact with the controls using backing files, context, and skeleton JSPs. This is discussed later. Note: The PortalServlet doesn’t actually parse the XML document on each request. A lot of caching and magic is going on behind the scenes to obtain the desired performance for the enterprise applications.

init() loadState() handlePostbackData() preRender() saveState() render() dispose()

ET

raiseChangeEvents()

A

Once the control tree is built and all the instance variables are set on the controls, the control tree is run through its life cycle. The life cycle can be thought of as a set of methods on the controls that are called on in a well-defined order. The life cycle methods are as follows:

B

These methods are called in depth first order. In other words, all the init() methods are called, followed by the loadState() methods, and so on. They are also called depth first. Example, given the following control tree, the order in which the init() method would be called is: C1, C2, C5, C3, C6, C7, C4, then the loadState() method would be called in the same order, and so on. The last method to be called would be C4’s dispose():

BEA WebLogic Portal Portal Development Guide

4-7

The Portal Frame work

Portal Controls This section describes all the netuix controls that make up the portal framework. The control relationship is driven by the XML schema definition controls-netuix-1_0_0.xsd. WebLogic Portal has two entities commonly referred to as “controls”: the UI controls discussed in this section and the Workshop—or “business”—controls described in the Controls Guide. Business controls encapsulate certain programming logic and facilitate developing portal applications, particularly Java Page Flows. Do not confuse them with the UI controls described in this section.

A

Many of the XML files described in Netuix File Structure represent UI controls, the key Netuix feature. As the filenames might suggest, UI controls create the components of the portal user interface; for example, the books, pages, and portlets that comprise the portal. This section describes these Netuix controls.

Desktop

ET

The Desktop control is the parent control that hosts all the other netuix controls. Every portal must have one Desktop control. The Desktop control actually provides little functionality above and beyond entitlement checking and a place to go to discover other controls.

Windows

B

The most important use of the Desktop control from a developer perspective is that it has a PresentationContext that can be traversed to obtain references to all the child controls, like books, pages, and portlets.

A Window control provides functionality similar to the windowing concept on your computer. Windows support States and Modes. States affect the rendering of the Window, like minimize, maximize, float, and delete. Modes affect the content, like Edit and Help. (Custom modes are also supported.) Windows can also act as a container for other Windows. For example, a book can contain a page. All Window controls must have a Content control. The Content control is responsible for hosting the actual content inside the window. The Window control is an abstract class that is one of the three derived classes that must be used in the portal. These derived classes are: Books, Pages and Portlets. The figure below shows the relationship between Windows, Books, Pages and Portlets.

4-8

BEA WebLogic Portal Portal Development Guide

Netuix Framewo rk for Rendering Applic ations

B

Book

ET

A

Figure 4-1 Window, Book, Page, and Portlet Hierarchy Example

A Book aggregates a set of navigables. A navigable is a Book or a Page. A Book may have an optional menu control that provides navigation among navigables. From a code standpoint, Navigable is an interface that Book and Page implement.

Page A page is used to display a set of Placeables. A Placeable is a Portlet or Book. The Page has a layout which has one or more Placeholders which can host zero or more Placeables.

Portlet Portlets are used as windows to host may different types of applications. As of this writing the applications can be any one of following: HTML pages, JSP files, .pinc files, Page Flows, Struts, Webflows, JSR 168 Portlets, and WSRP proxy portlets.

BEA WebLogic Portal Portal Development Guide

4-9

The Portal Frame work

Menus Menus are optional components that are loosely coupled to books and pages. A menu is responsible for displaying some type of navigation component, whether it is a set of tabs, a set of links, or some tree structure. The menu fires PageChaneEvents that the Pages themselves listen to and activate accordingly. WebLogic Portal provides two types of menus: singlelevel and multilevel. You can also create your own menus by using JSPs and the tag, or from a backing file call the setupPageChangeEvent method an a Book, Page or Portlet backing context before the preRender method.

Layouts

A

Layouts and Placeholders (not to be confused with personalization placeholders) are used to structure the way portlets and books are displayed on a page. Layout placeholders are rendered as HTML table cells.

ET

WebLogic Portal ships with some predefined layouts and the ability to create your own custom layouts. More layouts will probably be shipped in future service packs and future releases. If the supplied layouts don't meet your needs, you will have to create your own custom layout.

Interacting With UI Controls (taken from the netui white paper)

Context

B

Since controls are not exposed directly to developers, developers need a way to directly interact with and affect the behavior of the controls. To accomplish this, WebLogic Portal exposes context, backing files, skeletons, and events. Use these components when altering the behavior of or interaction with the portal framework.

A context is nothing more then a delegate to the underlying control. This delegate exposes only the supported methods on the control. Contexts are broken down into two types: backing context and presentation context. Backing contexts are available from the backing files, and presentation contexts are available from the JSPs. Two types of context are required because certain methods apply at certain times in the life cycle. For example, it doesn’t make sense to have a setTitle() method on the Presentation context

4-10

BEA WebLogic Portal Portal Development Guide

I nt e r ac ti n g Wit h U I C o n t ro l s

because the portal has already started to render and it would have no effect. Calling this method from a backing file, however, is appropriate.

Backing Context BackingContext is available from backing files. A reference to a Backing context can be obtained in one of two ways: The first way is to use the static method getXXXBackingContext on the context class. This method returns the active backing context for that type. To be more specific, if you call this method from portlet A’s backing file, you will obtain the backing context for portlet A not portlet B. Similarly, if you call getPageBackingContext(request) from portlet A, you will obtain the page backing context for the page portlet A is located on.

A

The second way to obtain a backing context is from another context. This can be useful when you want a context that is not the active context. Example would be, you want to obtain portlet Bs backing context from portlet A.

ET

If portlet A is contained within the same page as Portlet B then you could use: PortletBackingContext portletB = PageBackingContext.getPageBackingContext(request).PortletBackingContext getPortletBackingContextRecursive(“Portlet Bs instance label”);

If Portlet A does not know where portlet B is located then you can delegate to the DesktopBackingContext

B

PortletBackingContext portletB = DesktopBackingContext.getPageBackingContext(request).PortletBackingCont ext getPortletBackingContextRecursive(“Portlet Bs instance label”);

Refer to the javadoc on these and other backing context for more information. com.bea.netuix.servlets.controls.page.PageBackingContext com.bea.netuix.servlets.controls.application.backing.DesktopBackingCont ext

Presentation Context PresentationContext are available from JSP files. A reference to a presentation context can be obtained in one of two ways: The first way is to use the static method getXXXPresentationContext on the context class. This method returns the active presentation context for that type. To be more specific, if

BEA WebLogic Portal Portal Development Guide

4-11

The Portal Frame work

you call this method from portlet A’s content JSP, you will obtain the presentation context for portlet A not portlet B. Similarly, if you call getPagePresentationContext(request) from portlet A, you will obtain the page Presentation context for the page portlet A is located on. The second way to obtain a presentation context is from another context. This can be useful when you want a context that is not the active context. For example, you want to obtain portlet Bs presentation context from portlet A.

Backing Files Backing files are simple Java classes that implement the com.bea.netuix.servlets.controls.content.backing.JspBacking interface or extend

A

the com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking abstract class (in retrospect it should have been called a backing class). The methods on the interface mimic the controls life cycle methods and are invoked at the same time the controls life cycle methods are invoked.

Desktops Books Pages Portlets

B

JspContent controls

ET

The controls as of this writing that support backing files are:

A new instance of a backing file is created per request, so you do not have to worry about thread safety issues. New Java VMs are specially tuned for short-lived objects, and this is not the performance issues it once was in the past. Also JspContent controls support a special type of backing file that allows you to specify if the backing file is thread safe. If this value is set to true, only one instance of the backing file is created and shared across all requests.

Skeletons Skeletons are JSPs that are used during the render phase. The render phase is actually broken into two parts: begin render and end render. The parent control’s begin render is called, followed by its children’s begin render, their children's begin render, and so on. After the last begin render is called, the children’s end renders are called, ending with the parent’s end render. This allows the

4-12

BEA WebLogic Portal Portal Development Guide

I nt e r ac ti n g Wit h U I C o n t ro l s

parent to provide a container, such as an HTML table, and the children to provide the table contents. Each skeleton is actually called twice. There are special tags in the skeleton that evaluate to true depending on which render phase you are in.

Events There are four types of events in the system: Window Mode Window State

Generic Portlet Events.

A

Page Change

ET

The Mode, State and Page Change Events are not exposed directly to the developer but can be configured through special methods on the Window backing files. Namely: setupModeChangeEvent, setupStateChangeEvent, and setupPageChangeEvent(). The methods must be called before the preRender method as events are fired just after handlePostbackData method. Also, they will work only if the handlePostbackData method returns true. Note: When calling one of the setupxxevent methods, it must be done on the backing context that the backing file is tied to. If you do not use this method, the event might not be fired.

B

Portlet Events (not to be confused with page flow events) allow portlets to communicate. One portlet can create an event and other portlets can listen for that event. These Portlet events can also carry payloads. Here is an example of one portlet firing and event from a backing file and other portlets listening for the event: Listing 0-1 Sample Code for Portlet Firing and Event from a Backing File /** * This is the implementation on the backing file of the portlet that wants to fire the event. */ public boolean handlePostbackData(HttpServletRequest request, HttpServletResponse response) {

BEA WebLogic Portal Portal Development Guide

4-13

The Portal Frame work

// Create a new portlet event with the results in the paylod PortletEvent portletEvent = new PortletEvent(new MyPayload(“Hello From portlet A”)); // Get a hold of the portlet event manager and fire the event. PortletBackingContext portletBackingContext = PortletBackingContext.getPortletBackingContext(request); PortletEvent.Manager portletEventManager = PortletEvent.getEventManager(this, portletBackingContext); portletEventManager.fireEvent(portletEvent); // Needed for the event to fire. return true; }

ET

A

/** * This is the implementation of the portlet that wants to receive the event. */ public class ResultBacking extends AbstractJspBacking implements PortletEventListener { MyPayload result; public void init(HttpServletRequest request, HttpServletResponse response) { result = null;

}

B

// Register for Portlet Events PortletBackingContext portletBackingContext = PortletBackingContext.getPortletBackingContext(request); PortletEvent.addGlobalListener(portletBackingContext, this); CustomPortletEvent.Manager portletEventManager = CustomPortletEvent.getEventManager(this, portletBackingContext);

public void handleEvent(Object source, AbstractEvent event) { // Can check the source of the event if (source instanceof PortletA) { result = (MyPayload)((PortletEvent)event).getPayload(); } }

4-14

BEA WebLogic Portal Portal Development Guide

Ne tuix Fi le Structure

Netuix File Structure As mentioned previously, Netuix is an XML framework for rendering applications, whether these applications look like portals or not. Many customers who use our product today create applications from our framework that look nothing like a portal. Typically when people think of portals they think of “My Yahoo!”. While many applications developed with Netuix look like My Yahoo!, many do not. A Netuix application is represented by one or more XML documents, the most familiar being the .portal file (an XML file with a .portal extension). The portal file is a template with which multiple desktops can be created in the . When used as a template, the portal file determines the default Look & Feel of any desktop created from it.

.book: the book file. .page: the page file

ET

.laf: the Look & Feel file

A

Other XML files within the Netuix structure include:

This file points to the specific skin and skeleton to be used for the overall portal desktop’s Look & Feel. For more information on how the .laf file works, please refer to “Themes” on page 8-1. .layout: the layout file.

B

This file contains the XML that describes the controls that make up the layout. The markup from this file is copied into the .portal file and into the database for reassembly. A .layout can live anywhere in the web application directory except WEB-INF. .portlet: the portlet file .menu: the menu file

.theme: the theme file .pinc: the portal include file

This is a portal file that includes other portal files (.pinc = “portal includes”). Just like a JSP can include other JSP files to distribute functionality, a portal file can include other portal files. A .pinc file differs from a .portal file in that a portal includes the root elements or controls while the .pinc file does not. We will discuss this in more detail later. However, for this discussion the portal file is the parent, and it can in turn include one or

BEA WebLogic Portal Portal Development Guide

4-15

The Portal Frame work

more .pinc files, which in turn can include other .pinc files. One other important note: a .pinc file must begin with a Book or a Page element as the root element.

How Portals are Rendered In the portal file, you can think of each element representing an instance of a UI control. These UI controls are wired together in a hierarchical tree, on which each control has a parent and zero or more children. These UI controls discover each other at runtime and can modify the tree by adding new children or removing existing children.

The PortalServlet

A

All requests for a portal or desktop come in through the PortalServlet. The PortalServlet is registered in the web.xml file under the url-patterns appmanager and *.portal. If the PortalServlet detects a request ending with .portal it knows the request is for a locale file and does not need to go to the persistence API for the XML.

ET

The first thing the PortalServlet does is parse the XML file (.portal) to generate a control tree. Every element in the portal file represents a control in the control tree, and every attribute on the element represents an instance variable on the control. The same hierarchy is maintained in the XML document as in the control tree. A UI control is simply a Java class that extends the UIControl class.WebLogic Portal does not explicitly expose controls to developers, but developers can interact with the controls using backing files, context, and skeleton JSPs.

B

The PortalServlet doesn’t actually parse the XML document on each request. Caching and many other “under the hood” processes are going on behind the scenes to obtain the desired performance for the enterprise applications. Front door servlet to handle requests for portals and desktops. Requests that end in 'portalExtensions' are handed off to the UIServlet. The UIControl tree or content uri for a portal for a requested desktop is cached after being retrieved from the persistent store. Caches for user personalized desktops are flushed at the end of a user's session. Non-personalized desktops stay in the cache until either the cache expires them based on its ttl value or they are updated using the persistence API. ContentUris for portals are also cached and flushed using the aforementioned logic. If a tree is obtained, it is handed over to the UIServlet to run life cycle methods on it. If a content uri is obtained the request is forwarded to it.

4-16

BEA WebLogic Portal Portal Development Guide

H o w P o r ta l s ar e R e n de re d

The Portal Rendering Service All controls run through a life cycle (a set of methods called on the control in a particular order). All the methods are called in turn in a depth first order. To best illustrate this, let’s walk through the sequence of events that happen when a person requests a portal in single file mode from the browser. Once the control tree is built and all the instance variables are set on the controls, the control tree is run through its life cycle. The life cycle can be thought of as a set of methods on the controls that are called on in a well-defined order. The life cycle methods are as follows: init() loadState()

raiseChangeEvents() preRender()

render() dispose()

ET

saveState()

A

handlePostbackData()

B

These methods are called in depth first order. In other words, all the init() methods are called, followed by the loadState() methods, and so on. They are also called depth first. Example, given the control tree in Figure 4-2, the order in which the init() method would be called is: C1, C2, C5, C3, C6, C7, C4, then the loadState() method would be called in the same order, and so on. The last method to be called would be C4’s dispose(). Figure 4-2 Control Tree Order

BEA WebLogic Portal Portal Development Guide

4-17

B

ET

A

The Portal Frame work

4-18

BEA WebLogic Portal Portal Development Guide

CHAPTER

5

A

Setting up Your Portal Development Environment

Some content TBD - Some sections are copied from the Getting Started with WebLogic Portal tutorials and will be expanded for GA.

ET

Use this chapter as you prepare your Workshop for WebLogic environment for portal development. This chapter describes the Portal EAR Project Wizard, Portal Web Project Wizard, Datasync Project Wizard, the Add/Remove a Project dialog, and a subset of the WebLogic Domain Configuration Wizard. Although you are not required to follow a particular order in using these wizards, the sections in this chapter are in sequence according to the recommended order. This chapter also describes some features in the Workshop for WebLogic interface that you might find useful as you use it to develop portals.

B

For a step by step example of how to perform the tasks related to each wizard, see the Getting Started with WebLogic Portal tutorials. This chapter contains the following sections: WebLogic Domain Configuration Wizard Portal EAR Project Wizard Add and Remove Projects Dialog Portal Web Project Wizard Portal Datasync Project Wizard Using the Merged Projects View Running a Project on the Server

BEA WebLogic Portal Portal Development Guide

5-1

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

Customizing a Workbench Perspective Setting WebLogic Portal Preferences in Workshop for WebLogic For a step-by-step example of most of the wizards and tasks described in this chapter, refer to the tutorial “Getting Started with WebLogic Portal.”

WebLogic Domain Configuration Wizard This section describes the sections of the Configuration Wizard that are interesting from a WebLogic Portal perspective. A domain is a group of WebLogic Server resources that contain the application server. You must have a server domain that is WebLogic Portal – enabled in order to test the portal that you create. This customized domain is generally called a portal domain.

A

A sample portal domain comes with WebLogic Portal and is, by default, located at WebLogic_HOME\samples\domains\portal.

ET

You can start the Domain Configuration Wizard in several ways. Here are summaries of two methods: From the Workshop for WebLogic interface (workbench)

a. From the Servers view, right-click and select New > Server. b. From the New Server - Define a New Server dialog, click Next and then click the hyperlink to start the wizard.

B

From the Start menu in Windows XP.

Select Start > All Programs > BEA Products >Tools > Configuration Wizard. The first dialog in the wizard looks like the example in Figure 5-1.

5-2

BEA WebLogic Portal Portal Development Guide

W e b L o g i c D o m ai n C o n fi gu ra ti o n Wi za r d

ET

A

Figure 5-1 BEA WebLogic Server Configuration Wizard

B

Table 5-1 shows the values that you would typically enter in the wizard, along with some useful notes that you might find useful as you set up your portal domain.

BEA WebLogic Portal Portal Development Guide

5-3

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

Table 5-1 Configuration Wizard Values for a Portal Domain In this Wizard Page...

Select or Enter...

Welcome

Create a new WebLogic domain (the default)

Select Domain Source

When you do this, most other components are selected automatically; keep them selected. Notice that a WebLogic Portal GroupSpace check box is available on this wizard dialog; portal projects based on the GroupSpace sample application must have a a GroupSpace-enabled domain.

Configure Administrator Username and Password

A

For GroupSpace domains, WebLogic Server creates an additional datasource that points to the GroupSpace instance of the BEA Repository. (Default) user name: weblogic User password: weblogic

ET

Confirm user password: weblogic

You might want to use this WebLogic Server administrator login when using the WebLogic Portal Administration Console, so keep track of what you enter here.

Configure Server Start Mode and JDK

•

Development Mode (the default)

•

JRockit SDK

No (the default)

Create WebLogic Domain

Domain location: Accept the default, or specify another directory on your system.

B

Customize Environment and Services Settings

Portal EAR Project Wizard This section describes the dialogs of the WebLogic Portal Enterprise Application Archive (EAR) Project Wizard. An EAR project collects the component projects of the application for deployment; you create one EAR project per enterprise application. The EAR project contains JAR files, deployment descriptors, build files, and auto-generated files. For more information about EAR projects and

5-4

BEA WebLogic Portal Portal Development Guide

P o r ta l E AR Pr o j e c t Wi za r d

their relationship to the other projects in the Workshop for WebLogic workbench, refer to the “Applications and Projects” topic in the Workshop for WebLogic Programmers’s Guide. The Portal EAR Project is an EAR project that is customized for WebLogic Portal. EAR projects appear as siblings to the other projects in a workspace but functionally, they link together projects and do not contain any of the content of your application. To start the Portal EAR Project Wizard, perform these steps: 1. From the File menu, select New > Project... The New Project – Select a Wizard dialog displays. Select WebLogic Portal > Portal EAR Project, as shown in Figure 5-2.

B

ET

A

Figure 5-2 New Project – Select a Wizard Dialog with Portal EAR Project Selected

2. Click Next.

BEA WebLogic Portal Portal Development Guide

5-5

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

3. In the New Portal EAR Project dialog, enter a name for your EAR project in the Project Name field, and click Next. Caution: Note for Beta - Do not use any spaces in your EAR Project name. Although Workshop for WebLogic allows spaces, WebLogic Server does not allow spaces in the names of deployable modules. If you include a space in your EAR Project, the WebLogic Portal Administration Console will not start. The Select Project Facets dialog displays, as shown in Figure 5-3.

B

ET

A

Figure 5-3 New Portal EAR Project – Select Project Facets Dialog

Table 5-2 describes each WebLogic Portal–related field of the Select Project Facets dialog. The selections that you make here cause WebLogic Portal to create files that you can use as you create your project, and associate the project with the correct set of library modules. For more information about Library Modules, see “About Library Modules” on page 3-5. 5-6

BEA WebLogic Portal Portal Development Guide

Add and Remove Proj ects Di alo g

Table 5-2 New Portal EAR Project Dialog Data Fields - WebLogic Portal Information Field

Description

Presets dropdown menu

The value automatically displayed in this dropdown menu corresponds to the selections made in the tree view of project facets. You can select a preset group of facets from the dropdown menu, or select and unselect specific check boxes in the tree display. If you select a customized set of facets, <custom> displays in the field.

Project Facet Display Tree

WebLogic Portal (Optional) WebLogic Portal GroupSpace

Select the WebLogic Portal facets that you want to install. If certain facets depend on others, messages appear to describe these dependencies and your selections must conform to these requirements. Admin Framework

•

Admin Portal

•

P13N Application Libraries

•

Portal Application Services

A

•

ET

WebLogic Portal primary

•

Portal Customizations Framework

•

Propagation Service

This selection adds Commerce Services to the project.

Check this box (and its sub-features) to enable this project as a GroupSpace EAR.

B

Selecting these check boxes restricts this EAR project to development as a communities-based EAR only. For detailed instructions on creating a communities-based application, refer to the Communities Development Guide. Note: BEA recommends against adding GroupSpace facets after you have already begun development on a non-GroupSpaceenabled application. GroupSpace applications have specific hierarchical (and other) requirements, which you should have in mind as you begin development.

Add and Remove Projects Dialog This section describes the Add and Remove Projects Dialog, which you use to associate an EAR project with a portal domain. If your EAR Project already exists when you create you domain,

BEA WebLogic Portal Portal Development Guide

5-7

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

you can make this association when you create the server domain. If not, you can do it later using the steps outlined in this section. To associate the Portal EAR Project with the server, perform these steps: 1. In the Servers view, right-click BEA WebLogic v9.2 Server @ localhost, then select Add and Remove Projects. The Add and Remove Projects dialog displays, as shown in Figure 5-4.

B

ET

A

Figure 5-4 Add and Remove Projects Dialog

2. Click to select the desired EAR project in the Available projects column and then click Add. The project is added to the Configured projects column on the right. 3. Click Finish.

5-8

BEA WebLogic Portal Portal Development Guide

Po rt a l W eb Pr oje ct Wi za r d

The Portal EAR Project is now associated with the server. To verify this, in the Servers view you can expand the server node to view the server’s associated projects. The myPortalEAR project should be shown as a subordinate node.

Portal Web Project Wizard You use the Portal Web Project Wizard to create the web project that contains portal files. When you create a Portal Web Project, WebLogic Portal creates a set of library modules and files that you can use as you create your portal. To start the wizard, perform these steps: 1. Select File > New > Project. The New Project – Select a Wizard dialog box displays.

B

ET

A

2. In the dialog, select WebLogic Portal > Portal Web Project, as shown in Figure 5-5.

BEA WebLogic Portal Portal Development Guide

5-9

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

3. Click Next.

B

ET

A

Figure 5-5 New Project – Select a Wizard Dialog with Portal Web Project Selected

The New Portal Web Project dialog displays.

New Portal Web Project – Portal Web Project Figure 5-6 shows an example of the New Portal Web Project dialog.

5-10

BEA WebLogic Portal Portal Development Guide

Po rt a l W eb Pr oje ct Wi za r d

B

ET

A

Figure 5-6 New Portal Web Project Dialog

Table 5-3 describes each field of the New Portal Web Project – Portal Web Project dialog. Table 5-3 New Portal Web Project Dialog Data Fields Field

Description

Project name

The name of the portal web project.

BEA WebLogic Portal Portal Development Guide

5-11

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

Table 5-3 New Portal Web Project Dialog Data Fields (Continued) Field

Description

Project contents area Use default check box and file browser

You can use the content area that WebLogic Portal creates by default, or point to another directory where your project contents are stored.

Add project to an EAR check box and file browser

If you have not yet created a Portal EAR Project, leave this check box unselected; you can associate the project with an EAR later by

right-clicking the web project in the Package Explorer tree and selecting Properties; then use the J2EE Module Dependencies setting to associate the project with the EAR.

A

If you have an existing EAR to associate with the project, select the check box; the dropdown menu displays an auto-filled

ET

EAR name corresponding to the EAR project(s) that you created in the Portal EAR Project Wizard. Click to select the appropriate EAR file, or click Browse to navigate to an existing EAR file. A portal web project must be associated with an EAR for the build to work successfully.

New Portal Web Project – Select Project Facets dialog

B

The New Portal Web Project – Select Project Facets dialog is shown in Figure 5-7.

5-12

BEA WebLogic Portal Portal Development Guide

Po rt a l W eb Pr oje ct Wi za r d

B

ET

A

Figure 5-7 New Portal Web Project – Select Project Facets Dialog

Table 5-4 describes each WebLogic Portal–specific field of the dialog. Table 5-4 New Portal Web Project Dialog Data Fields - WebLogic Portal Information Field

Description

Presets dropdown menu

The value automatically displayed in this dropdown menu corresponds to the selections made in the tree view of project facets. You can select a preset group of facets from the dropdown menu, or select and unselect specific check boxes in the tree display. If you select a customized set of facets, <custom> displays in the field.

Project Facet Display Tree

BEA WebLogic Portal Portal Development Guide

5-13

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

Table 5-4 New Portal Web Project Dialog Data Fields - WebLogic Portal Information (Continued) Field

Description

WebLogic Portal primary

Select the WebLogic Portal facets that you want to install. If certain facets depend on others, messages appear to describe these dependencies and your selections must conform to these requirements. •

P13N Web Libraries

•

Portal Customizations Framework

•

Portal Framework

•

Portal Framework Common API

•

Portal Framework Struts

•

Portal Visitor Tools Portal Web Application Services

•

WSRP Producer

A

•

This selection adds Commerce Tag Libraries to the project.

WebLogic Portal GroupSpace

Check this box (and its sub-features) to enable this project as a GroupSpace Portal Project.

ET

WebLogic Portal (Optional)

•

Collaboration Portlets

•

GroupSpace

B

Selecting these check boxes restricts this web project to development as a GroupSpace-based project only. For detailed instructions on creating a GroupSpace-based application, refer to the Communities Development Guide Note: BEA recommends against adding GroupSpace facets after you have already begun development on a non-GroupSpaceenabled application. GroupSpace applications have specific hierarchical (and other) requirements, which you should have in mind as you begin development.

New Portal Web Project - Web Module Dialog The New Portal Web Project – Web Module dialog is shown in Figure 5-7.

5-14

BEA WebLogic Portal Portal Development Guide

Po rt a l W eb Pr oje ct Wi za r d

ET

A

Figure 5-8 New Portal Web Project – Web Module dialog

Table 5-5 describes each field of the dialog.

Table 5-5 New Portal Web Project – Web Module Data Fields Field

Description

B

Context Root Content Directory

The default web content directory name WebContent is automatically displayed; you can change it if you wish.

As a best practice, you should locate your portal file(s) and other portal resources in a web content directory that is subordinate to the web project directory.

Java Source Directory

The default Java source directory name src is automatically displayed; you can change it if you wish.

New Portal Web Project - WebLogic Web Module Dialog The New Portal Web Project – WebLogic Web Module dialog is shown in Figure 5-9.

BEA WebLogic Portal Portal Development Guide

5-15

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

ET

Table 5-6 describes each field of the dialog.

A

Figure 5-9 New Portal Web Project – WebLogic Web Module Dialog

Table 5-6 New Portal Web Project – WebLogic Web Module Dialog Description Description

Use library modules and Copy JARs into the WEB-INF/lib directory radio buttons

If you select the Use library modules radio button, WebLogic Portal creates associations with library modules rather than copying the complete set of JAR files into your project. BEA recommends that you use library modules because of their significant advantages in source control, file sharing, and patch application. For more information about library modules, refer to “About Library Modules” on page 3-5.

B

Field

Add dependencies from this module to all WebLogic Utility/EJB modules in EAR check box

5-16

BEA WebLogic Portal Portal Development Guide

Po rt al Dat as y nc Pr oje ct Wi za r d

Portal Datasync Project Wizard A datasync project is an optional project that stores general purpose portal services data that is used in the development of personalized applications and portals. These portal services include User Profiles, Session Properties, Campaigns and others. You can share a single datasync project among several EAR projects if you wish. To create the datasync project, perform these steps: 1. Select File > New > Project. The Select a Wizard dialog box displays. 2. In the dialog, select WebLogic Portal > Datasync Project, as shown in Figure 5-10.

B

ET

A

Figure 5-10 New—Select a Wizard Dialog with Datasync Project Selected

BEA WebLogic Portal Portal Development Guide

5-17

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

Portal Datasync Project Wizard - Create New Datasync Project Dialog The Create New Datasync Project dialog is shown in Figure 5-11.

B

ET

A

Figure 5-11 Create New Datasync Project Dialog

Table 5-7describes each field of the dialog.

5-18

BEA WebLogic Portal Portal Development Guide

Po rt al Dat as y nc Pr oje ct Wi za r d

Table 5-7 New Datasync Project Data Fields Field

Description

Project name

The name that you want to assign to this datasync web project.

Project Contents

The default web content directory name WebContent is automatically displayed; you can change it if you wish. As a best practice, you should locate your portal file(s) and other portal resources in a web content directory that is subordinate to the web project directory. The default Java source directory name src is automatically displayed; you can change it if you wish.

Create default project directories

This check box is selected by default.

Create default project files

This check box is selected by default.

ET

A

Datasync source folder

Create New Datasync Project – EAR Projects

B

The Create New Datasync Project – EAR Projects dialog is shown in Figure 5-12.

BEA WebLogic Portal Portal Development Guide

5-19

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

B

ET

A

Figure 5-12 Create New Datasync Project – EAR Projects Dialog

This dialog allows you to select the check box for the appropriate Portal EAR project. Tip:

If you create a datasync project without associating it with an EAR, you can do this step later by right-clicking the datasync project in the Package Explorer tree and selecting Properties; then expand the Datasync node in the tree and select EAR Projects to associate the project with the EAR.

If you add a Datasync Project with the default settings, it looks similar to the Package Explorer tree shown in Figure 5-13.

5-20

BEA WebLogic Portal Portal Development Guide

Using the Merge d Projec ts Vi ew

B

ET

A

Figure 5-13 Datasync Project Added to the Package Explorer

Using the Merged Projects View The WebLogic Portal Merged Projects View is included by default in the Portal Perspective. This view shows a combined list of the files in your project, including the associated library modules. This view provides important reference information for your portal development project. If you are not using the Portal Perspective, you should open the Merged Projects view in the workbench. To do so, perform these steps:

BEA WebLogic Portal Portal Development Guide

5-21

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

1. Select Window > Show View > Other. 2. Expand the WebLogic Portal node in the tree if it is not already expanded, and click to select Merged Projects View, as shown in Figure 5-14. Tip:

Some items listed in the Merged Projects View are italicized. The italicized items represent entities that are stored in library modules. All entities that are stored on your filesystem, such as the portal file you created, are shown in regular type.

B

ET

A

Figure 5-14 Show View Dialog with Merged Projects View Selected

Notice that other useful portal-specific views are available here. Experiment to find the best combination of views that you want to have available as you develop portals. 3. Click OK.

The additional view is added to the workbench. Note: You can view a Properties dialog for a file in the Merged Projects View by right-clicking the file and selecting Properties. The dialog shows the library module information for the file, including the library module name and version. Caution: If you use the Merged Projects view to copy all or a portion of a library module resource 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 projects.

5-22

BEA WebLogic Portal Portal Development Guide

Runni ng a Proje ct on the Server

Running a Project on the Server You have three commonly used options for running and viewing the results of your project development; the selection you make depends on the changes you have made in your project and whether or not your server is already started. The following list describes each option available from the context menu in the Project Explorer view: Run as > Run on Server - starts the server if not already started and performs a full publish/republish of the application; then it opens a web browser within the editor view. You must use this selection if you have changed a backing class, page flow, EJB, descriptor, Java file, control, or web service. You can customize the browser setting so that an external browser displays the application; to do this, select Window > Preferences > General > Web Browser and select the appropriate external browser application.

A

Tip:

ET

Open on Server - starts the server if it is not already started, and launches an internal portal artifact browser, displaying the selected application. (If the server is already started, this option has no effect.) This selection requires that you have already performed an initial Run on Server process. This option is faster than the Run on Server selection and is recommended when you need to start the server but you do not need to republish (redeploy).

B

Note: Beta Release users - The Open on Server option might be eliminated for GA, because improvements in Run on Server processing performance make it nearly as fast as that option if not as fast. Refresh button in a currently displayed browser view- refreshes the current display based on changes made in the currently selected portal - same as Open on Server except that using Refresh does not start the server, so it won’t do anything if you stopped the server at some point after displaying the initial browser. This selection also requires that you previously performed an initial Run on Server process. You can use this option if your changes were limited to JSPs, HTML, .portal files, or .portlet files.

Customizing a Workbench Perspective Optionally, you can create a personally customized combination of views, so that you can easily return to it any time.

BEA WebLogic Portal Portal Development Guide

5-23

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

To save the current workbench layout as a perspective, select Window > Save Perspective As, enter a name for your customized perspective in the Name field, and click OK. Your new perspective is added to the list, in the Other category. You can also set this perspective as the default perspective for Workshop for WebLogic, using the Window > Preferences options. For more information, refer to your Eclipse documentation.

Setting WebLogic Portal Preferences in Workshop for WebLogic You can set preferences for the behavior of the various editors and features of WebLogic Portal.

A

Preferences in the WebLogic Portal Section 1. Select Window > Preferences and then select WebLogic Portal in the tree display. A dialog similar to the example in Figure 5-15 displays:

B

ET

Figure 5-15 WebLogic Portal Product Preferences

2. Expand a section in the dialog to set options for that component.

5-24

BEA WebLogic Portal Portal Development Guide

S e t ti ng We bLo gi c Po rt a l P re f e r ences in Wo rk sho p for WebL ogic

Preferences in the General Section 1. Select Window > Preferences. 2. Expand the Appearance node in the tree display. A dialog similar to the example in Figure 5-16 displays:

ET

A

Figure 5-16 Workshop for WebLogic Appearance Preferences

B

3. Both the Colors and Fonts node and the Label Decorations node contain settings related to WebLogic Portal: In the Propagation Tool node, you can change the assigned colors for status indicators. In the Rules Editor node, you can change the font, style, and size for the Rules Editor that is used for campaigns, user segments, placeholders, and content selectors.

BEA WebLogic Portal Portal Development Guide

5-25

B

ET

A

Se tt in g u p You r Po rt al Deve lop ment E nv iro nmen t

5-26

BEA WebLogic Portal Portal Development Guide

CHAPTER

6

A

Upgrading WebLogic Portal Projects to Version 9.2

ET

The BEA Workshop for WebLogic Programmer’s Guide, available as part of the Workshop for WebLogic online help, contains several useful topics that you should review as you prepare for and implement your portal application upgrade, including the following: Upgrading Applications from 8.1 Guidelines for Upgrading

Changes During the Upgrade Process How to Use the Upgrade Wizard

B

These Workshop for WebLogic topics describe the changes that the import utility performs as it upgrades an application, show how to use the wizard, and describe some preparatory steps and clean-up steps that can help you complete the upgrade process as efficiently as possible. This chapter focuses on topics that are specifically related to upgrading WebLogic Portal applications, and contains the following sections: Version 8.1 Features Not Supported in Version 9.2 Using the Import Wizard to Upgrade Version 8.1 Portal Applications

Version 8.1 Features Not Supported in Version 9.2 Webflows and pipelines were deprecated in Version 8.1 and are no longer supported; use page flows in place of these deprecated features.

BEA WebLogic Portal Portal Development Guide

6-1

U pg ra di ng We bLo gi c P o rt a l P ro j e c t s t o Ver s i o n 9.2

Using the Import Wizard to Upgrade Version 8.1 Portal Applications Workshop for WebLogic Version 9.2 provides an import wizard that you can use to upgrade Version 8.1 portal applications. This wizard makes nearly all of the changes that upgrade a working Version 8.1 portal application to a working Version 9.2 application. This section briefly describes each step of the import wizard, focusing on steps of particular interest when upgrading portal applications. For more information on the upgrade wizard, refer to the Workshop for WebLogic help. The import wizard will upgrade your source code and your Version 8.1 project into the Version 9.2 project model. This includes the following processes:

A

Optionally moving shared libraries from the version 8.1 application's Libraries folder to a new EAR project in the upgraded application. An EAR project is the preferred location for shared libraries in Version 9.2.

ET

Converting Version 8.1 project types to Version 9.2 project types.

Moving source code into a src directory (if it is not in one already).

Log File for Upgrade Messages

The upgrade wizard generates a log of messages. This file is placed in the following location:

B

Workspace_root_dir\.metadata\upgrade.log

Before You Begin

Perform these tasks before starting the portal application upgrade process: 1. Upgrade your portal server domain before upgrading your portal applications. You can find instructions for domain upgrade in the WebLogic Portal Upgrade Guide. Note: In the current release, a Platform domain (a domain created with WLI elements in it) cannot be upgraded with the domain upgrade wizard. 2. Ensure that the wizard has enough memory. Follow the steps described in the Workshop for WebLogic help topic if needed. For example, portal projects that are the same size or smaller than the WebLogic Portal 8.1.x “sampleportal” application, a memory allocation of 1 GB should be adequate.

6-2

BEA WebLogic Portal Portal Development Guide

U s i n g th e I m por t Wi z ar d t o U pg ra de Ver s i o n 8.1 P o r ta l A pp l i c at i o n s

3. Optionally, you can turn off JSP validation to speed up the upgrade process. To do so, select Window > Preferences. Click Validation in the tree and then uncheck JSP Syntax Validation. Click OK to save the change. Note: Beta customers - If JSP validation does not succeed but your results appear to work, please turn off JSP validation and contact your BEA representative to provide the error and the application causing the problem.

Using the Wizard To perform the upgrade process for a Version 8.1 portal application, perform these steps: 1. Start Workshop for WebLogic Version 9.2. 2. Click File > Import.

A

3. In the Import dialog, under Select an import source, select Workshop 8.1 Application, then click Next.

ET

4. In the Workshop 8.1 Application Import dialog, click the Browse button and navigate to the .work file for the Workshop 8.1 portal application that you want to upgrade; click Open. 5. After you have selected the .work file, note that the application's projects are displayed with check boxes; by default, all projects are selected. Click Next.

B

6. In the project list, clear check boxes for projects that you do not want to upgrade and import; verify that check boxes are selected for desired projects. Click Next. The Source Upgrade dialog displays. 7. For General preferences, select your preference for error handling and message verbosity. 8. For Project Libraries, verify that the Use WebLogic 9.0 J2EE Shared Libraries check box is selected. The ability to share libraries among projects was added in BEA WebLogic Server Version 9.0 and although it is not required, BEA strongly recommends that you use this feature. Note: This selection is not related to the library module feature that WebLogic Portal uses. Regardless of your selection here, old files from Version 8.1 will be compared with library module files in Version 9.2, and files that are duplicates will be marked for deletion. (You can override file deletion at a later step in the upgrade process if desired.) 9. For properties file upgrader options, you can choose whether or not to delete copied resource bundle files form the web content folder.

BEA WebLogic Portal Portal Development Guide

6-3

U pg ra di ng We bLo gi c P o rt a l P ro j e c t s t o Ver s i o n 9.2

10. For the JSP Tags preference, if the projects you're upgrading include NetUI JSP tags and you want to upgrade these tags to current Beehive versions, select the Migrate NetUI tag to current version check box. If you choose not to upgrade the tags, in general they will still be usable in Version 9.2. For more information on issues related to upgrading to the Beehive tags, see Upgrading Support for JSP Tag Expression Language in the Workshop for WebLogic help. 11. Click Next. An informational message appears, stating that Workshop for WebLogic must compile the application in order to upgrade it. 12. Click OK.

A

The upgrader analyzes the projects to be upgraded and then displays an Upgrade preview page including a list of included files and related upgrade messages. You can expand the node for each file to view the upgrade messages associated with that file.

ET

The messages here are also available in the upgrade log file after the wizard finishes. 13. After reviewing the messages, click Next.

B

For each project to be updated, a File Actions dialog displays, allowing you to select whether or not to save/delete file sets of modified and unmodified files. Portal resources that have not been modified from 8.1.x are marked for replacement with their Version 9.2 counterparts, and by default the old unneeded versions are marked for deletion. Any modified files are saved by default. Review these file lists and check or uncheck the associated check boxes as desired. 14. Click Next as needed to progress through the File Action dialogs. 15. When you have reviewed all dialogs, click Finish to complete the upgrade process.

Upgrading Look & Feels Portal Look & Feels in WebLogic Portal 8.1 used two configuration files for skins and skeletons (in the /skins/skin_name and /skeletons/skeleton_name directories): skin.properties and skeleton.properties. Both were text files, and skeleton.properties was optional. In WebLogic Portal 9.2, both files are now XML, and both are required. To upgrade a WebLogic Portal 8.1 Look & Feel to the WebLogic Portal 9.2 format:

6-4

BEA WebLogic Portal Portal Development Guide

Upgradi ng Loo k & Fee ls

1. Make sure the portal application containing the Look & Feel has been converted to WebLogic Portal 9.2, as described in this chapter. 2. Open the Look & Feel file (.laf file). Informational messages will notify you about the change that should occur. 3. Click OK to continue.

B

ET

A

The configuration files are automatically converted to the new XML format.

BEA WebLogic Portal Portal Development Guide

6-5

B

ET

A

U pg ra di ng We bLo gi c P o rt a l P ro j e c t s t o Ver s i o n 9.2

6-6

BEA WebLogic Portal Portal Development Guide

CHAPTER

7

A

Integrating Web Applications into Portals

ET

One of WebLogic Portal’s greatest assets is its flexibility in managing many different types of applications. These applications can be surfaced either as the sole contents on a portal page or inside a portlet on a page. Regardless of how the application is surfaced, it maintains the full functionality intended in its design. You can easily transform an existing Workshop for WebLogic web application into a Portal Web Project by installing the necessary WebLogic Portal – specific library modules into it. Then you can give the web application a portal user interface, add personalization and campaign functionality, and take advantage of WebLogic Portal's content and user management services.

B

Note: Beta release – descriptions for integrating Struts and other application types are TBD.

Integrating an Existing Web Application into Workshop for WebLogic Integrating a web application into a WebLogic Portal environment involves the following steps: Installing WebLogic Portal project facets into the EAR project. Installing WebLogic Portal project facets into the web application project. Adding a Datasync project (if you want to use the general service portal services data such as user profiles, user segments, request properties, session properties, and so on). Associating your EAR project with a WebLogic Portal-enabled server.

BEA WebLogic Portal Portal Development Guide

7-1

In teg r at in g W eb Ap pl ica ti ons in to Po rt al s

To integrate an existing web application into Workshop for WebLogic and add WebLogic Portal functionality, follow these steps: Note: These instructions assume that you have an existing web application that conforms to the requirements of the Workshop for WebLogic Version 9.2 environment, and includes an EAR Project and a Workshop for WebLogic Dynamic Web Project . 1. In the Package Explorer view, right-click the EAR Project and select Properties. 2. Click to select Project Facets in the tree that is displayed in the left pane of the dialog. The project facets associated with this EAR project display in the table, as shown in Figure 7-1.

B

ET

A

Figure 7-1 Project Facets Associated with Non-Portal EAR Project

3. Click Add/Remove Project Facets. The Add/Remove Project Facets - Select Project Facets dialog displays. 4. Select the WebLogic Portal check box. All the features for the WebLogic Portal facet are selected by default; the example in Figure 7-2 shows the expanded tree with the WebLogic Portal facet selected.

7-2

BEA WebLogic Portal Portal Development Guide

I n teg r at i n g a n Ex i s t i n g Web A pp l i cation into Wo rk sho p for WebL ogic

5. Click Finish.

ET

A

Figure 7-2 Select Project Facets Dialog with WebLogic Portal Facet Selected (and Expanded)

B

The Project Facets table in the properties dialog displays the facets that you just added, as shown in Figure 7-3.

BEA WebLogic Portal Portal Development Guide

7-3

In teg r at in g W eb Ap pl ica ti ons in to Po rt al s

A

Figure 7-3 Updated Project Facets Display including WebLogic Portal Features

ET

6. Click OK.

The Package Explorer view includes the new portal-related content. 7. Repeat steps 1 through 6 to add WebLogic Portal facets to the Web Project. When you are finished, the display in the Properties view includes the WebLogic Portal facets, and the tree in the Package Explorer view shows the added portal-specific library modules.

B

Figure 7-4 shows an example of the new portal-related content that is added for the EAR project and web project.

7-4

BEA WebLogic Portal Portal Development Guide

I n teg r at i n g a n Ex i s t i n g Web A pp l i cation into Wo rk sho p for WebL ogic

Figure 7-4 Package Explorer View of Web Application Before and After Integrating Portal

Before installing Portal facets

B

ET

A

After installing Portal facets

8. Associate your portal-enabled project with a WebLogic server that is customized for use with WebLogic Portal. If you need to create a new server that is enabled for use with WebLogic Portal, refer to “WebLogic Domain Configuration Wizard” on page 5-2. You can now use WebLogic Portal features to create, assemble, and manage a portal environment. Note: BEA recommends against adding GroupSpace facets after you have already begun development on a non-GroupSpace-enabled application. GroupSpace applications have specific hierarchical (and other) requirements, which you should have in mind as you begin development.

BEA WebLogic Portal Portal Development Guide

7-5

B

ET

A

In teg r at in g W eb Ap pl ica ti ons in to Po rt al s

7-6

BEA WebLogic Portal Portal Development Guide

CHAPTER

8

A

User Interface Development with Look & Feel Features

Most of this chapter is not included for Beta; however, the new Genes & Chromosomes feature is included. Complete content will be available at the GA release.

ET

This chapter describes how to use the portal framework to develop the overall appearance and behavior of the portal you develop in Workshop for WebLogic. You will be able to look at a rendered portal in a browser and understand which pieces of the underlying framework that you need to modify to obtain the results you want. In addition, the Look & Feel Editor is discussed. The Look & Feel Editor lets you interactively modify the text styles used by a portal. This chapter includes the following sections:

B

Portal Rendering and Look & Feel Introduction The Look & Feel Editor Creating a Look & Feel

Portal Rendering and Look & Feel Introduction TBD

Themes TBD

BEA WebLogic Portal Portal Development Guide

8-1

User Interface De velo pment with Look & Feel Features

Genes & Chromosomes Genes allow you to take a single Look & Feel and easily modify it to express, for example, different color schemes. A Look & Feel gene defines a particular characteristic of a Look & Feel that can be expressed differently by any given rendering of the Look & Feel. If, for example, a Look & Feel is defined to have a gene named ''wlp.portlet.border.color'' and the current request is determined to associate a value of ''#ff0000'' with that gene, then for that rendering of the Look & Feel, all portlet borders governed by that gene will be rendered red in color. Using genes can provide the following advantages in your Look & Feel: Simplified Look & Feel customization for minor modifications such as color scheme changes.

A

Easier implementation of branding, allowing one Look & Feel to be used for multiple brands. Convenient facility to support the generation of dynamic values in associated CSS files or Javascript files.

ET

Global parameterization capabilities; for example, genes can be used to share a set of global properties to toggle the rendering of certain portal-wide features. Provide a way to allow end users to toggle advanced features.

B

Look & Feels can define a set of genes that together comprise a chromosome, providing the ability to alter the appearance of any given Look & Feel with a minimum of effort. Each Look & Feel can define, and be sensitive to, its own set of genes. The following terms are related to genes and chromosomes: A gene is an arbitrary name defining a single, orthogonal parameter affecting the way particular Look & Feel will be rendered. A chromosome is a set of genes – a “ready-to-render” Look & Feel parameter set. A default chromosome is a chromosome published by a skin or skeleton as a means of both exposing its supported parameters and their defaults; this chromosome also serves as the active chromosome if none other is explicitly specified. You define the default chromosome directly in the configuration file of the skin or skeleton that owns it. A chromosome instance is a chromosome that overrides and/or extends some or all of the genes defined in a skin or skeleton's default chromosome; you define a chromosome

8-2

BEA WebLogic Portal Portal Development Guide

Using Ge nes in Loo k & Fee ls

instance in its own configuration file in the home directory of the skin or skeleton to which it applies. A genome is the set of chromosomes drawn from both skin and skeleton that will be applied to a Look & Feel for a particular rendering. A mutator is an optional, configurable filter for gene values that is applied immediately before rendering.

Using Genes in Look & Feels Genes are implemented as granular HTML style definitions that you can insert into CSS files as variables. You define genes in an XML .chromosome file. Following is an example that highlights one of the primary benefits of genes.

A

Gene Example

ET

In a .chromosome file, you could define a gene called “bodyColor” and assign it a value of “red,” like this:

#FF0000

In all of your CSS files, you can use the gene as a variable. For example: body {

B

border:1px solid ${bodyColor}

This entry is equivalent to bodyColor: border:1px solid #FF0000 When you use this gene in your CSS files, you only need to modify the gene value itself to cascade the change throughout all your CSS files rather than changing the value manually in each CSS file. You can also use the same gene names in multiple Look & Feels, and provide different gene values in each Look & Feel.

Creating a Chromosome and Genes To create a basic chromosome file, copy default.chromosome from the WebLogic Portal library modules. To do this: 1. Show the Merged Projects View (Window > Show View). BEA WebLogic Portal Portal Development Guide

8-3

User Interface De velo pment with Look & Feel Features

2. In the Merged Projects View, navigate to yourPortalWebProject > Framework > Skins > legacy. 3. Right-click default.chromosome and select Copy to Project. The file is copied to your project on the file system. 4. Move the file to your skin or skeleton directory, depending on where you want to use it. 5. Add genes to the chromosome, using the structure shown in “Gene Example” on page 8-3.

Guidelines for Using Genes Use the following guidelines for working with genes:

A

Each Look & Feel can reference one chromosome for skins and one chromosome for skeletons. If the framework does not find a gene in the chromosomes you reference in a Look & Feel, it looks for the gene in a default.chromosomes file (you must create this file).

ET

As a best practice, create a default.chromosome file in each Look & Feel, and create a custom chromosome to override values in default.chromosome you want to override. Genes can be used in both skins and skeletons. In skeletons, CSS files are often used in conjunction with JavaScript to control behavior. Chromosomes (.chromosome files) must be in the same directory as the skin.xml or skeleton.xml files.

B

Any genes you want to use in the Look & Feel must be defined in the skin or skeleton chromosome. The framework does not check to see if a gene you use in a CSS is defined in a chromosome. If you reference a nonexistent gene in a CSS, the HTML output will show the gene reference, such as ${bodyColor}. In skin.xml, use <style> and <style content-uri> if you are using genes. Otherwise use . Genes can contain references to other genes. You must duplicate .chromosome files in theme directories.

Using the Genes API Gene API information will be provided for the General Availability release.

8-4

BEA WebLogic Portal Portal Development Guide

Cre ating a Lo ok & Fe el

Creating a Look & Feel TBD

The Look & Feel Editor

B

ET

A

TBD

BEA WebLogic Portal Portal Development Guide

8-5

B

ET

A

User Interface De velo pment with Look & Feel Features

8-6

BEA WebLogic Portal Portal Development Guide

CHAPTER

9

A

Developing Portals Using Workshop for WebLogic

Most of this chapter is TBD. The current content of most included sections is copied from the Getting Started with WebLogic Portal tutorials

ET

Keep in mind that you must have the framework for your portal interface in place, including Look & Feel elements, any required CSS files, and so on, before you start building your portal. This chapter includes the following sections: Creating a Portal File

Portal Component Properties

B

Copying Library Module Files into a Project Deploy and View a Portal Federating Portals

Working with URLs Enabling Desktop Selection

Creating a Portal File When you create a portal, WebLogic Portal creates a portal file—an XML file with a .portal file extension. The .portal file is the central defining file of a portal, with references to all the major components of the portal: the desktops, books, pages, portlets, and so on.

BEA WebLogic Portal Portal Development Guide

9-1

Devel oping Portals Us ing Workshop fo r WebLogic

If your portal runs as a file-based portal, when users visit the portal they will point their browsers at this file: http://host_name:port_number/PortalWebProject_Name/portal_name.portal. To create a portal and its accompanying .portal file, perform these steps: 1. If the Portal perspective is not already open, select it by choosing Window > Open Perspective > Portal. 2. Navigate to the web content directory of your Portal Web Project (by default it is named WebContent); right-click and then select New > Portal. The New Portal dialog displays, as shown in Figure 9-1.

A

Because you started this wizard by right-clicking the web content directory, the parent folder field automatically displays that directory name.

B

ET

Figure 9-1 New Portal Dialog

The wizard allows you to create your portal file outside the web content directory, but as a best practice, you should locate your portal file in a web content directory that is subordinate to the web project directory. The default web content directory name is WebContent, and is assigned when you use the Portal Web Project Wizard. You can

9-2

BEA WebLogic Portal Portal Development Guide

Crea t ing a Po rt a l Fi le

change the name of your web content directory if you wish; for more information, refer to “New Portal Web Project - Web Module Dialog” on page 5-14. 3. In the File name field, enter the name that you want to assign to the portal. A file type of .portal is required for portals; you can type the .portal extension to the portal’s name if you wish, but WebLogic Portal automatically adds the extension if you don’t enter it. 4. Click Finish. The wizard adds the portal to the specified folder in the Portal Web Project and a view of the portal displays in the editor, as shown in Figure 9-2.

B

ET

A

Figure 9-2 Portal Displayed in Workbench

The created portal includes a desktop, header, footer, book, and page. A desktop is a user-specific view of the portal content. A portal can support many desktops. A single portal might support an employee-specific desktop, a customer-specific desktop, and others, where each desktop exposes different kinds of content to different sets of users. Any part of a portal can be

BEA WebLogic Portal Portal Development Guide

9-3

Devel oping Portals Us ing Workshop fo r WebLogic

included or excluded from a desktop, including a book, a page, a specific application, or an individual link. Desktops can also define the look and feel attributes of a portal. Desktops can be associated with a particular skin that defines the color scheme, fonts, and images used. Desktops also contain a header and footer—you can place images, text, or any web content in these areas to give consistency to the look and feel of a desktop. Typically, you use Workshop for WebLogic to develop a portal and its key components; then you use the WebLogic Portal Administration Console to create specific desktops using the portal as a template. For information about creating desktops in the next phase of development, refer to “Creating Portal Desktops” on page 13-1.

ET

A

You use books to organize your content and navigation in a hierarchical manner. Books can contain other books or pages. In a browser, a book is rendered as a set of tabs or links. Each portal contains a main book called, by default, “Main Page Book.” A page consists of a set of columns and/or windows that organize the actual content of your portal. You navigate to a page by clicking on an individual tab or a link. You can create books and pages using either Workshop for WebLogic or the WebLogic Portal Administration Console.

Add a Page to Your Portal

This section describes how to add a second page to the portal’s main book. When the portal is rendered in a browser, the two pages will appear as two clickable tabs. You add a new page using a few different methods; this description describes the drag and drop method.

B

To add a new portal page, perform these steps:

1. From the Palette view, drag and drop the Page icon to the location where you want to add it. Figure 9-3 shows the result when you add a new page to the right of the default portal page. Tip:

9-4

If you do not see the Palette tab, select Window > Show View > Palette.

BEA WebLogic Portal Portal Development Guide

Portal Compo nent Properti es

ET

A

Figure 9-3 Adding a Page to a Portal in the Workbench

Portal Component Properties

B

Portal properties are named attributes of the portal that uniquely identify it and define its characteristics. Some properties—such as title and definition label—are required; many optional properties allow you to enable specific functions for the portal such as presentation properties, rollover images, and control tree optimization. The specific properties that you use for a portal vary depending on your expected use for that portal. During the development phase of the portal life cycle, you generally edit portal properties using the Workshop for WebLogic interface; this section describes properties that you can edit using Workshop for WebLogic. During staging and production phases, you typically use the WebLogic Portal Administration Console to edit portal properties; only a subset of properties are editable at that point. For instructions on editing portal properties from the WebLogic Portal Administration Console, refer to “Creating Portal Desktops” on page 13-1. For a detailed description of all portal properties, refer to “Appendix - Portal Properties” on page A-1. This section contains the following topics:

BEA WebLogic Portal Portal Development Guide

9-5

Devel oping Portals Us ing Workshop fo r WebLogic

Editing Portal Properties Tips for Using the Properties View in the Workbench

Editing Portal Properties To edit portal properties, follow these steps: 1. Navigate to the location of the portal whose properties you want to edit, and double-click the .portal file to open it in the workbench editor. 2. Click the border of the desired component to display its properties in the Properties view.

A

The displayed properties vary according to the active area that you select. If you click the outer (desktop) border, properties for the entire desktop appear; if you click inside a placeholder, properties for that placeholder appear, and so on. 3. Navigate to the Properties view to view the current values for that component’s properties. Figure 9-4 shows a segment of a portal header’s Properties view:

B

ET

Figure 9-4 Portal Properties Example - Header Properties

4. Double-click the field that you want to change. If you hover the mouse over a property field, a description of that field displays in a popup window. Values for some properties are not editable after you create the portal. In some cases, from the property field you can view associated information pertaining to that property; for example, the Skeleton URI property provides an Open button to view the associated file. For more information about options available in the Properties view, refer to “Tips for Using the Properties View in the Workbench” on page 9-7.

9-6

BEA WebLogic Portal Portal Development Guide

C o p y i n g L i br a ry M o d ul e F i l e s i nt o a P ro j e c t

Tips for Using the Properties View in the Workbench 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. If a file is associated with a property, the Properties view includes an Open button in addition to a Browse button; you can click Open to display the appropriate editor/view for the file type. If you want to edit the XML source for a portal file, you can right-click the .portlal file in the Package Explorer view and choose Edit with > XML Editor to open the file using the basic XML editor that Eclipse provides.

A

Copying Library Module Files into a Project

ET

You can override a resource in a library module by copying the resource into your portal web project and then customizing it. Caution: If you copy library module 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. To copy a library module resource into your project, follow these steps: 1. Add the Merged Projects view if it is not currently visible. To do so:

B

Select Window > Show View > Merged Projects View. The Merged Projects View is part of the default Portal Perspective, displaying in the same area as the Package Explorer view. 2. Select the Merged Projects view if it is not already selected. Italicized items in the Merged Projects View represent entities that are stored in library modules. All entities that are stored on your filesystem, such as any portal files that you create, are shown in regular type. 3. Expand the display tree to view the resource that you want to copy to the project. You can copy a single file, set of files, or an entire folder, to your project. 4. Right-click the resource(s) that you want to copy, and select Copy To Project.

BEA WebLogic Portal Portal Development Guide

9-7

Devel oping Portals Us ing Workshop fo r WebLogic

The resources are copied to the web content folder of your project, and reflect the hierarchy of their location in the library module. Note: You can view a Properties dialog for a file in the Merged Projects View by right-clicking the file and selecting Properties. The dialog shows the library module information for the file, including the library module name and version.

Viewing Files that Override Library Module Files You can view local file overrides of library module files in either or both of these ways: In the Merged Projects view in Workshop for WebLogic, files that you copied to the project are shown in plain (non-italic) text.

A

Optionally, you can choose to superimpose a small marker icon on file icons in the display tree to indicate that a local file in your portal web project is overriding a file of the same name and path that exists in one of your library modules.

ET

The icon indicating library module overrides is turned off by default, due to the processing time involved in updating the information, and the fact that using it causes the WebLogic Portal plugins to always load at startup. To activate the library override marker icons, follow these steps: a. Navigate to Window > Preferences > General > Appearance > Label Decorations. b. Check the box labeled WebLogic Library Module File Override.

B

c. Click Apply and then click OK.

A small arrow displays in the icon for files that were copied from the library module to the project.

Deploy and View a Portal

You can deploy a portal to the server and view it in a browser window that is contained within Workshop for WebLogic. Follow these steps: 1. Right-click the.portal file for the portal in the Package Explorer view and select Run As > Run on Server, as shown in Figure 9-5. Note: In many cases you are not required to redeploy a portal to see changes that you have made. For more information, refer to “Running a Project on the Server” on page 5-23.

9-8

BEA WebLogic Portal Portal Development Guide

D e pl o y a nd Vi e w a P o r ta l

Figure 9-5 Selecting to Run the Portal on the Server

The Run On Server - Define a New Server dialog displays. Make sure the server that you want to use is highlighted.

A

2. Click Finish to begin the deployment process. Wait while Workshop for WebLogic starts the server, deploys files to the server, and runs the application. While deployment is in process, you can view status messages in the status bar at the bottom of the window.

If you previously deployed a project of the same name and that project is in a different location, you need to undeploy that project. To do this, double-click the server in the Servers view, and delete myPortalWebProject (not the library modules) from the Published Modules list. For more information about this task, refer to the “Managing Servers” section of the Workshop for WebLogic help.

B

Tip:

ET

The results appear in a new tab in the editor view, as shown in Figure 9-6.

Figure 9-6 Portal Display in the Workbench Editor View

BEA WebLogic Portal Portal Development Guide

9-9

Devel oping Portals Us ing Workshop fo r WebLogic

Tip:

You can choose to always use an external web browser to view your portal if you wish. To do so, select Window > Preferences and select General > Web Browser in the property tree; then select the Use external Web browser radio button.

Federating Portals TBD Brief description of concept and reference to Federated Portals doc.

Working with URLs Enabling Desktop Selection

B

ET

TBD

A

TBD

9-10

BEA WebLogic Portal Portal Development Guide

C H A P T E R 10

A

Creating Portals for Multiple Device Types

This chapter has not been updated from 8.1.x content

ET

There are many types of Web-enabled mobile devices that can access your portals. Since these devices have different interfaces and different-sized viewing areas, each has a unique requirement for the type of content they display. With the multichannel framework provided in WebLogic Workshop Portal Extensions, you can extend your portals to include support for different mobile devices. This flexible framework lets you create a single portal that serves content to Web-capable devices seamlessly and simultaneously. You can also serve different content to different browsers, such as Mozilla, Netscape, Opera, and Internet Explorer.

B

When a device accesses a portal, the portal knows what kind of device it is and automatically serves the device the content you created for it within the Look & Feel you created for it. This chapter contains the following sections: Adding Multichannel Features to a Portal Web Application Defining Multichannel Clients Building Multichannel Portals

Adding Multichannel Features to a Portal Web Application TBD

BEA WebLogic Portal Portal Development Guide

10-1

Cre ating Portals fo r Mul ti ple Devi ce T y pes

Defining Multichannel Clients TBD

Building Multichannel Portals

B

ET

A

TBD

10-2

BEA WebLogic Portal Portal Development Guide

B

ET

A

B ui l din g Mu l t i c h an ne l Po rt a l s

BEA WebLogic Portal Portal Development Guide

10-3

Cre ating Portals fo r Mul ti ple Devi ce T y pes

Table 10-1 corresponding steps for figure Step

Instructions

1

When a device accesses a portal-enabled server with a URL, the device sends a user-agent string in the HTTP header that tells what kind of client it is. The server stores this user-agent string in the “User-Agent” request property for the portal application. The “User-Agent” request property is automatically included with any portal application you create in WebLogic Workshop Platform Edition. To view this property, open the following file in WebLogic Workshop: \data\request\DefaultRequestPropertySet.req.

B

ET

A

Portal developer tasks: None. This happens automatically.

10-4

BEA WebLogic Portal Portal Development Guide

B ui l din g Mu l t i c h an ne l Po rt a l s

Table 10-1 corresponding steps for figure (Continued) Step

Instructions

2

To enable multichannel support for devices, a portal web project must be able to map the user-agent string stored in the “User-Agent” property to a classification. This mapping must be created before portals are accessed by mobile devices. Portal developer tasks: You must map clients to classifications in your portal web project WEB-INF\client-classifications.xml file. The default client-classifications.xml file contains default client mappings. For each client entry that maps to a classification, you can enter either an explicit user-agent string that maps exactly to what a device sends, or you can enter a regular expression that can encompass multiple user-agent strings.

A

The following example of a client classification mapping in client-classifications.xml shows explicit mappings (with the <useragent> tag) and a regular expression mapping (with the <useragent-regex> tag). <useragent value="Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; 240x320)"/>

ET

<useragent value="Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240x320)"/> <useragent-regex value="(.*)PDA; Windows CE(.*)NetFront/3(.*)" priority="1"/>

B

An explicit <useragent> value can be used for only one classification. If you use more than one <useragent-regex> tag to map with regular expressions, it is possible that a device accessing a portal could map to more than one classification. To determine which classification the device is mapped to, use the priority attribute, as shown above. The value “1” is the highest priority. Enter any whole number for the priority value. Note: For portlets that are assigned client classifications, the classification “description” value is used in the WebLogic Portal Administration Console to show which classifications the portlet is assigned to. Write descriptions that are easily understood by portal administrators. For information on user-agent strings and values for different devices, perform a web search for “user-agent.”

3

Because of the client-classification.xml mappings you defined, the user-agent string stored in the “User-Agent” property is mapped to the classification name you provided. In the example mapping above, the name is “pocketpc”. Portal developer tasks: None. This happens automatically.

BEA WebLogic Portal Portal Development Guide

10-5

Cre ating Portals fo r Mul ti ple Devi ce T y pes

Table 10-1 corresponding steps for figure (Continued) Step

Instructions

4

After the client is successfully mapped to a classification, the classification name is stored in the “Client Classification” property in the DefaultRequestPropertySet.

B

ET

A

Portal developer tasks: None. This happens automatically.

10-6

BEA WebLogic Portal Portal Development Guide

B ui l din g Mu l t i c h an ne l Po rt a l s

Table 10-1 corresponding steps for figure (Continued) Step

Instructions

5

The portal uses that client classification name stored in the DefaultRequestPropertySet throughout the portal framework to identify the content and presentation tailored to the device. Portal developer tasks: The portal is where you develop and enable specific content and presentation to be used for different mobile devices. The portal framework includes the following touch points for creating device-specific content and presentation: Portlet Development - When you create a portlet with the WebLogic Workshop Portal Extensions, you can assign the portlet to be used by different devices (client classifications). With the portlet open in the Portlet Designer, in the Property Editor window, do the following: Click the ellipsis icon [...] in the Client Classifications field to launch the Manage Portlet Classifications dialog box.

A

In the dialog box, select whether you want to enable or disable classifications for the portlet. (If you disable classifications, the portlet is automatically enabled for the classifications you do not select for disabling.) Move the classifications you want to enable/disable from the Available Classifications list to the Selected Classifications list, and click OK.

ET

The list of classifications is read from the client-classifications.xml file. JSP Tags - The WebLogic Workshop Portal Extensions include a set of JSP tags for creating device-specific inline content in JSPs. Only the content that meets the device criteria defined by the JSP tag is delivered to the device.

B

The JSP tags have a required “client” attribute for mapping the JSP content to classifications. For that client value in the JSP tag, you must use the exact value used for the name in the client-classification.xml file (the value being stored in the “Client Classification” property in the DefaultRequestPropertySet). See the Mobile Devices JSP Tags for more information. Look & Feel Development - The Look & Feels (skins and skeletons) provided with the WebLogic Workshop Portal Extensions include support for a few mobile devices (nokia, palm, and pocketpc). These skins and skeletons are included as subdirectories of the main skins and skeletons in your portal web projects. For example, a pocketpc skin is included as part of the “default” skin in <project>\framework\skins\default\pocketpc. You can also develop your own skins and skeletons to support different devices. When a Look & Feel is selected for a desktop, the portal framework reads the “Client Classification” property in the DefaultRequestPropertySet and uses the Look & Feel logic to find skin and skeleton directories matching the name of the client classification. For instructions on creating skins and skeletons for Look & Feels, see Creating Skins and Skin Themes and Creating Skeletons and Skeleton Themes. Interaction Management Development - With the client classification name being stored in the “Client Classification” property of the DefaultRequestPropertySet, you can build and trigger personalization and campaigns for devices based on that property value. For information on developing personalization and campaigns, see Developing Personalized Applications. BEA WebLogic Portal Portal Development Guide

10-7

Cre ating Portals fo r Mul ti ple Devi ce T y pes

Table 10-1 corresponding steps for figure (Continued) Step

Instructions

6

Based on the mapping you set up to match user-agent (client) strings in the HTTP request to classification names, the portal sends the device-specific content and presentation you developed to the different devices that access the portal.

B

ET

A

Portal developer tasks: None. This happens automatically.

10-8

BEA WebLogic Portal Portal Development Guide

C H A P T E R 11

A

Configuring Visitor Tools

This chapter has not been updated from 8.1.x content

ET

Portal visitors can use browser-based tools to personalize the makeup and appearance of their portal. This chapter describes how to set up your portal to allow visitor customization. This chapter includes the following sections:

Adding Visitor Tools to a New Portal Application

B

The GroupSpace User Guide Visitor Tools chapter provides content on end user customization that you can use as a starting point for creating your own user guide for your portal end users.

Adding Visitor Tools to a New Portal Application TBD

BEA WebLogic Portal Portal Development Guide

11-1

B

ET

A

Configuring Vis ito r Tool s

11-2

BEA WebLogic Portal Portal Development Guide

C H A P T E R 12

A

Designing Portals for Optimal Performance

This chapter has not been updated from 8.1.x content

ET

Performance is always an issue in the acceptance of an enterprise-level software solution and WebLogic Portal is not immune to these issues. However, many performance problems are not the result of flaws in the product but rather the result of poor decisions made during the design phase of application development. Proper planning allows you to take advantage of the inherent strengths of WebLogic Portal to ensure optimal performance for your portals.

B

Portal performance is usually measured by the amount of time required to actually render that portal and all of its constituent parts once a visitor clicks an object on the screen (that is, sends a request to the portal servlet). Any number of reasons—all easily addressed and rectified by proper design—can negatively impact the anticipated system response, although foremost among them is portal layout and design. This chapter contains the following sections: Control Tree Design

Using Multiple Desktops Optimizing the Control Tree Pluggable Framework Cache Other Ways to Improve Performance

BEA WebLogic Portal Portal Development Guide

12-1

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

Control Tree Design One of the most important variables that affects portal performance is portal controls. The more portal controls (pages, portlets, buttons, and so on) you have, the larger your control tree. For a detailed description of the controls available for a portal, see “Portal Controls” on page 4-8.

How the Control Tree Works When a portal is instantiated, it generates a taxonomy, or hierarchy of portal resources, such as desktops, books, pages, and portlets. Each resource is represented as a node on the control tree, as shown in fig.

B

ET

A

Figure 12-1 Simple Portal Schematic Example

This example depicts a single portal with a main book containing six sub-books, which in turn contain two pages each, and each page contains two portlets each, for a minimum of 42 controls in the portal; the inclusion of buttons, windows, menus, and layouts increases the number of controls on the portal significantly. Note: This example is significantly oversimplified; enterprise portals might include thousands of controls.

12-2

BEA WebLogic Portal Portal Development Guide

Control Tree De sign

How the Control Tree Affects Performance Once the control tree is built and all the instance variables are set on the controls, the tree must run through the life cycle for each control before the portal can be fully-rendered. The life cycle methods are called in depth-first order. That is, all the init() methods for each control are called, followed by the loadState() method for each control, and so on in an order determined by the position of each control in the portal’s taxonomy. For example, the control tree illustrated in Figure 12-2 depicts the taxonomy a simple portal comprised of a book (B1) containing two pages (P1 and P2), which each contain two portlets (p1-p4; note that p2 also contains its own subordinate book, page, and portlet hierarchy).

B

ET

A

Figure 12-2 Control Tree with Life Cycle Methods

When this portal is rendered, the init() method (and handlePostBackData() if _nfpb=true) is called first, for each control, in this order: B1, P1, p1, p2, B2, P3, p5, p6, P2, p3, and finally p4. Next, the loadState() method would be called in the same order, and so on for all life cycle methods through saveState(). Note: Control life cycle methods preRender(), render(), and dispose() are called only on visible controls.

BEA WebLogic Portal Portal Development Guide

12-3

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

Running each control through its life cycle requires some overhead processing time, which, when you consider that a portal might have thousands of controls, can grow exponentially. Thus, you can see that larger the portal's control tree the greater the performance hit.

Using Multiple Desktops With SP3 and earlier versions of WebLogic Portal, the simplest way to limit the size of the control tree without limiting the flexibility of the portal is to split the portal into multiple desktops. In portal taxonomy, a desktop is nothing more than a portal embedded into another portal. It maintains the ability to leverage all of the features inherent in any portal and, within itself, can contain additional desktops.

Why This is a Good Idea

ET

A

When you split a complex portal into multiple desktops, you spread the controls among those desktops. Since the control tree is scoped to the individual portal and since a desktop behaves much like a portal, each desktop has its own tree and the controls on that tree are built only when that desktop is opened. Thus, by splitting a complex portal with a large control tree into multiple desktops, you reduce the number of controls on the tree to just that number necessary for the active desktop. As you might guess, this reduces the amount of time required to render the portal as a single desktop and increase portal performance.

B

When a portal is rendered, about 15% of the processing time is dedicated to constructing the control tree, 70% to running the life cycle methods, and 15% in garbage collection (clearing dead objects from the heap, thus releasing that space for new objects). While construction and garbage collection are always performed, running the life cycle methods is necessary only for visible controls (that is, those on the exposed desktop). This results in considerable overhead savings and improved system performance. For example, the sample control tree depicted in Figure 12-1 shows a single portal with 42 controls. Were we to split this portal up into multiple desktops, as in Figure 12-3, while we would increase the number of control trees in the entire portal, each tree would be nearly two thirds smaller, and thus be processed in roughly two-thirds the time, significantly reducing the time required to render the portal.

12-4

BEA WebLogic Portal Portal Development Guide

Us ing Multiple Desktops

ET

A

Figure 12-3 Simple Portal Split into Multiple Desktops

B

Figure 12-4 shows how the example in Figure 12-3 might be rendered once opened.

BEA WebLogic Portal Portal Development Guide

12-5

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

Figure 12-4 How Multiple Desktops Reduce Control Tree Size

ET

A

When this desktop is opened, a control tree is constructed using only the controls on that desktop...

...while all other controls are ignored.

Design Decisions for Using Multiple Desktops

B

As these examples demonstrate, splitting a complex portal into multiple desktops can be very rewarding in terms of improved performance; however, not all portals benefit from the extra effort required to split them into multiple desktops. Before implementing a portal using multiple desktops, you need to consider some important design decisions. For example: How many controls does your portal use? If the portal is small (about ten pages or less) or uses a limited number of controls, the extra effort necessary to create multiple desktops might not be necessary. Can your portal be logically divided into multiple desktops? While splitting a complex portal into multiple desktops might save rendering time, arbitrarily assigning portlets to those desktops, with no thought to their interrelationships, can be dangerous. Visitors might have a negative experience with the application if related information is not easily located, particularly if it is on a desktop separate from where it might logically go.

12-6

BEA WebLogic Portal Portal Development Guide

Optimizing the Control Tree

What sort of administrative overhead is required once the multiple desktops are deployed into production? For example, if you have 20 different potential desktops, a big consideration is how common they will be. If they are more alike than different, then using fewer desktops is better because there will be fewer administrative tasks to perform. Are there customization concerns? Each desktop must be customized separately, which can add significant additional effort for portal developers and administrators. However, note that portal administrators can make changes in the library that will affect all desktops in the portal.

A

Can you afford to lose some functionality in your portal? For example, if your application relies on interportlet communication, either through Page Flows or backing files, you might be better off not splitting-up the portal, as listeners and handlers on one desktop cannot communicate with their counterparts on other desktops. For portlets to communicate with each other, they must be on the same desktop; your portal design must take this requirement into consideration.

ET

For more information on creating desktops, please refer to “Creating a Portal and Desktop” on page 13-7.

Optimizing the Control Tree

Tree optimization, as the name implies, means that control tree rendering is done in a way that creates the least amount of system overhead while providing the user with as complete a set of portal controls as that user needs to successfully use the portal instance.

B

Note: Asynchronous portlet rendering can be used with control tree optimization. For more information about asynchronous portlet rendering, refer to the Portlet Development Guide.

Enabling Control Tree Optimization You enable control tree optimization by setting the treeOptimizationEnabled flag in the .portal file to true, as shown in Listing 12-1. Listing 12-1 Enabling Tree Optimization in .portal <desktop> element:
BEA WebLogic Portal Portal Development Guide

12-7

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

definitionLabel="defaultLookAndFeel">

Note: If treeOptimizationEnabled= is not included in the .portal file, the portal defaults to treeOptimizationEnabled=false. ***** When this flag set to true, the portal framework generates a partial control tree instead of the full control tree, basing this tree on just the controls that are visible and active. Thus, with fewer controls needing to be rendered, processing time and expense can be significantly reduced. For portals, you can enable this flag by setting Tree Optimization to true in the Workshop for WebLogic Properties Editor, as shown in Figure 12-5.

B

ET

A

Figure 12-5 Enabling Tree Optimization in Workshop for WebLogic

For desktops, you can set the flag from the Administration Portal, as shown in Figure 12-6. Figure 12-6 Enabling Tree Optimization from the Administration Portal

12-8

BEA WebLogic Portal Portal Development Guide

Optimizing the Control Tree

Note: For new desktops, treeOptimizationEnabled="true" is the default value, so you really do not need to set anything in that circumstance.

Setting the Current Page Before the flag can actually work, the file url-template-config.xml (in /webAppName/WEB-INF) must have {url:currentPage} set in the element, as shown in Listing 12-2. Note: When you create a new project in WebLogic Workshop, currentPage is added automatically; however, if you are migrating from an earlier version of WebLogic Portal, you must manually update url-template-config.xml.



A

Listing 12-2 url-template-config.xml URL Templates Component

ET

{url:scheme}://{url:domain}:{url:port}/{url:path}?{url:queryString} {url:currentPage}



{url:scheme}://{url:domain}:{url:port}/{url:prefix}/{url:path}? {url:queryString}{url:currentPage}

B

https://fin.domain.com:7004/{url:prefix}/{url:path}?{url:queryString} {url:currentPage}&dept=finance {url:scheme}://{url:domain}:{url:port}/{url:prefix}/{url:path}? {url:queryString}{url:currentPage} http://{url:domain}:{url:port}/{url:path}?{url:queryString} {url:currentPage} http://{url:domain}:{url:port}/{url:path}?{url:queryString}

BEA WebLogic Portal Portal Development Guide

12-9

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

{url:currentPage}

How Tree Optimization Works When the portal servlet receives a request (that is, a mouse-click) it reads the cache to determine if a control tree factory exists. If one doesn’t, it calls controlTreeFactoryBuilder, passing it the XML from the .portal file. This class returns a control tree factory to the servlet, which passes the request to the CreateUIControlTree class. Assuming _pageLabel and treeOptimizationEnabled="true", CreateUIControlTreeFactory calls the PartialUIControlTreeCreator() method, which

A

returns a control tree comprised of just the control identified by the page label and the set of active page and book labels; this is a partial control tree.

ET

For example, if tree optimizations were enabled for the portal depicted in Figure 12-4, when you submit a request (that is, a mouse click), only the active controls would be rendered, as illustrated in Figure 12-7. Figure 12-7 How Tree Optimization Reduces Control Tree Size With

treeOptimizationEnable=true,

B

only the controls that are active in the session will be rendered...

12-10

BEA WebLogic Portal Portal Development Guide

...while all other controls are ignored.

Optimizing the Control Tree

The set of active page and book labels for that session stored during the saveState() life cycle method execution tell PartialUIControlTreeCreator() which controls to build. Only these controls will be built; all others in the portal are ignored. As you can see, a significant amount of processing overhead is eliminated when the control tree is optimized—since far fewer controls need to be built—resulting in greatly improved performance.

Limitations to Using Tree Optimization If you are creating complex portals that require a large number of controls, tree optimization is the easiest way to ensure optimal portal performance. Controls that aren’t active in the current portal instance aren’t built, saving considerable time and overhead. Nonetheless, you need to be aware that tree optimization slightly changes a portal’s behavior and some portal implementations will not have substantial benefit; for example:

A

The backing file life cycle methods init() and handlePostBackData(), which are called when the backing file is executed—even for non-visible controls—are not called when tree optimization is enabled, unless they appear on visible controls.

ET

If your portal uses backing files on any of their controls, some backing context APIs are limited in their functionality. On DesktopBackingContext, BookBackingContext, and PageBackingContext, the following methods return null if they are trying to access a page, book, or portlet that is not in the partial tree

B

– public BookBackingContext getBookBackingContextRecursive(String definitionLabel) – public PageBackingContext getPageBackingContextRecursive(String definitionLabel) – public PortletBackingContext getPortletBackingContextRecursive(String instanceLabel) – public PortletBackingContext[] getPortletsBackingContextRecursive(String definitionLabel)

You might experience the same behavior—or lack thereof—on DesktopPresentationContext, BookPresentationContext, and PagePresentationContext with the presentation versions of these methods: – public BookPresentationContext getBookPresentationContextRecursive(String definitionLabel) – public PagePresentationContext getPagePresentationContextRecursive(String definitionLabel)

BEA WebLogic Portal Portal Development Guide

12-11

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

– public PortletPresentationContext getPortletPresentationContextRecursive(String instanceLabel) – public PortletPresentationContext[] getPortletsPresentationContextRecursive(String definitionLabel)

If your portal uses multi-level menus you need to decide if the benefit of multilevel menus outweigh any performance hit. If the menu is on an active book, every control accessible from that menu must be created before the portal is completely rendered, thus more overhead and a greater performance hit. On the other hand, because a multilevel menu results in the creation of a skeletal control tree, it can reduce the number of request cycles required to navigate to your desired destination, reducing the total overhead required to accomplish a navigation.

A

If your portal uses Programmatic Page Change Events called from a backing file and the page to which the change is being directed is not within the partial control tree, it does not exist in the instance and the page change will not occur.

ET

You can work around this problem by doing one of the following (this is the preferred order): a. Use a link to perform the page change.

b. Use the new declarative interportlet communications model. c. Implement a redirect from within the backing file.

B

d. Set _nfto=”false” in the invoking link. This causes the full control tree to be created for that single request. e. Turn off tree optimization altogether on the portal. If your portal uses “cookie” or “url” state locations, the partial control tree will not work. If your portal uses non-visible portlets, the onDeactivation portlet events for non-visible portlets might not work with portal tree optimization turned on. When the “tree optimization” flag in a .portal file is turned on, not all non-visible portlets for a given request are processed. (A non-visible portlet is one that lives on a page that is not displayed for the given request.) This can be a problem if you are trying to catch an onDeactivation event for a portlet—once the portlet has been deactivated, it is no longer visible, and so the system doesn't process it to fire its deactivation event. The recommended workaround is to set tree optimization to false for the portal in question. However, there is a trick you can play if you need the tree optimization. For each portlet that you want to catch deactivation events for, define a dummy event handler (for example,

12-12

BEA WebLogic Portal Portal Development Guide

Pluggable F ramework Cache

create a custom event handler with event = "[some nonsense string]" and set the property “Only If Displayed” to false. This forces the system to process the portlet whether visible or not. Mindful of these conditions, never set treeOptimizationEnabled to true without first doing a complete regression test on the portal. If any of the above-listed problems occur, you might want to rethink your portal design or disable tree optimization completely.

Disabling Tree Optimization

A

As discussed above, although control tree optimization can benefit almost any portal, behavioral limitations might require that you disable it. When you disable optimization, the portal creates a full control tree upon every request. Be aware that this could significantly impede the performance of very large portal. You need to decide whether the anticipated performance hit is offset by the improvement in functionality. To disable tree optimization, do one of the following:

Set treeOptimizationEnabled= “false” in the .portal file or on the desktop.

ET

Include nfto=”false” in the request parameter of just that instance for which you want to disable tree optimization. The parameter needs to be added to URL programmatically as the URLs are generated using framework classes GenericURL and PostbackURL; for more information on these classes, see the WebLogic Portal Javadoc. The following code shows one way to adding this parameter: PostbackURL url = PostbackURL.createPostbackURL(request, response);

B

url.addParameter(GenericURL.TRE_OPTIMIZATION_PARAM, "false");

Use one of the tags in the render tag libraries. Delete the _pageLabel parameter from the request.

Pluggable Framework Cache TBD

Other Ways to Improve Performance In addition to managing the taxonomy of your portal through effective use of the control tree, WebLogic Portal offers other ways to improve performance. These solutions can all be used in concert with multiple desktops and control tree optimization, ensuring superior portal

BEA WebLogic Portal Portal Development Guide

12-13

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

performance. This section describes the most effective performance-enhancing solutions available with WebLogic Portal.

Use Entitlements Judiciously Entitlements determine who can access the resources in a portal application and what they can do with those resources. This access is based on the role assigned to an application visitor, allowing for flexible management of the resources. For example, if you have an Employee Review portlet, you can assign the “Managers” visitor entitlement role you created to that portlet, letting only logged in users who belong in that role view the portlet.

ET

How Entitlements Affect Performance

A

Users visiting an application are assigned roles based on an expression that can include their name, the group that they are in, the time of day, or characteristics from their profile. For example, the “gold member” role could be assigned to a user because they are part of the frequent flyer program and have flown more than 50,000 miles in the previous year. This role is dynamically assigned to the user when they log into the site.

To ensure optimal portal performance, use entitlements judiciously. Too many entitlements can significantly impact performance. This happens because the entitlement engine is called during the render phase of an operation and is required to check system overhead and rules. Because this checking represents additional system overhead, if it is required too often on a portal, performance degrades. In addition, the entitlements engine is also responsible for managing administrative tasks, which increases that overhead, again causing degrading performance.

B

By default, entitlements are stored in the database as opposed to LDAP. Nonetheless, always be aware that too many entitlements can impede performance.

Recommendations for Using Entitlements Here are some simple recommendation for using entitlements judiciously: Avoid the temptation to create a role for every node on an organizational chart. In large organizations, granting entitlements would then become a serious burden on the system. If you want to focus the user experience to a more granular level than that provided by the role assigned a user, consider employing the personalization capabilities available with WebLogic Portal. Disable entitlements if a portal is not using any security policies. If a portal is using security policies enable it and set the value for the attribute to equal the number of desktops +

12-14

BEA WebLogic Portal Portal Development Guide

Othe r Ways to Improve Performance

number of books + number of pages + number of portlets + number of buttons (max, min, help, edit) used in a portal. Use the default value if you are concerned about available memory. Limit your entitlement request to only one resource at a time. Bundling a larger number of resources (portlets, pages, books) with one entitlement request can cause an unwanted performance hit. If your portal uses more than 5000 entitlements, customize the cache settings for WebLogic Entitlements Engine. For details, see the Performance Tuning Guide.

Limit User Customizations

A

BEA recommends that you allow users (visitors) to modify only one page or a small set of pages, and require that administrators control the remainder of pages.

ET

When users customize a page, they obtain their own instance of that page. All other pages that have not been customized point back to the original library instance. When an administrator makes a change to a page, that change must iterate for each user who customized the page. If many users customized that page, propagating the change might take a long time because of the required database processing.

Optimize Page Flow Session Footprint

B

If your portal uses Page Flows portlets in a replicated clustering environment, you might experience a performance issue because the request attributes you add to these portlets might be persisted to the session as a component of a Page Flow portlet’s state. As more request attributes are added, the session grows, often to sizes that can severely restrict performance. Page Flow portlets are hosted within the Portal framework by the Scoped Servlet environment. This environment effectively acts as a servlet container, but its behavior causes the request attributes to be scoped to the session within a container class used to persist Page Flow state. This can be particularly unwelcome in clustered environments, when large amounts of data— including these Page Flow portlet request attributes—might be replicated across the cluster. WebLogic Portal provides the requestAttrPersistence attribute for Page Flow portlets. requestAttrPersistence is included in the .portlet file and can be set by from the Properties Editor in WebLogic Workshop. requestAttrPersistence has these values:

BEA WebLogic Portal Portal Development Guide

12-15

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

session: this is the existing behavior (this is the default). All existing Page Flow portlets should not require changes by default. transient-session: places a non-serializable wrapper class around a persisted Page Flow state object into the session. These portlets work just as the existing portlets, except in failover cases, where the persisted request attributes disappear on the failed-over-to server. In these cases you must write the forward JSPs to gracefully handle this contingency by, at minimum, not expecting any particular request attribute to be populated and, ideally, by having a mechanism to either repopulate the request attributes 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. While session memory is still consumed in this case, there will be no additional cluster replication costs for the persisted request attributes.

A

none: performs no persistence operation. Since these portlets never have request attributes

available on refresh requests, you must write the forward JSPs to assume the request attributes will not be available. This option is helpful when you want to remove completely the framework-induced session memory loading for persisted request attributes.

ET

To set the request attribute persistence attribute for a page flow portlet, open the Request Attribute Persistence drop-down under the Page Flow Content group in the WebLogic Workshop Properties Editor and select the desired value, as shown in Figure 12-8.

B

Figure 12-8 Selecting Request Attribute Persistence Attribute

Use File-Based Portals for Simple Applications Portals come in two flavors: file-based and streaming. As the name implies, a file-based portal— also called a “light portal”—obtains all of its resources from the user’s file system. Streaming portals, on the other hand, derive their resources from one or more databases. A key difference between the two implementations is in the method you use to create and manage multiple portlet instances. Using a streamed portal, managed using the WebLogic Portal Administration Console, you can manage a single instance of a portlet while reusing it in many places; you can also easily create a large number of portlet instances and configure each one differently. Using a file-based portal you need to create individual source portlets within .portal files.

12-16

BEA WebLogic Portal Portal Development Guide

Othe r Ways to Improve Performance

Streaming portals also provide you with the management capabilities of the Administration Console. For example, if you want to disable a portlet, you can do this task easily from the Administration Console; otherwise, you must directly access the production servers to change .portal files. The Administration Console also provides management functionality for book and page contents, and the ability to user visitor entitlements and delegated administration on different instances of resources.

Why Use a File-based Portal? For simple, static portals, deriving resources from the file system can result in improved performance and bring these benefits: Source code control is easily manageable.

A

Propagation to other environments is easy. They are easy to create in WebLogic Workshop.

Limitations to Using File-based Portals

ET

While file-based portals might show some performance improvement over streaming portals, their functionality is limited; for example, because no database is involved, you cannot take advantage of things such as user customization or entitlements. Other features that are missing from a file-based portal include: Delegated Administration

B

Visitor Tools

Preferences at the portal instance level and at the definition level. Moreover, in the majority of cases, the performance improvement gained by using a file-based portal is not so significant as to outweigh these limitations.

Create a Production Domain in Development While this tip doesn’t directly improve performance at runtime, it nonetheless allows you to see how your application will perform before you propagate it to production. By creating a production domain in development, you can simulate and then evaluate how the portal will perform in production. You can then make the necessary adjustments before actually deploying the portal. If problems occur or performance is not optimal, you can rectify these situations before the end user ever sees them.

BEA WebLogic Portal Portal Development Guide

12-17

D e s i g ni ng P o rt a l s f o r O p tim a l P e r fo rm a nc e

To create a production domain, you must update the startup script settings by setting the WLS_PRODUCTION_MODE= flag to true and setting to false these flags: iterativeDevFlag debugFlag testConsoleFlag logErrorsToConsoleFlag pontbaseFlag verboseLoggingFlag

A

Additionally, you must set default values for the threadcount and the JDBCConnectionPool sizes. If you are threading portlets (that is, using forkable=true) ensure that you configure a portalRenderQueue and portalPreRenderQueue in your config.xml file so that the forked portlets use their own thread pools and not the WebLogic thread pool. The following code sample describes how to set the thread count appropriately: <ExecuteQueue Name="default" ThreadCount="15"/>

ET

<ExecuteQueue Name="portalRenderQueue" ThreadCount="5"/>

Optimize Portlet Performance

You can optimize the performance of the portlets in your portal in several ways, including the following:

B

Editing performance-related portlet properties to optimize performance Caching portlets

Using remote portlets

Pre-rendering and rendering portlets in parallel Rendering portlet content asynchronously Using backing files You can find more detail on each of these alternatives in the Portlet Development Guide.

12-18

BEA WebLogic Portal Portal Development Guide

A

Part III Staging

Introduction TBD.

B

ET

For a view of how the tasks in this section relate to the overall portal life cycle, refer to the BEA WebLogic Portal Overview.

Part III includes the following chapters: Chapter 13, “Creating Portal Desktops” Chapter 14, “Deploying Portals to Production”

BEA WebLogic Portal Portal Development Guide

A ET B 12-2

BEA WebLogic Portal Portal Development Guide

C H A P T E R 13

A

Creating Portal Desktops

Note for Beta Release - Many of the existing tasks in this chapter are described in a “tutorial” format based on the Getting Started with WebLogic Portal tutorials. The descriptions of these tasks (and completion of the remaining task descriptions) will be expanded for the GA release.

B

ET

You perform the tasks described in this chapter to prepare your portal application for public consumption. From an administrative standpoint, a portal is a container that defines a portal application. When you create a new portal in the administration portal, you are really creating an empty portal to hold different versions of the portal (desktops) that can be targeted to specific users. A portal can contain one or more desktops, or views, of a portal. It is the desktops to which you add the portal resources and navigation such as books, pages, and portlets that make a dynamic portal. After you assemble the desktops, you can configure and test the application as a whole, and then deploy it to the production environment when it is ready for public access. The primary tool used in this chapter is the WebLogic Portal Administration Console. This chapter contains the following sections: Administration Console Overview Administration Console Library of Resources Starting and Logging In to the Administration Console Portals and Desktops

BEA WebLogic Portal Portal Development Guide

13-1

C re at i n g P o r ta l D e s k t o ps

Administration Console Overview The WebLogic Portal Administration Console is the tool that portal administrators use to not only control the behavior, content, and appearance of portals, but to perform many traditional system administration activities such as user management and security management. The WebLogic Portal Administration Console is organized according to the following categories of tasks: Portal Management – Portals, desktops, books, pages, portlets, and other portal resources. This guide and the Portlet Development Guide provide details about Portal Management tasks.

A

User, Groups, & Roles – User and group management, security provider configuration, Delegated Administration, and Visitor Entitlements. The User Management Guide and Security Guide provides detailed information about the tasks in this category.

ET

Configuration Settings – Server settings for Cache Management, Server Maintenance Mode, Personalization, Security, Unified User Profiles, and WSRP. This guide, Security Guide, Federation Guide, Interaction Management Guide, User Management Guide, and Performance Tuning Guide provide detailed information about the tasks in this category.

B

Interaction Management – Campaigns, Placeholders, User Segments, And Content Selectors. The Interaction Management Guide provides detailed information about the tasks in this category. Content Management – Content and repositories. The Content Management Guide provides detailed information about the tasks in this category.

Administration Console Library of Resources When you create a new desktop using the Administration Console, you can use an existing portal template. Using a template means that you take the portal resources for your desktop directly from a .portal file that was created in Workshop for WebLogic. (The .portal file is also called the primary instance.) When you create a desktop, the portal assets are removed from the

13-2

BEA WebLogic Portal Portal Development Guide

S ta rt in g an d L ogg in g In to th e A dmi nis tr at io n Con so le

.portal file, placed in a database, and surfaced in both the Library and desktop trees of the Administration Console. Taking the assets from a new desktop instance and placing them in the Library is called disassembling.

At this point, the assets (books, pages, and so on) in the Library (Library instances) are hierarchically related to their corresponding desktop instances. A change to a Library resource, such as a name change, is automatically inherited by the corresponding desktop asset. On the other hand, a change to the desktop asset is not reflected back up the hierarchy. Note: Changes made to assets are never “reverse inherited” up the hierarchy. A change to a desktop asset is never inherited by its corresponding Library instance. Likewise, a change to a Visitor instance is never inherited by a desktop or Library instance. New books and pages that you create in a desktop are not disassembled—they are considered to be private to that desktop.

A

Plan your implementation to make the best use of this WebLogic Portal functionality. Refer to the Production Operations Guide for more details about disassembling and decoupling of resources in the Administration Console.

ET

Starting and Logging In to the Administration Console Opening the Administration Console

B

Before you can begin using the WebLogic Portal Administration Console, the server must be running. Depending on the state of your Workshop for WebLogic workbench, you might need to start the server before opening the Administration Console. Follow these steps:

1. Start Workshop for WebLogic and open a workspace: 2. In the Servers view, click the server to select it. 3. Click Start

in the Servers view toolbar.

Wait while Workshop for WebLogic starts the server. This process might take some time, depending on the speed of your system.When the process completes, the Status column in the Servers view displays Started and the square Stop the Server button becomes active. 4. In the Package Explorer view, select the .portal file for the portal you want to manage with the Administration Console.

BEA WebLogic Portal Portal Development Guide

13-3

C re at i n g P o r ta l D e s k t o ps

5. From the main menu, select Run > Open Portal Administration Console, as shown in the example in Figure 13-1.

A

Figure 13-1 Menu Selection for Run > Open Portal Administration Console

ET

The Administration Console window opens in a new tab in the workbench editor view, with the login dialog displayed, as Figure 13-2 shows. Note: If you set up your Workshop for WebLogic preferences to open external browsers instead of the internal browser, a separate window opens to display the Administration Console login dialog.

B

Figure 13-2 WebLogic Portal Administration Console Login Dialog

13-4

BEA WebLogic Portal Portal Development Guide

S ta rt in g an d L ogg in g In to th e A dmi nis tr at io n Con so le

Logging In to the Administration Console The Administration Console login dialog requires a WebLogic Server system administrator or a WebLogic Portal administrator user name and password. WebLogic Server system administrators have full security privileges for the entire domain and can log in to and use the WebLogic Server Administration Console tools. WebLogic Portal administrators have full security privileges for a Portal Web Project, which can include multiple portals. Table 13-1 shows the default system administrator user names and passwords: Table 13-1 Default User Names and Passwords for the WebLogic Portal Administration Console Password

Description

portaladmin

portaladmin

Administrator for the portal domain

weblogic

weblogic

WebLogic Server system administrator with full privileges in the domain

A

User Name

ET

To log in to the WebLogic Portal Administration Console, follow these steps: 1. Type the appropriate user name and password into the dialog and click Sign In. The main menu of the Administration Console displays. in the editor view

B

2. To get a better view of the console and its functions, click Maximize toolbar. Your display should look like the example in Figure 13-3.

Note: If you set up your Workshop for WebLogic preferences to open external browsers instead of the internal browser, you do not need to perform this step.

BEA WebLogic Portal Portal Development Guide

13-5

C re at i n g P o r ta l D e s k t o ps

ET

A

Figure 13-3 Administration Console Main Page, Maximized

B

Portals and Desktops

Desktops are the application views of a portal that are accessed by visitors to a site. A desktop is contained within a portal, and there may be multiple desktops within each portal. A desktop contains all the portlets, content, and Look & Feel elements necessary to create individual user views of a portal. All users access the default desktop before they define their own desktops. Figure 13-4 shows an example of a possible desktop hierarchy. Figure 13-4 Example of Portal Desktop Hierarchy

13-6

BEA WebLogic Portal Portal Development Guide

Portals and Desktops

You can create one or more desktops per portal, and tailor each desktop for a target audience. Book and page resources are often created by developers in Workshop for WebLogic. In order to make these resources visible in the library, you must create a desktop in the Administration Console using the portal created in Workshop for WebLogic as the template. For example, if a developer creates book and page resources in a portal called NewTestPortal in Workshop for WebLogic, you must create a new desktop and select the NewTestPortal.portal as your template for the desktop.

Creating a Portal and Desktop To create a desktop, you first create a portal to contain it. To create a portal and desktop, follow these steps:

A

1. Click the Portal Management menu shortcut on the Administration Console home page. The Portal Management page displays; the Portal Resources tree displays in the left pane of the page, as shown in Figure 13-5.

B

ET

Figure 13-5 Portal Resources Tree in the Administration Console

Notice that the display is based on the portal that you selected before you opened the Administration Console. If you expand the Library > Portlets portion of the tree, you can see any portlets that exist for that portal. 2. Click Portals in the tree. The Portals page displays, with the Browse Portals tab active. If no portals exist yet, the table containing portals is empty. 3. Click Create New Portal.

BEA WebLogic Portal Portal Development Guide

13-7

C re at i n g P o r ta l D e s k t o ps

The Create a New Portal dialog displays, Figure 13-6 shows an example.

A

Figure 13-6 Create a New Portal Dialog in Administration Console

4. Enter values for the portal, using Table 13-2 as a guide:

ET

Table 13-2 Create a New Portal Dialog Field Descriptions Field

Value/Description

Portal Name

Required. Name of the portal you want to add.

Description

Optional description of the portal.

B

Partial URL URI (default resource)

5. Click Create New Portal.

When the Portals page displays again, the Browse Portals table includes the portal you created, and the Portal Resources tree includes the new portal. 6. Click myBEAportal in the Browse Portals table to view the details for this portal. The Portals page displays, with the Browse Desktops tab active. Because no desktops exist yet, the table containing desktops is empty. 7. Click Create New Desktop. The Create Desktop wizard displays, as shown in Figure 13-7.

13-8

BEA WebLogic Portal Portal Development Guide

Portals and Desktops

B

ET

A

Figure 13-7 Create Desktop Wizard in Administration Console

8. Enter values for the desktop in the appropriate wizard pages, using Table 13-3 as your guide:

BEA WebLogic Portal Portal Development Guide

13-9

C re at i n g P o r ta l D e s k t o ps

Table 13-3 Create Desktop Wizard Field Descriptions Field or Selection

Value/Description

Step 1: Select how you want to create a desktop...

1. Select the appropriate radio button based on the object you want to use as a template for the new portal:

– Use a desktop template – Select resources in the Library – Select a portal file 2. Click Next. Step 2: Search for templates 1. For You can search for an Show All.

A

Desktop template

The portal you created using Workshop for WebLogic displays in the list. 2. Click to select.

Select Resources in the Library

ET

3. Click Next.

1. For You can search for an Show All. The portal you created using Workshop for WebLogic displays in the list.

2. Click to select myPortal.portal. 3. Click Next.

1. For You can search for an Show All.

B

Select a portal file

The portal you created using Workshop for WebLogic displays in the list.

2. Click to select myPortal.portal. 3. Click Next.

Step 3: Enter desktop properties...

•

Title –

•

Description –

•

Partial URL –

•

Default Shell –

•

Look and Feel –

9. Click Next to create the desktop.

13-10

BEA WebLogic Portal Portal Development Guide

Portals and Desktops

A confirmation dialog confirms that the desktop has been created and displays related information. 10. Click Finish to return to the main Administration Console page. The Browse Desktops table includes the desktop you created, and the Portal Resources tree includes the new desktop, as shown in Figure 13-8, which shows the expanded tree.

ET

A

Figure 13-8 New Desktop in Portal Resources Tree

Notice that the portlets that you created for this portal (which was used as the template for this desktop) appear automatically in the new desktop.

Creating Desktop Templates

B

When you create a desktop using a template (.portal file) in WebLogic Administration Portal, each resource of that desktop (such as books, pages, and portlets) has a Definition Label that serves as a unique ID for that component in the database. If you create a new desktop out of a template that contains portal resources with Definition Labels that are identical to resources already stored in the database, you will receive the following warning.

BEA WebLogic Portal Portal Development Guide

13-11

C re at i n g P o r ta l D e s k t o ps

Use the following information for guidance in updating portal resources when you receive this warning: Table 13-4 Details for each selection when updating or replacing resources Description

Keep portal resources already in the library

Ignores the resources in the template and leaves the database version of the resources intact, including any user customizations that have been made.

Replace conflicting portal resources with template version

Uses the template to replace the database version of all conflicting resources and adds new, non-conflicting resources to the database.

Replace markup with template version

Keeps user customizations but allows replacement of resource XML markup; for example, a change in a portlet's modes or a change in a portlet's Content URI.

A

Option

ET

If you want to replace specific portal resources, use Workshop for WebLogic to create a “dummy” .portal file containing the portal resources that you want to update (portal components with the Definition Labels you want to update in the database), create a new desktop with that template in the WebLogic Portal Administration Console, and select the appropriate “Replace” option in the warning box that appears.

Create a New Page on the Desktop

B

In this task, you will create a new page for your desktop. Follow these steps: 1. In the Portal Resources tree for myPortalWebProject, expand the tree to display the pages for the desktop, as shown in Figure 13-9.

13-12

BEA WebLogic Portal Portal Development Guide

Portals and Desktops

Figure 13-9 Expanded Portal Resources Tree Showing Desktop Pages

B

ET

Figure 13-10 Browse Pages Tab

A

2. Click Pages to display the Browse Pages tab, as shown in Figure 13-10.

3. Click Create New Page. The Create New Page dialog displays, as shown in Figure 13-11.

BEA WebLogic Portal Portal Development Guide

13-13

C re at i n g P o r ta l D e s k t o ps

Figure 13-11 Create New Page Dialog in Administration Console

Table 13-5 Create New Page – Field Descriptions Value/Description

Title

Tutorial Page

Description

new page for tutorial

Layout

Three Column Layout

Theme

(leave as is - None)

B

ET

Field

A

4. Enter values for the new page, using Table 13-5 as a guide:

5. Click Create.

The new page is added, and is displayed in the Details page for the desktop; the Portal Resources tree updates to include the new page, as shown in Figure 13-12.

13-14

BEA WebLogic Portal Portal Development Guide

Portals and Desktops

B

ET

A

Figure 13-12 New Page Added to the Portal Resources Tree

BEA WebLogic Portal Portal Development Guide

13-15

B

ET

A

C re at i n g P o r ta l D e s k t o ps

13-16

BEA WebLogic Portal Portal Development Guide

C H A P T E R 14

A

Deploying Portals to Production

This chapter is TBD

ET

Propagation refers to the process of moving the database and LDAP contents of one portal domain environment to another. BEA provides tools to help with portal propagation. These tools not only move database assets and LDAP information, but they also report differences and potential conflicts between the source and the target environments. You can define policies to automatically resolve conflicts, or an administrator can view a list of differences and decide the appropriate actions to take on a case-by-case basis.

B

Propagation tools are described in detail in the Production Operations Guide. The Production Operations Guide also helps you through the process of planning a strategy for propagation and provides detailed information on best practices. This chapter describes the tasks associated with propagating (deploying) your portal from the staging environment to the production environment when it is ready for public access. The primary tools used in this chapter are the WebLogic Portal Propagation Utility (to move database and LDAP data between staging, development, and production), WebLogic Server application deployment tools, and any external content or security providers you are using.

BEA WebLogic Portal Portal Development Guide

14-1

B

ET

A

Depl oyin g P or ta ls to Pr od uc ti on

14-2

BEA WebLogic Portal Portal Development Guide

Introduction TBD.

A

Part IV Production

For a view of how the tasks in this section relate to the overall portal life cycle, refer to the BEA WebLogic Portal Overview.

B

ET

.

Part IV includes the following chapter: Chapter 15, “Creating and Managing Portals”

BEA WebLogic Portal Portal Development Guide

A ET B 14-2

BEA WebLogic Portal Portal Development Guide

C H A P T E R 15

A

Creating and Managing Portals

B

ET

This chapter is TBD.

BEA WebLogic Portal Portal Development Guide

15-1

B

ET

A

C re at i n g a nd M an ag i ng P o r ta l s

15-2

BEA WebLogic Portal Portal Development Guide