BEA WebLogic

Portal A ™
ET
Portal Development
Guide
B

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.
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.

Trademarks and Service Marks

A
Copyright © 1995-2006 BEA Systems, Inc. All Rights Reserved. BEA, BEA JRockit, BEA WebLogic Portal, BEA
ET
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
B

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
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

A
Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Staging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
ET
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Related Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Part I. Architecture
B

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
Java Controls in Portals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

A
JSPs and JSP Tags in Portals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Page Flows in Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
ET
Why are Page Flows Useful? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
State/Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

4. The Portal Framework

Framework Terms, Acronyms, and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
B

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
New Portal Web Project – Select Project Facets dialog . . . . . . . . . . . . . . . . . . . . . . 5-12

A
New Portal Web Project - Web Module Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
New Portal Web Project - WebLogic Web Module Dialog . . . . . . . . . . . . . . . . . . . 5-15
Portal Datasync Project Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
ET
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
Customizing a Workbench Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
B

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
Gene Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

A
Creating a Chromosome and Genes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Guidelines for Using Genes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
ET
Using the Genes API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Creating a Look & Feel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
The Look & Feel Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5

9. Developing Portals Using Workshop for WebLogic

B

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

[Link] 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

[Link] Visitor Tools

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

[Link] Portals for Optimal Performance

Control Tree Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

A
How the Control Tree Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
How the Control Tree Affects Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Using Multiple Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
ET
Why This is a Good Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Design Decisions for Using Multiple Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Optimizing the Control Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
Enabling Control Tree Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
B

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

[Link] 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
Creating a Portal and Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7

A
Creating Desktop Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11
Create a New Page on the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12
ET
[Link] Portals to Production
Part IV. Production
[Link] and Managing Portals
B

viii BEA WebLogic Portal Portal Development Guide

 CHAPTER 1

Introduction to Portals

portal life cycle.

This chapter contains the following sections:
A
This chapter introduces portal concepts and describes how the content of this guide relates to the
ET
What is a Portal?

What is the Portal Framework?

Portal Development and the Portal Life Cycle

Getting Started
B

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.

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

Search – Enterprise and web-based search facilities

ET
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:

Workflow – Business process management

B

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.
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

A
which pieces of the underlying framework you need to modify to obtain the results you want.
A detailed explanation of the portal framework components is provided in Chapter 4, “The Portal
Framework.”
ET
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
Development
B

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 –
Development –
Roll out your portals to a
Use Workshop for
production environment,
WebLogic to create portals,
making changes as
portlets, pages, and books
needed

Staging –

A
Use the WebLogic Portal
Administration Console to create
and configure desktops
ET
Architecture
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.
B

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”

Chapter 11, “Configuring Visitor Tools”

A
Chapter 12, “Designing Portals for Optimal Performance”

Staging
ET
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.
The chapters describing tasks within the Staging phase include:
B

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,

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

A
Complete the tutorial Getting Started with WebLogic Portal.

Related Guides
ET
BEA recommends that you review the following guides:

BEA WebLogic Portal Architecture Guide

BEA WebLogic Portal Overview

BEA WebLogic Portal Portlet Development Guide

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

1-6 BEA WebLogic Portal Portal Development Guide

Part I Architecture

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

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

Planning Your Portal

A
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.
ET
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.
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.
B

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)

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

A
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.
ET
Figure 2-1 Typical WebLogic Portal Environments
B

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.
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

Portal Production Operations User’s Guide.

Federated Portals
A
up your development environment, refer to the Team Development chapter of the BEA WebLogic
ET
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.
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
B

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
You can control access to portlet resources for two categories of users:

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

Portal administrators – You control portal resource management capabilities using

ET
delegated administration. Administrative access is determined based on delegated
administration roles.
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
B

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
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

decisions.
A
significant performance improvement can be realized by making just a few critical design

Here are some examples of performance optimizations that you can plan into your overall portal
strategy:
ET
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.

If your portal is small or relies only on static resources, you might experience some
B

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.
For instructions on how to implement your portal for use on mobile devices, refer to Chapter 10,
“Creating Portals for Multiple Device Types.”

A
ET
B

2-6 BEA WebLogic Portal Portal Development Guide

Part II Development

Introduction TBD.
A
ET
B

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”

Chapter 12, “Designing Portals for Optimal Performance”

A
ET
B

2-2 BEA WebLogic Portal Portal Development Guide

 CHAPTER 3

Understanding Portal Development

Some sections are not updated for Version 9.2

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

Portal Hierarchy

Portal Development Environment in Workshop for WebLogic

Portal Resources in the Database

About Library Modules

B

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.”

Figure 3-1 Portal Hierarchy

A
ET
B

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.
This section describes WebLogic Portal features in the workbench from the perspective of the
portal developer.
A
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
ET
how your Workshop for WebLogic workbench might look during development of a portal.
B

BEA WebLogic Portal Portlet Development Guide 3-3

Understanding Portal Devel opme nt

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

A
ET

1. Package Explorer view – Shows the hierarchy of directories for the open project, and the
B

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
For detailed information about the content of WebLogic Portal database tables, refer to the BEA
WebLogic Portal Database Administration Guide.

About Library Modules A

WebLogic Portal library modules are packages of WebLogic Portal-specific resources that are
ET
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.
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
B

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.
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

A
would probably want to display green images to the user.
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
ET
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.
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:
B

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 desktop is a particular view of a portal that visitors access. A portal can be made up of multiple

A
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.
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
ET
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
B

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

Portal Feature File-Based Portals Streamed Portals

Adding Run-time check only Yes—More easily set and configured

Entitlements

Setting Preferences In portal definition For individual portal instances

Number of Limited More than file-based portals
Instances No Yes

Customization No Yes (through Visitor Tools and the

Administration Console)

Internationalization Difficult—requires changes to Easier

Performance

Propagation (from
skeleton files.

Slight advantage

Easy to accomplish by moving the

A Slightly less than file-based portals

Requires proper planning but easy to

ET
test to production .portal file implement with Propagation feature.
environments)

Development Easiest More complex

Process

For performance-related recommendations, refer to “Use File-Based Portals for Simple

B

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 <link TBD>.

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.
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.

A
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.
ET
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 <TBD>.

Why are Page Flows Useful?

B

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

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

A
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.
ET
State Management
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.
B

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

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.

Powerful Exception Handling

A
You can handle exceptions by pointing to local actions in your page flows, Page Flows, and
ET
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.
B

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 [Link]
web site.

State/Session Management
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.

A
ET
B

3-12 BEA WebLogic Portal Portlet Development Guide

 CHAPTER 4

The Portal Framework

This chapter will be reorganized for GA

A
The portal framework is the portion of WebLogic Portal that is responsible for the rendering and
customization of the portal.
ET
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.
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 –
B

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

It is important that we first define a set of terminology, as these terms occur throughout the

Netui
A
document. Please take the time to become familiar with these concepts.

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

Netuix
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.
B

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.

Library
The library is a home for a set of public controls that are not associated with a desktop. In

A
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.
ET
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.

Portal Components
B

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 [Link] 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 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.

A
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.
You can configure a shell to use specific JSPs or HTML files to display content—especially
ET
personalized content—in a header or footer.
Each set of different header/footer combinations requires a new shell.

Book
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
B

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 <render:pageUrl/> 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
Provides a single row of tabs for the book’s immediate pages and child books.

Multi-Level Menu
A
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
ET
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.
A layout is an HTML table definition used by a page to determine the physical locations of
B

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

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.

A
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
ET
include other JSP files to distribute functionality, a portal file can include other portal files.
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.
B

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 [Link] 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.
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()
handlePostbackData()
raiseChangeEvents()
A
ET
preRender()
saveState()
render()
dispose()

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
B

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.
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
A
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
ET
and beyond entitlement checking and a place to go to discover other controls.
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.

Windows
B

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

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

A
ET
Book
B

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 <render:pageUrl/> tag, or from a backing file call the
setupPageChangeEvent method an a Book, Page or Portlet backing context before the preRender
method.

Layouts
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.
A
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
ET
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)
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
B

context, backing files, skeletons, and events. Use these components when altering the behavior
of or interaction with the portal framework.

Context
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.

The second way to obtain a backing context is from another context. This can be useful

A
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.
If portlet A is contained within the same page as Portlet B then you could use:
ET
PortletBackingContext portletB =
[Link](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
PortletBackingContext portletB =
B

[Link](request).PortletBackingCont
ext getPortletBackingContextRecursive(“Portlet Bs instance label”);

Refer to the javadoc on these and other backing context for more information.
[Link]
[Link]
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
[Link] interface or extend
the [Link]
abstract class (in retrospect it should have been called a backing class). The methods on the

cycle methods are invoked.

A
interface mimic the controls life cycle methods and are invoked at the same time the controls life

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

ET
Desktops

Books

Pages

Portlets

JspContent controls
B

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

Page Change

Generic Portlet Events.

A
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
ET
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.
Portlet Events (not to be confused with page flow events) allow portlets to communicate. One
B

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 =
[Link](request);
[Link] portletEventManager =
[Link](this, portletBackingContext);
[Link](portletEvent);

// Needed for the event to fire.

return true;
}

/**
* This is the implementation of the portlet that wants to receive the event.
*/

PortletEventListener
{
MyPayload result;
A
public class ResultBacking extends AbstractJspBacking implements
ET
public void init(HttpServletRequest request, HttpServletResponse response)
{
result = null;

// Register for Portlet Events

PortletBackingContext portletBackingContext =
[Link](request);
[Link](portletBackingContext, this);
B

[Link] portletEventManager =
[Link](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.
Other XML files within the Netuix structure include:

.book: the book file.

.page: the page file

.laf: the Look & Feel file

A
ET
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.

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
B

.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
All requests for a portal or desktop come in through the PortalServlet. The PortalServlet is
registered in the [Link] file under the url-patterns appmanager and *.portal. If the

A
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.
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
ET
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 [Link] Portal does not explicitly expose controls to developers, but
developers can interact with the controls using backing files, context, and skeleton JSPs.
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
B

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()
handlePostbackData()
raiseChangeEvents()
preRender()
saveState()
render()
A
ET
dispose()
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().
B

Figure 4-2 Control Tree Order

BEA WebLogic Portal Portal Development Guide 4-17

The Portal Frame work

A
ET
B

4-18 BEA WebLogic Portal Portal Development Guide

 CHAPTER 5

Setting up Your Portal Development

Environment

tutorials and will be expanded for GA.

A
Some content TBD - Some sections are copied from the Getting Started with WebLogic Portal

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,
ET
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.
For a step by step example of how to perform the tasks related to each wizard, see the Getting
B

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 sample portal domain comes with WebLogic Portal and is, by default, located at
WebLogic_HOME\samples\domains\portal.
A
You can start the Domain Configuration Wizard in several ways. Here are summaries of two
methods:
ET
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.

From the Start menu in Windows XP.

B

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

Figure 5-1 BEA WebLogic Server Configuration Wizard

A
ET

Table 5-1 shows the values that you would typically enter in the wizard, along with some useful
B

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.
For GroupSpace domains, WebLogic Server creates an
additional datasource that points to the GroupSpace instance of
the BEA Repository.

Configure Administrator Username

and Password A
(Default) user name: weblogic
User password: weblogic
Confirm user password: weblogic
ET
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

Customize Environment and Services No (the default)

B

Settings

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

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.

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

A
ET
B

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.

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

A
ET
B

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 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.
• Admin Framework
•
•
•
Admin Portal
A
P13N Application Libraries
Portal Application Services
ET
• Portal Customizations Framework
• Propagation Service

WebLogic Portal (Optional) This selection adds Commerce Services to the project.

WebLogic Portal Check this box (and its sub-features) to enable this project as a GroupSpace
GroupSpace EAR.
Selecting these check boxes restricts this EAR project to development as a
B

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-GroupSpace-
enabled 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.

Figure 5-4 Add and Remove Projects Dialog

A
ET
B

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.

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

A
ET
B

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

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

A
ET
B

3. Click Next.
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

Figure 5-6 New Portal Web Project Dialog

A
ET
B

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 - You can use the content area that WebLogic Portal creates by
Use default check box and default, or point to another directory where your project contents
file browser are stored.

Add project to an EAR If you have not yet created a Portal EAR Project, leave this check
check box and file browser 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.
If you have an existing EAR to associate with the project, select
the check box; the dropdown menu displays an auto-filled

A
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.
ET
A portal web project must be associated with an EAR for the build
to work successfully.

New Portal Web Project – Select Project Facets dialog

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

5-12 BEA WebLogic Portal Portal Development Guide

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

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

A
ET
B

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

WebLogic Portal
(Optional)

WebLogic Portal
A
This selection adds Commerce Tag Libraries to the project.

Check this box (and its sub-features) to enable this project as a GroupSpace
ET
GroupSpace Portal Project.
• Collaboration Portlets
• GroupSpace
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
B

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.

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

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

A
ET
Table 5-5 describes each field of the dialog.

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

Context Root
B

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

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

Table 5-6 describes each field of the dialog.

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

Use library modules and If you select the Use library modules radio button, WebLogic Portal
Copy JARs into the creates associations with library modules rather than copying the complete
WEB-INF/lib directory set of JAR files into your project. BEA recommends that you use library
radio buttons modules because of their significant advantages in source control, file
B

sharing, and patch application. For more information about library

modules, refer to “About Library Modules” on page 3-5.

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.

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

A
ET
B

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.

Figure 5-11 Create New Datasync Project Dialog

A
ET
B

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.

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

Create default project This check box is selected by default.

directories

Create default project files A

This check box is selected by default.
ET
Create New Datasync Project – EAR Projects
The Create New Datasync Project – EAR Projects dialog is shown in Figure 5-12.
B

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

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

A
ET
B

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

Figure 5-13 Datasync Project Added to the Package Explorer

A
ET
B

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.

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

A
ET
B

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.

Tip: You can customize the browser setting so that an external browser displays the

A
application; to do this, select Window > Preferences > General > Web Browser and
select the appropriate external browser application.

Open on Server - starts the server if it is not already started, and launches an internal
ET
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).
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
B

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.

Preferences in the WebLogic Portal Section

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

Figure 5-15 WebLogic Portal Product Preferences

ET
B

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:

Figure 5-16 Workshop for WebLogic Appearance Preferences

A
ET
3. Both the Colors and Fonts node and the Label Decorations node contain settings related to
WebLogic Portal:
B

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

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

A
ET
B

5-26 BEA WebLogic Portal Portal Development Guide

 CHAPTER 6

Upgrading WebLogic Portal Projects to

Version 9.2

A
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:
ET
Upgrading Applications from 8.1

Guidelines for Upgrading

Changes During the Upgrade Process

How to Use the Upgrade Wizard

These Workshop for WebLogic topics describe the changes that the import utility performs as it
B

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:

Optionally moving shared libraries from the version 8.1 application's Libraries folder to a

shared libraries in Version 9.2.

A
new EAR project in the upgraded application. An EAR project is the preferred location for

Converting Version 8.1 project types to Version 9.2 project types.

ET
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:
Workspace_root_dir\.metadata\[Link]
B

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.

3. In the Import dialog, under Select an import source, select Workshop 8.1 Application, then
click Next.
A
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.
ET
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.

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.
B

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.

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.

file. A
You can expand the node for each file to view the upgrade messages associated with that

The messages here are also available in the upgrade log file after the wizard finishes.
ET
13. After reviewing the messages, click Next.
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.
B

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): [Link]
and [Link]. Both were text files, and [Link] 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.
The configuration files are automatically converted to the new XML format.

A
ET
B

BEA WebLogic Portal Portal Development Guide 6-5

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

A
ET
B

6-6 BEA WebLogic Portal Portal Development Guide

 CHAPTER 7

Integrating Web Applications into

Portals

A
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.
ET
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.
Note: Beta release – descriptions for integrating Struts and other application types are
TBD.
B

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.

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

A
ET
B

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

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

A
ET
5. Click Finish.
The Project Facets table in the properties dialog displays the facets that you just added, as
shown in Figure 7-3.
B

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

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

6. Click OK.
A
ET
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.
Figure 7-4 shows an example of the new portal-related content that is added for the EAR
B

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 After
installing installing
Portal facets Portal facets

A
ET
B

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

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

A
ET
B

7-6 BEA WebLogic Portal Portal Development Guide

 CHAPTER 8

User Interface Development with Look

& Feel Features

A
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.
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
ET
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:

Portal Rendering and Look & Feel Introduction

B

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 ''[Link]'' 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.

Easier implementation of branding, allowing one Look & Feel to be used for multiple
brands.

Javascript files.
A
Convenient facility to support the generation of dynamic values in associated CSS files or

Global parameterization capabilities; for example, genes can be used to share a set of
ET
global properties to toggle the rendering of certain portal-wide features.

Provide a way to allow end users to toggle advanced features.

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.
B

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.

Gene Example
A
In a .chromosome file, you could define a gene called “bodyColor” and assign it a value of “red,”
like this:
ET
<gene name=”bodyColor”>
<value>#FF0000</value>
</gene>

In all of your CSS files, you can use the gene as a variable. For example:
body {
border:1px solid ${bodyColor}
B

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 [Link] 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 [Link] 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:

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 [Link] file (you must create this
file).
A
As a best practice, create a [Link] file in each Look & Feel, and create a
custom chromosome to override values in [Link] you want to override.
ET
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 [Link] or

[Link] files.

Any genes you want to use in the Look & Feel must be defined in the skin or skeleton
B

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 [Link], use <style> and <style content-uri> if you are using genes. Otherwise
use <link>.

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

TBD

A
ET
B

BEA WebLogic Portal Portal Development Guide 8-5

User Interface De velo pment with Look & Feel Features

A
ET
B

8-6 BEA WebLogic Portal Portal Development Guide

 CHAPTER 9

Developing Portals Using Workshop for

WebLogic

A
Most of this chapter is TBD. The current content of most included sections is copied from
the Getting Started with WebLogic Portal tutorials
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.
ET
This chapter includes the following sections:

Creating a Portal File

Portal Component Properties

Copying Library Module Files into a Project

B

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:
[Link]

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.

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

Figure 9-1 New Portal Dialog

A
ET
B

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.

Figure 9-2 Portal Displayed in Workbench

A
ET
B

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.
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

A
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.
ET
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.
To add a new portal page, perform these steps:
B

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: If you do not see the Palette tab, select Window > Show View > Palette.

9-4 BEA WebLogic Portal Portal Development Guide

 Portal Compo nent Properti es

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

A
ET
Portal Component Properties
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
B

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.
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.

A
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:

Figure 9-4 Portal Properties Example - Header Properties

ET
B

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.

Copying Library Module Files into a Project

A
You can override a resource in a library module by copying the resource into your portal web
project and then customizing it.
ET
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:

Select Window > Show View > Merged Projects View.
B

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.

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

A
name and path that exists in one of your library modules.
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.
ET
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.

c. Click Apply and then click OK.

B

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 [Link] 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.

2. Click Finish to begin the deployment process.

A
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.
The results appear in a new tab in the editor view, as shown in Figure 9-6.
ET
Tip: 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

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

TBD

Enabling Desktop Selection

TBD
A
ET
B

9-10 BEA WebLogic Portal Portal Development Guide

 C H A P T E R 10

Creating Portals for Multiple Device

Types

A
This chapter has not been updated from 8.1.x content
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.
ET
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.
When a device accesses a portal, the portal knows what kind of device it is and automatically
B

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

TBD

A
ET
B

10-2 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

A
ET
B

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: <PORTAL_APP>\data\request\[Link].
Portal developer tasks: None. This happens automatically.

A
ET
B

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\[Link] file. The default [Link] 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.
The following example of a client classification mapping in [Link] shows
explicit mappings (with the <useragent> tag) and a regular expression mapping (with the
<useragent-regex> tag).

A
<classification name="pocketpc" description="For the PocketPC">
<useragent value="Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; 240x320)"/>
<useragent value="Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240x320)"/>
ET
<useragent-regex value="(.*)PDA; Windows CE(.*)NetFront/3(.*)" priority="1"/>
</classification>
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.
B

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 [Link] 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.
Portal developer tasks: None. This happens automatically.

A
ET
B

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.
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.)
A
Move the classifications you want to enable/disable from the Available Classifications list to the
Selected Classifications list, and click OK.
The list of classifications is read from the [Link] file.
ET
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.
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
[Link] file (the value being stored in the “Client Classification” property in the
DefaultRequestPropertySet). See the Mobile Devices JSP Tags for more information.
B

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.
Portal developer tasks: None. This happens automatically.

A
ET
B

10-8 BEA WebLogic Portal Portal Development Guide

 C H A P T E R 11

Configuring Visitor Tools

A
This chapter has not been updated from 8.1.x content
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.
ET
This chapter includes the following sections:

Adding Visitor Tools to a New Portal Application

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.
B

Adding Visitor Tools to a New Portal Application

TBD

BEA WebLogic Portal Portal Development Guide 11-1

Configuring Vis ito r Tool s

A
ET
B

11-2 BEA WebLogic Portal Portal Development Guide

 C H A P T E R 12

Designing Portals for Optimal

Performance

A
This chapter has not been updated from 8.1.x content
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
ET
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.
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
B

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.

Figure 12-1 Simple Portal Schematic Example

A
ET
B

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).

Figure 12-2 Control Tree with Life Cycle Methods

A
ET
B

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

When you split a complex portal into multiple desktops, you spread the controls among those

A
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
ET
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.
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
B

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

Figure 12-3 Simple Portal Split into Multiple Desktops

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

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

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

A
ET
...while all other controls are ignored.

Design Decisions for Using Multiple Desktops

As these examples demonstrate, splitting a complex portal into multiple desktops can be very
B

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.

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.

A
For more information on creating desktops, please refer to “Creating a Portal and Desktop” on
page 13-7.
ET
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.
Note: Asynchronous portlet rendering can be used with control tree optimization. For more
information about asynchronous portlet rendering, refer to the Portlet Development
B

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:
<netuix:desktop definitionLabel="defaultDesktopLabel"
markupName="desktop" treeOptimizationEnabled="true"
markupType="Desktop" title="SimplePortal"><netuix:lookAndFeel

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">
<netuix:desktop/>

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.

Figure 12-5 Enabling Tree Optimization in Workshop for WebLogic

A
ET
B

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 [Link] (in
<PORTAL_HOME>/webAppName/WEB-INF) must have {url:currentPage} set in the
<url-template> 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 [Link].

Listing 12-2 [Link] URL Templates Component

<!-- URL templates -->

<url-template name="default"> A
{url:scheme}://{url:domain}:{url:port}/{url:path}?{url:queryString}
ET
{url:currentPage}
</url-template>
<url-template name="proxyurl">
{url:scheme}://{url:domain}:{url:port}/{url:prefix}/{url:path}?
{url:queryString}{url:currentPage}
</url-template>
<url-template name="finurl">
B

[Link]
{url:currentPage}&amp;dept=finance
</url-template>
<url-template name="default-complete">
{url:scheme}://{url:domain}:{url:port}/{url:prefix}/{url:path}?
{url:queryString}{url:currentPage}
</url-template>
<url-template name="jpf-default">
[Link]
{url:currentPage}
</url-template>
<url-template name="jpf-action">
[Link]

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}
</url-template>

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
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.

A
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.
ET
Figure 12-7 How Tree Optimization Reduces Control Tree Size

With ...while all other controls are

treeOptimizationEnable=true, ignored.
only the controls that are active in the
session will be rendered...
B

12-10 BEA WebLogic Portal Portal Development Guide

 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:

The backing file life cycle methods init() and handlePostBackData(), which are called

A
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.

If your portal uses backing files on any of their controls, some backing context APIs are
ET
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
– public BookBackingContext getBookBackingContextRecursive(String
definitionLabel)
B

– 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.

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

A
exist in the instance and the page change will not occur.
You can work around this problem by doing one of the following (this is the preferred
order):
ET
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.

d. Set _nfto=”false” in the invoking link. This causes the full control tree to be created
for that single request.
B

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

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.

A
To disable tree optimization, do one of the following:

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

Include nfto=”false” in the request parameter of just that instance for which you want to
ET
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 = [Link](request, response);
[Link](GenericURL.TRE_OPTIMIZATION_PARAM, "false");
B

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.
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

A
dynamically assigned to the user when they log into the site.

How Entitlements Affect Performance

ET
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.
By default, entitlements are stored in the database as opposed to LDAP. Nonetheless, always be
B

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
<control-resource-cache-size=nn> 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

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.

A
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
ET
many users customized that page, propagating the change might take a long time because of the
required database processing.

Optimize Page Flow Session Footprint

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
B

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.

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

A
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.
To set the request attribute persistence attribute for a page flow portlet, open the Request
ET
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.

Figure 12-8 Selecting Request Attribute Persistence Attribute

B

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.

Propagation to other environments is easy.

Limitations to Using File-based Portals

A
They are easy to create in WebLogic Workshop.

While file-based portals might show some performance improvement over streaming portals,
ET
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

Visitor Tools
B

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
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 [Link] 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"/>
<ExecuteQueue Name="portalRenderQueue" ThreadCount="5"/>
A
ET
Optimize Portlet Performance
You can optimize the performance of the portlets in your portal in several ways, including the
following:

Editing performance-related portlet properties to optimize performance

B

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

Part III Staging

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

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

Creating Portal Desktops

A
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.
You perform the tasks described in this chapter to prepare your portal application for public
ET
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.
B

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

<TBD>

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.

User, Groups, & Roles – User and group management, security provider configuration,
Delegated Administration, and Visitor Entitlements.

tasks in this category. A

The User Management Guide and Security Guide provides detailed information about the

Configuration Settings – Server settings for Cache Management, Server Maintenance

ET
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.

Interaction Management – Campaigns, Placeholders, User Segments, And Content

Selectors.
B

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.
Plan your implementation to make the best use of this WebLogic Portal functionality. Refer to

resources in the Administration Console. A

the Production Operations Guide for more details about disassembling and decoupling of

Starting and Logging In to the Administration Console

ET
Opening the Administration Console
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.
B

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 [Link] 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.

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

A
The Administration Console window opens in a new tab in the workbench editor view,
with the login dialog displayed, as Figure 13-2 shows.
ET
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.

Figure 13-2 WebLogic Portal Administration Console Login Dialog

B

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
User Name Password Description

portaladmin portaladmin Administrator for the portal domain

weblogic weblogic

A
WebLogic Server system administrator with full
privileges in the domain

To log in to the WebLogic Portal Administration Console, follow these steps:

ET
1. Type the appropriate user name and password into the dialog and click Sign In.
The main menu of the Administration Console displays.

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

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

Figure 13-3 Administration Console Main Page, Maximized

A
ET
Portals and Desktops
B

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 [Link] 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:

1. Click the Portal Management menu shortcut on the Administration Console home page.

of the page, as shown in Figure 13-5. A

The Portal Management page displays; the Portal Resources tree displays in the left pane

Figure 13-5 Portal Resources Tree in the Administration Console

ET
B

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.

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

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

Table 13-2 Create a New Portal Dialog Field Descriptions

A
ET
Field Value/Description

Portal Name Required. Name of the portal you want to add.

Description Optional description of the portal.

Partial URL
B

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

Figure 13-7 Create Desktop Wizard in Administration Console

A
ET
B

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 1. Select the appropriate radio button based on the object you want to
want to create a desktop... 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

Desktop template 1. For You can search for an Show All.

list.
2. Click to select.
3. Click Next.
A
The portal you created using Workshop for WebLogic displays in the
ET
Select Resources in the 1. For You can search for an Show All.
Library The portal you created using Workshop for WebLogic displays in the
list.
2. Click to select [Link].
3. Click Next.

Select a portal file 1. For You can search for an Show All.
B

The portal you created using Workshop for WebLogic displays in the
list.
2. Click to select [Link].
3. Click Next.

Step 3: Enter desktop • Title –

properties... • 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.

Figure 13-8 New Desktop in Portal Resources Tree

A
ET
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

When you create a desktop using a template (.portal file) in WebLogic Administration Portal,
B

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
Option Description

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

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

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

A
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
ET
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

In this task, you will create a new page for your desktop. Follow these steps:
B

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

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

Figure 13-10 Browse Pages Tab

A
ET
B

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

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

Table 13-5 Create New Page – Field Descriptions

Field

Title
Value/Description

Tutorial Page
A
ET
Description new page for tutorial

Layout Three Column Layout

Theme (leave as is - None)

B

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

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

A
ET
B

BEA WebLogic Portal Portal Development Guide 13-15

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

A
ET
B

13-16 BEA WebLogic Portal Portal Development Guide

 C H A P T E R 14

Deploying Portals to Production

This chapter is TBD

A
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
ET
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.
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.
B

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

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

A
ET
B

14-2 BEA WebLogic Portal Portal Development Guide

Part IV Production

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

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

Creating and Managing Portals

This chapter is TBD.

A
ET
B

BEA WebLogic Portal Portal Development Guide 15-1

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

A
ET
B

15-2 BEA WebLogic Portal Portal Development Guide