Ts 671sp1 Custom v01 en

TeamSite ®
User Interface
Customization Guide
Release 6.7.1 Service Pack 1
© 1999-2007 Interwoven, Inc. All rights reserved.
No part of this publication (hardcopy or electronic form) may be reproduced or transmitted, in any form
or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior
written consent of Interwoven. Information in this manual is furnished under license by Interwoven, Inc.
and may only be used in accordance with the terms of the license agreement. If this software or
documentation directs you to copy materials, you must first have permission from the copyright owner
of the materials to avoid violating the law which could result in damages or other remedies.
Interwoven, ConfirmSite, ContentServices, ControlHub, DataDeploy, DeskSite, FileSite, iManage,

LiveSite, MediaBin, MetaCode, MetaTagger, OffSite, OpenDeploy, Primera, Scrittura, TeamPortal,
TeamSite, VisualAnnotate, WorkDocs, WorkPortal, WorkRoute, WorkSite, WorkTeam, the respective
taglines, logos and service marks are trademarks of Interwoven, Inc., which may be registered in certain
jurisdictions. All other trademarks are owned by their respective owners. Some or all of the information
contained herein may be protected by patent numbers: US # 6,505,212, GBRI # 1053523, US #
6,480,944, US# 5,845,270, US #5,430,812, US #5,754,704, US #5,347,600, AUS #735365, AU
7830068, GB #GB2333619, US #5,845,067, US #6,675,299, US #5,835,037, AUS #632333, CAN
#2,062,965, FRAN / GRBI / SPAI / SWED #480941, GERM #69020564.3, KORS 10-0576487, JAPA
#2968582, MX #219522, NZ #516340, SING #109524, SG #89006, SG #89086, SG #74973, SG
#85502 US #5,065,447, US #6,609,184, US #6,141,017, US #5,990,950, US #5,821,999, US
#5,805,217, US #5,838,832, US #5,867,221, US #5,923,376, US #6,434,273, US #5,867,603, US
#4,941,193, US #5,822,721, US #5,923,785, US #5,982,938, US #5,790,131, US #5,721,543, US
#5,982,441, US #5,857,036, US #6,697,532, US #6,792, 454, US #6,928,149, US #7,092,969 or other
patents pending application for Interwoven, Inc.
Interwoven, Inc.
160 East Tasman Drive
San Jose, CA 95134
http://www.interwoven.com
TeamSite User Interface Customization Guide

Part 01-016-01-EN
August 2007
Table of Contents
About This Book 11
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Chapter 1: Customization Overview 15
What UI Features can be Customized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
UITK Toolkit Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
How Customizations are Preserved across Releases . . . . . . . . . . . . . . . . . . . . . . . . .19
How Customizations are Specified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Changes to HTML Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Changes to XML Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Changes to Online Help Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Before Making Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
How to Make Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Some Practical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Recommended Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Chapter 2: Toolkit Organization 25
Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Deployed Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Customer Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Directory Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Reference Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Style Sheet Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Reference Style Sheet Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Online Help Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Reference Online Help Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Online Help Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Custom Code Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Customer Samples Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Using the Sample Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Building the Customer Samples Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Removing the Customer Samples Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Chapter 3: Building the Web Application 33
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Disabling Browser Caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Faster Web Application Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Validating XML Customizations during the Build Process . . . . . . . . . . . . . . . . . . . .36
Troubleshooting Web Application Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Deploying Customizations to other Application Servers. . . . . . . . . . . . . . . . . . . . . .38
Customization Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
TeamSite User Interface Customization Guide 3

Contents
Chapter 4: Customizing GUI Behavior 41

Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Customization Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Configuration IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Order Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
ContentCenter Standard Portlet Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
ContentCenter Professional Tab Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
ContentCenter List and Attribute Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
ContentCenter Advanced Search Screen Fields, Languages, and Dropdown Labels
47
ContentCenter Link, Action List, Menu, Separator, and Heading Elements . . . .50
ContentCenter Map and Entry Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
ContentCenter Applications, Application, and Parameter Elements . . . . . . . . . .52
Other Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Element Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Inserting Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Moving Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Removing Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Common Attribute Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Reference ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
ResourceBundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
XML Reference File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Working with Columns and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Enabling ContentCenter Professional’s New File Templates Feature . . . . . . . . . . . .63
Customizing ContentCenter Application Behavior . . . . . . . . . . . . . . . . . . . . . . . . . .64
Configuring ContentCenter Maximum Saved Searches . . . . . . . . . . . . . . . . . . . .65
Configuring ContentCenter Data Record Search . . . . . . . . . . . . . . . . . . . . . . . . .65
Enabling Prompting after Modifying Forms (use tt-data) in ContentCenter
Professional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Configuring ContentCenter Saving of Incomplete Forms . . . . . . . . . . . . . . . . . .66
Configuring ContentCenter Data Record Form Rendering . . . . . . . . . . . . . . . . .67
Configuring ContentCenter Locking Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . .68
Configuring ContentCenter Extended Attribute Behavior upon Import . . . . . . . .70
Configuring ContentCenter Authentication Cookie Expiration . . . . . . . . . . . . . .71
Configuring ContentCenter SSO Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Configuring the ContentCenter Tagging Interface . . . . . . . . . . . . . . . . . . . . . . . .71
Eliminating the Tagging Step from ContentCenter Standard Wizards . . . . . . . . .72
Controlling File Tagging in ContentCenter Standard Wizards . . . . . . . . . . . . . . .72
Eliminating the Submit Wizard Step after ContentCenter Standard file operations .
73
Configuring ContentCenter Standard Workarea Names . . . . . . . . . . . . . . . . . . . .74
Enabling ContentCenter Standard “Edit My Workareas” feature . . . . . . . . . . . . .74
Enabling Directory Browsing instead of Editing Directories with VisualPreview . .
75
Extending ContentCenter’s Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Interwoven, Inc. 4
Contents
Chapter 5: Customizing GUI Appearance 77

Style Sheet Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Using Custom Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Style Sheet Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Custom Styles within Custom Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Examining ContentCenter Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Co-branding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Per Form Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Chapter 6: Customizing Online Help 83
Types of Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Underlying Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Customization Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Online Help File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Help Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Customizing Online Help Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Making Simple Changes to Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Making Complex Changes to Online Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Customizing Wizard Help Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Chapter 7: Extending GUI Functionality 91
Custom Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Adding ContentCenter Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Link URL Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Accessing Static Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Accessing Web Pages outside ContentCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Accessing CGIs from ContentCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Accessing Custom Java Code from ContentCenter . . . . . . . . . . . . . . . . . . . . . . .94
Restricting Custom Links by TeamSite Role . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Adding Custom Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Restricting Custom Tabs by TeamSite Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Adding Custom Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Chapter 8: Adding Custom Java Code 99
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Custom Code Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Third Party Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Editing the Deployment Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Invoking Custom Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Code Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Servlets or JSPs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Including CSS files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Accessing ContentServices SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
HTML Links within ContentCenter Custom Code. . . . . . . . . . . . . . . . . . . . . . .104
Accessing ContentCenter Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Logging Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Chapter 9: Using URL Commands 109
URL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Using URL Commands within TeamSite Workflow . . . . . . . . . . . . . . . . . . . . . . . .110

Contents
Other Uses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

URL Command Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Additional Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Specifying VPaths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Role Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
General URL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
File URL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Workflow URL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Legacy URL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Display Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
After URL Commands Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Browser Behavior and Workflow URL Commands . . . . . . . . . . . . . . . . . . . . . .126
Workflow CGI Tasks and Done Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Transitioning Workflow CGI Tasks and Done Pages . . . . . . . . . . . . . . . . . .127
Cancelling Workflow CGI Tasks and Done Pages . . . . . . . . . . . . . . . . . . . .127
Displaying a Workflow Feedback Page from a CGI Task. . . . . . . . . . . . . . .128
Customizing the UrlExternalTask Command to Send Email . . . . . . . . . . . . . . .129
Appendix A: Recommended Best Practices 131
Appendix B: Migrating Existing Customizations 133
Migrating to TeamSite 6.7.1 Service Pack 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Migrating to TeamSite 6.7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Advanced Search Screen Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Migrating Role Restrictions on Custom Menu Items and Custom Tabs . . . . . . .134
Migrating other New Customization Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Migrating 6.0 or 6.0L Customizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Upgrading to 6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Other 6.0 Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
New Reference File Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Property File Specification Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Changed Column Name in Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Enabling Directory Browsing instead of Editing Directories with VisualPre-
view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Disabling Editor Publish Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Changed Invocation of Legacy WebDeskPro CGIs. . . . . . . . . . . . . . . . . . . .138
WebDeskPro Customizations Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Previous Customization Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
TeamSite Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Edition Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
File History Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
User Profiles/Set Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Disabling Editor Publish Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Enable/Disable VisualPreview (Smart Context Editing, SCE) . . . . . . . . . . . . . .140
URL Commands (Casual Contributor Interface) . . . . . . . . . . . . . . . . . . . . . . . .140
Setting the Local File Manager (LaunchPad) Interface . . . . . . . . . . . . . . . . . . .140
Setting Unique Server Names for the Local File Manager (LaunchPad) to
Recognize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Setting Login Authentication Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Configuring Preview Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Custom Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Interwoven, Inc. 6
Contents
Configuring Submit Button Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

Disabling Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
Disabling Directory Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
Disabling Unlocked File Auto-Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
Setting the Number of Jobs Listed in the To Do List . . . . . . . . . . . . . . . . . . . . .144
Configuring Job Attribute Filters and Settings . . . . . . . . . . . . . . . . . . . . . . . . . .144
Configuring Email Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
Other Customization’s Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
DataDeploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
FormsPublisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
Metadata Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Metadata Capture/Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
WebDesk Favorites and Recents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Workflow CGI Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Workflows with Custom Date Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Workflow Instantiation within ContentCenter Standard. . . . . . . . . . . . . . . . . . .146
Appendix C: README files 147
README_base config_types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
README_teamsite_config_types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
README_search_config_types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
README_debug_custom_codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Glossary 161
Index 165

Contents
Interwoven, Inc. 8
List of Figures
Figure 1 ContentCenter Standard before Customization . . . . . . . . . . . . . . . . . . . . .15
Figure 2 ContentCenter Standard after Customization . . . . . . . . . . . . . . . . . . . . . . .16
Figure 3 ContentCenter Professional before Customization. . . . . . . . . . . . . . . . . . .17
Figure 4 ContentCenter Professional after Customization . . . . . . . . . . . . . . . . . . . .17
Figure 5 Customization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Figure 6 Customer and Reference Toolkit Directory Structure . . . . . . . . . . . . . . . .30
Figure 7 Customization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Figure 8 TeamSite Online Help System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Figure 9 TeamSite Wizard Help Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Figure 10 TeamSite Customized Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

List of Figures
Interwoven, Inc. 10
About This Book
The TeamSite User Interface Customization Guide describes how to customize the
ContentCenter Standard and ContentCenter Professional user interfaces in Interwoven
6, allowing you to customize—without programming—their look and feel, display
behavior, and online help content; to extend their capabilities by invoking custom Java
code from custom menu items, tabs, and home page components; and to access portions
of ContentCenter functionality via URL commands embedded within email messages,
web pages, or custom JSPs.
These user interfaces, as well as the FormsPublisher user interface, are built upon
Interwoven’s User Interface Toolkit (UITK) technology, part of the ContentServices
series of developer tools and interfaces. Other products shipped with Interwoven 6,
such TeamSite Front Office, do not currently use this technology.
The older TeamSite WebDesk Pro user interface is no longer supported. This guide
contains a migration appendix to assist those customers who have existing WebDesk Pro
customizations who wish to migrate them to the new Interwoven ContentCenter
products.
In the future, Interwoven intends to expose the underlying UITK technology as a set of
Java interfaces and libraries. Currently, such programmatic use of the UITK is not
supported. Any UITK calls visible in the JSPs that are part of the ContentCenter
products are for internal Interwoven use only. Such calls are not supported and are
subject to change. This book is not intended to be the UITK developer’s guide.
Intended Audience
The target audience for this book varies depending on the types of customizations being
done. It includes Interwoven Administrators and IT developers. Broadly speaking,
customizers can be divided by tasks and skill sets as follows:
Designers: edit product look and feel, co-branding, and online help content.
Interwoven Integrators: as above, plus adding custom menu items and integrating
with workflow by embedding ContentCenter functionality within auto-generated
emails.
Java Developers: writing custom code accessed from within the ContentCenter web
application from custom menu items, tabs, or custom home page components.
All customizers should understand HTML, CSS (HTML cascading style sheets), some XML,
and JavaScript. Interwoven integrators should also understand TeamSite Workflow.
Java developers should be generally familiar with how J2EE web applications are built.

About This Book
Organization
To support this range of skill sets, this manual presents its topics in order of increasing
complexity:
Chapter 1, “Customization Overview.” Briefly describes what ContentCenter GUI
features can be customized, how customizations are specified and made, and how
they are preserved across new Interwoven releases.
Chapter 2, “Toolkit Organization.” Outlines the organization of the customer toolkit,
in which customizations are made and preserved.
Chapter 3, “Building the Web Application.” Details how to speed up and extend
rebuilding the ContentCenter web application after specifying customizations.
Chapter 4, “Customizing GUI Behavior.” Details how to customize the behavior and
layout of the GUIs by customizing XML configuration files.
Chapter 5, “Customizing GUI Appearance.” Details how to customize the
appearance of the GUIs by extending or customizing their cascading style sheets.
Chapter 6, “Customizing Online Help.” Describes how to customize the online help
associated with the GUIs.
Chapter 7, “Extending GUI Functionality.” Describes how to extend the functionality
of the GUIs by adding custom menu items, tabs, and home page components
(portlets).
Chapter 8, “Adding Custom Java Code.” Describes how to extend the functionality
of the GUIs by adding custom Java code to the ContentCenter web application,
accessed through custom menu items, tabs, or home page components (portlets).
Chapter 9, “Using URL Commands.” Discusses how portions of ContentCenter
functionality can be accessed by URL command links embedded within
automatically generated e-mails, web pages, and custom JSPs.
All customizers should read chapters 1 and 2.
Designers should also read chapter 3, 4, and 5.
Interwoven Integrators should also read chapters 6 and 8.
Java Developers should also read chapters 6, 7, and 8.
Interwoven, Inc. 12
About This Book
Notation Conventions
This manual uses the following notation conventions:
Table 1 Notation Conventions

Convention Definition and Usage
Bold Text that appears in a GUI element (such as a menu item, button, or element
of a dialog box) and command names are shown in bold. For example:
Click Edit File in the Button Bar.
Italic Terms are italicized the first time they are introduced.
Important information may be italicized for emphasis.
Book titles appear in italics.
Monospace Commands, command-line output, file names, field, method, type, and class
names, and program text are in monospace type. For example:
The iwextattr command-line tool allows you to set and look up extended
attributes on a file.
Monospaced Monospaced italics are used for command-line variables and generalized
italic field, method, and class names. For example:
iwckrole role user
This means that you must replace role and user with your values.
Monospaced bold Monospaced bold represents information you enter in response to system
prompts. The character that appears before a line of user input represents the
command prompt, and should not be typed. For example:
% iwextattr -s project=proj1
//IWSERVER/default/main/dev/WORKAREA/andre/products/index.html
Monospaced bold Monospaced bold italic text is used to indicate a variable in user input. For
italic example:
% iwextattr -s project=projectname workareavpath
means that you must insert the values of projectname and workareavpath
when you enter this command.
[] Square brackets surrounding a command-line argument mean that the
argument is optional.
| Vertical bars separating command-line arguments mean that only one of the
arguments can be used.
Path names are listed using “/” as the separator, for example:
iw-home/iwportal/portal.cfg. On Windows machines, substitute “\” as needed, such
as: iw-home\iwportal\portal.cfg.

About This Book
Interwoven, Inc. 14
Chapter 1
Customization Overview
The TeamSite User Interface Customization Guide describes how to customize the
ContentCenter Standard and ContentCenter Professional user interfaces.
This chapter presents an overview of the customization process, describing:

What UI features can be customized.
How customizations are preserved across releases.
How customizations are specified.
How to make customizations.
What UI Features can be Customized

Using Interwoven’s user interface toolkit technology, you can customize the look and
feel, display behavior, functionality, and content of the ContentCenter user interfaces.
For example, here is ContentCenter Standard’s initial home page:
Figure 1 ContentCenter Standard before Customization

Chapter 1: Customization Overview
And here it is after a number of customizations have been applied:
Figure 2 ContentCenter Standard after Customization
Co-branded Logo Custom

Menu Item
Custom UI
Component
(dynamic content)
New ColorScheme
Custom UI
Component
(web site)
Custom UI
Component
(static content)
Different UI Component Layout

(50% columns, instead of 30%/70%)
Interwoven, Inc. 16
Here is the ContentCenter Professional user interface as it is supplied by Interwoven:
Figure 3 ContentCenter Professional before Customization
Here it is after the customizations have been applied:
Figure 4 ContentCenter Professional after Customization
Co-branded Custom Tabs

Logo
New Column Custom

Column
Order
New Color
Scheme
Custom Attribute

Among the items that can be customized using Interwoven’s UITK technology are:
Look and Feel
Type styles (fonts, sizes, and colors)
Colors and images (background images and icons)
Co-branded logos
Display Behavior
Default page size for lists
Column presence in lists
Column order
Custom variables shown in detail areas
UI component (portlet) presence on the home page
UI component (portlet) sizing and placement order
Menu item order
Accessing Custom Functionality
Custom UI components (portlets) in ContentCenter Standard
Custom menu items
Custom tabs in ContentCenter Professional
Restricting access to custom items by TeamSite roles
Online Help
Online help content
Online help system indexing and navigation
ContentCenter Standard wizard help topics
ContentCenter Standard introductory How Do I component (portlet)
NOTE
Internally, ContentCenter Standard’s “components” (what you see on the screen) are
referred to as “portlets” within the UITK, as their framework behaves similarly to, but is
not, a portal framework (nor is it compliant with the JSR 168 standard).
UITK Toolkit Structure

Every web application supported by the UITK consists of a series of toolkits: a base
toolkit, plus one toolkit for each of its major subsystems. Each toolkit has configuration
files and, if appropriate, a help system.
Interwoven, Inc. 18
In addition to these toolkits, each web application has a special customer toolkit in
which the Interwoven toolkits’ configuration files, HTML styles, and online help can be
overwritten or extended. All customizations within this customer toolkit are applied
whenever the web application is rebuilt. This customer toolkit is not overwritten when a
new version of the web application is installed, ensuring that customizations are
preserved across releases.
In the current Interwoven release, there is only one UITK web application, the
ContentCenter web application.
Customizations can be undone by removing them from the customer toolkit and then
rebuilding the web application.
Customizations are processed in the customer toolkit before being merged with the
internal toolkits. In the customer toolkit, the customer_out directory contains the
output directories for custom Java code (JSPs and Servlets) and supporting
files—including their copies of the configuration and style sheet files—whose source is
placed in the customer_src directories.
A reference toolkit is supplied, containing the style sheets, exposed XML configurations,
and help files used by Interwoven internally, so that these can be examined and, where
appropriate, copied into the corresponding customer_src directories in the customer
toolkit to be extended or modified. Customizations should not be made in the reference
toolkit (and will have no effect if attempted, as the reference toolkit is not applied when
the web application is rebuilt).
An Interwoven-supplied customer samples toolkit (and customer_sample_src

directories) contains various sample customizations that can be copied into the customer
toolkit to demonstrate possible customizations. Alternatively, this toolkit as a whole can
be merged into the ContentCenter web application when it is rebuilt, to demonstrate all
the samples at once.
How Customizations are Preserved across

Releases
When a later release of Interwoven software is installed, the existing customer toolkit is
not changed (although files in the reference and customer samples toolkits may change).
Thus, all existing customizations are automatically preserved and applied when the
(new) web application is built.
NOTE
Some changes in a new release of the underlying Interwoven-supplied software may be
“masked” by customer customizations, such as an updated Interwoven-supplied online
help screen whose older version was customized. In these cases, the customer will need
to merge their customizations with Interwoven’s updates (contained within the updated
reference toolkit).

How Customizations are Specified

Customizations are specified by editing different files, depending on the feature being
customized. These files are of three types:
HTML cascading style sheets (.css files).
XML configuration files.
Online help files (primarily HTML files).
The exact mechanism by which a customization is applied when the web application is
rebuilt varies depending on the type of file it is specified in, as described in more detail
in the next sections. Essentially, though, when the web application is rebuilt:
Style sheets are applied in cascading order.
Corresponding XML configuration files are merged together.
Custom online help files replace the corresponding Interwoven-supplied files.
Changes to HTML Cascading Style Sheets

Most toolkits have an associated cascading style sheet (.css file). As the web
application displays each page in a browser, it includes whatever style sheets are
specified by that page. As each style sheet is included, it modifies and extends the
styles in all previously included style sheets. This process allows styles to be defined
either globally, within the base toolkit style sheet, or specifically for any given toolkit.
Some Interwoven internal toolkits have associated custom style sheets located within
the customer toolkit in the corresponding toolkit subdirectory. These initially contain
no entries. In the web application, these custom style sheets are each applied after the
corresponding Interwoven style sheet. Thus, any HTML style change made to a custom
style sheet will automatically take precedence over the same named style specified in its
corresponding internal style sheet.
By choosing which customer style sheet to make a style change in, the scope of a
customization can be controlled.
For example, by specifying different colors in the custom base toolkit style sheet and a
custom logo in the base/images directory, all ContentCenter interfaces will be affected.
Then, by specifying different font styles in the ContentCenter Standard custom style
sheet, only the fonts in that interface will change while fonts in the ContentCenter
Professional interface will remain unchanged.
This is useful because many styles can look nice in one interface but not in another
interface.
Interwoven, Inc. 20
Changes to XML Configuration Files

Interwoven internal toolkits have configuration files in which the characteristics of
logical display elements, such as a menu displayed by that toolkit, are described by XML
entries. These configuration files are identified by their prefixes, such as “portal_”.
When the web application is rebuilt, these configuration files are read in a specified
order and merged to build a master internal structure of all display elements. Within a
set of files with the same prefix, if several XML entries have the same configuration id,
the last entry read supersedes any earlier ones in this structure.
For each set of configuration files with a given prefix, the customer toolkit contains a
similarly named file in the customer_src/etc/conf/customer directory, such as
portal_custom.xml, which initially contains an empty element that serves as a
placeholder for customizations.
Because configuration files in the customer toolkit are read last when rebuilding the web
application, any entries in them automatically modify or, in the case of conflicts,
supersede the Interwoven-supplied entries.
For example, to redefine one aspect of how ContentCenter Standard lays out its UI
components on its home page—the widths of each column displayed on the home page
as a percentage of the home page’s total width—an entry with different column
percentages is placed in the file portal_custom.xml, replacing the initially empty
element pair <iwov-portal></iwov-portal> with:
<iwov-portal>
<portal-page id="iw.ccstd.home.portal-page">
<portlet-group id="iw.ccstd.home.column1.portal-group" width="50%">
</portlet-group>
</portlet-group>
</portal-page>
</iwov-portal>
After the web application is rebuilt, the UI components (portlets) displayed in

ContentCenter Standard’s hompage will be arranged in two equal sized columns.
In addition to redefining Interwoven-supplied entries, entries can be added to

configuration files to:
Describe new elements, such as custom menu items, or a custom tab within
ContentCenter Professional, or a custom portlet within ContentCenter Standard.
Define custom TeamSite Workflow attributes to display in Job and Task lists and
detail areas.
Delete existing menu items and portlets.
Reorder existing menu items in a menu or portlets on the ContentCenter Standard
home page.

Changes to Online Help Files

Some Interwoven toolkits have associated online help systems. These can be edited so
that their content better matches a customized interface, conforms to company
standards, or describes the behavior of new elements, such as custom menu items.
To do so, copy the relevant help file into the customer toolkit and edit it as needed.
When the web application is rebuilt, any help files in the customer toolkit will
automatically overwrite the corresponding Interwoven help files. Thus, any existing
links within the help system will now automatically take the user to the customized help
file.
If many new files are added to a help system, it may be useful to update its table of
contents and index files as well, as described in Chapter 6, “Customizing Online Help.”
Before Making Customizations

Recommended Best Practice
Back up the entire customer toolkit (customer_out and customer_src directories) by

copying them to a location outside of the content_center directory, so that the toolkit
can be restored to its original state if needed.
Before performing any customizations, consider performing the steps described in

“Faster Web Application Builds” on page 35 because rebuilding the ContentCenter web
application can be dramatically sped up for most customizations by turning off JSP
precompilation.
How to Make Customizations

To customize the ContentCenter web application:
1. Identify the feature being customized and the relevant file(s) to edit.
2. Edit the corresponding file(s) in the customer_src directories.
3. Generate the output files, placing them in the customer_out directory, and rebuild
the ContentCenter web application by:
a. changing to iw-home/local/config/lib/content_center/customer_src
b. and issuing iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl
NOTE
This script must be invoked from within the customer_src directory.
Interwoven, Inc. 22
4. Test the customization (if unexpected behavior results, remove the customization
from the customer_src directory and rebuild the ContentCenter web application).
The standard customization process is shown below.
Figure 5 Customization Process
customer_src make_toolkit customer_out make_toolkit

directories directories web application
(source files, including (ready to merge output
(expanded and deployed)
configuration and style files)
sheet files)
internal
toolkits
If necessary, the make_toolkit script automatically stops the servlet container before
rebuilding the web application and restarts it when it is done.
NOTE
If you are using a different application server than the Apache Tomcat supplied by
Interwoven, such as IBM WebSphere or BEA WebLogic, you will also have to perform
certain additional manual steps as discussed in “Deploying Customizations to other
Application Servers” on page 38.
Because this script stops and restarts services (Windows) or daemons (Unix), you must
be Administrator (Windows) or root (Unix) to execute it. You must also have write
permission in the customer_out directories in the customer toolkit.
Some Practical Considerations

Because rebuilding the web application can take several minutes, UI customizations in a
production environment should take place during scheduled server maintenance time.

Test UI customizations on a development server running TeamSite, such as the one
provided by Interwoven’s Developer Suite, before making them on the production
server.
Using development servers to prototype and test customizations before rolling them out
in a production environment may be required if UI developers are not generally granted
Administrator (Windows) or root (Unix) privileges on your production systems.

To rapidly prototype UI Customizations, an additional desktop server license (typically

used to develop and test TeamSite workflows), such as the one offered as a low cost
add-on to the Interwoven Developer Suite, can be quite useful.
Interwoven, Inc. 24
Chapter 2
Toolkit Organization
This chapter describes the User Interface Toolkit (UITK) technology and the format and
naming conventions used within it.
The UITK consists of a series of internal toolkits, plus a customer toolkit, reference
toolkit (though this is not part of the final package), and a sample toolkit. Their output,
when deployed and built, is packaged as a Java web application .WAR (web archive) file.
Web Application
The ContentCenter web application normally runs inside the Interwoven-supplied
Apache Tomcat application server. Manual steps are provided for customers who wish
to use either the IBM WebSphere or BEA WebLogic application servers instead of
Apache Tomcat.
Deployed Toolkits
Each ContentCenter toolkit corresponds to a ContentCenter user interface subsystem.
The base toolkit defines the fundamental functionality of the UITK. Each application
or subsystem with either online help or custom style sheets has a corresponding toolkit
that is visible within the customer_src toolkit:
ccstd for ContentCenter Standard.
ccpro for ContentCenter Professional.
formspub for FormsPublisher.
Once the web application is installed, these toolkits, along with other internal toolkits
corresponding to subsystems (such as VisualPreview) without online help or custom
style sheets, will appear in the deployed web application under
iw-home/httpd/webapps/content_center.
Do not modify any files in the merged and deployed web application in this location.
Any modifications made to these files are not only unsupported but will also be
overwritten the next time the web application is rebuilt.

Chapter 2: Toolkit Organization
Important!
Do not rely on any internal Interwoven information exposed in this merged and
deployed web application.
While internal files, being part of a deployed web application, are necessarily exposed
here and can therefore be examined by customers, the information in these files that is
not exposed externally through the customer toolkit is not supported nor guaranteed to
remain in its current form in future versions of the UITK. This especially pertains to all
internal Java calls and commands. Customers are strongly discouraged from relying on
or making use of any information visible in the merged and deployed ContentCenter
web application.
Customer Toolkit
The customer toolkit is where customizations are placed, to be merged into the rebuilt
web application. Initially, it is an empty framework. It consists of several directories
and “skeletal” files ready to be merged into the expanded ContentCenter web
application.
Directory Structure
The customer toolkit resides under iw-home/local/config/lib/content_center. It
consists of two top level directories:
customer_src, where customizations are specified and the source files for custom
Java code development, including custom configuration files, style sheets, and
online help files, are placed.
customer_out, where the processed and ready to merge custom configuration files,
style sheets, and modified online help files are automatically placed before
rebuilding the ContentCenter web application. Files in this directory should not be
modified.
Configuration Files
Custom XML configuration files placed in the customer_src/etc/conf/customer
directory must begin with the same prefixes as the internal configuration files that they
will each be merged with. There are seven custom configuration files:
application_custom.xml
file_template_custom.xml
portal_custom.xml
search_custom.xml
ui_custom.xml
Interwoven, Inc. 26
userops_custom.xml
workflow_custom.xml
NOTE
This is true for new TeamSite 6.7 installations; it is true for migrations of TeamSite 6.x
to TeamSite 6.7 only after the files in customer_src_new/etc/conf/customer have
either been merged with the files in customer_src/etc/conf/customer, as described in
Appendix B, “Migrating Existing Customizations.”
These files are initially empty, except for their two first lines (as in
portal_custom.xml):
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE iwov-portal
PUBLIC "-//Interwoven, Inc.//DTD Portal Customizations 1.0//EN"
"../../../../reference/etc/conf/portal_custom.dtd">
and an empty placeholder element (such as in portal_custom.xml)

<iwov-portal></iwov-portal>
into which customizations will be placed.
Do not remove any of these lines.
Reference Configuration Files
The reference toolkit, iw-home/local/config/lib/content_center/reference,

contains in /etc/conf a set of reference XML configuration files, each prefixed with
ref_.
These files list the externally exposed XML used within internal Interwoven configuration
files (the ones that the customer toolkit customizations are merged with) so that the XML
entries and ids used by Interwoven are available to be referenced or modified within
customizations.
Each reference file’s name includes the internal toolkit (teamsite, ccstd, ccpro, and so
on) it comes from and the type of customization entries it contains (application,
portal, workflow, or ui).
For example, ref_csstd_ui_filesys.xml lists elements of ContentCenter Standard

that involve the file system. To customize one of its elements, you would place a
corresponding modified entry in ui_custom.xml.
Also present in this directory is the file README_base_config_types which details the
XML structure used in most of the reference files (plus other README files for more
specialized customizations).
Also present are DTDs corresponding to the XML custom configuration files. As the
custom configuration files contain only the externally exposed portions of the final

merged XML files that result from rebuilding the web application, they cannot be
validated against the final internal merged file schema. The DTDs supplied apply only
to the custom configuration files and are closely, though not absolutely, accurate (erring
on the side of strictness). They are provided so that customer customizations can be
validated before attempting to rebuild the ContentCenter application, as described in
“Customization Format” on page 42.
Style Sheet Files

In each exposed toolkit folder (base, ccstd, ccpro, formspub) in the customer_src/web
directory is a styles directory containing an empty custom.css style sheet used to
customize Interwoven-supplied styles or to add new custom styles.
Reference Style Sheet Files
The Interwoven internal styles that are exposed to be modified, replaced, or extended by
customers are in style sheets within the reference toolkit, one for each internal toolkit
with the name /toolkit/styles/iw.css (such as /base/styles/iw.css).
These reference style sheets contain all the Interwoven defined style names and
definitions for that toolkit. The base.css style sheet include styles used by all
applications.
During customization, only the styles being customized—and only the portions of a
style being customized—are copied from the reference toolkit into the appropriate
custom.css style sheet and then edited, as discussed further in Chapter 5, “Customizing
GUI Appearance.”
Online Help Files

Under each toolkit in the customer_src directory is a /web/toolkit/help/locale
directory in which customized versions of online help files are placed.
For example, customized versions of the English help files for ContentCenter
Professional would be placed in customer_src/web/ccpro/help/en.
Reference Online Help Directories
In the reference toolkit there is a /toolkit/help/locale directory for each toolkit with
a help system, such as /ccstd/help/en for the ContentCenter Standard English help
system, that contains reference copies of the Interwoven-supplied help files.
When customizing online help pages, copy the online help files you are modifying from
the relevant reference toolkit directory to the corresponding
/web/toolkit/help/locale directory in customer_src and then edit them as needed.
Interwoven, Inc. 28
Do not copy any files you will not be modifying, as discussed further in Chapter 6,
“Customizing Online Help.”
Online Help Style Sheets
The ContentCenter online help system has its own style sheets in order to have a look
and feel distinct from the actual ContentCenter GUIs.
In each customer_src/web/toolkit/help/locale directory, there is an initially empty

style sheet, custom.css, in which help style sheet customizations are made.
Within reference/base/help/base/en is iw.css (and a reference file ref_iw.css in

the directory above this) which contains all the Interwoven defined style names and
definitions for the online help system.
Custom Code Directories

The customer_src toolkit is also where code and supporting files are placed for custom
Java servlets and JSPs to be deployed within the ContentCenter web application.
Its structure is that of a source tree for a Java J2EE application, with etc, lib, src, and
web directories, as discussed in Chapter 8, “Adding Custom Java Code.”
The XML configuration files and custom style sheets located here are also part of a
custom Java program’s supporting files.
Summary
The following diagram illustrates the customer and reference toolkit structure.

Figure 6 Customer and Reference Toolkit Directory Structure
Customer Samples Toolkit

The directory iw-home/local/config/lib/content_center also contains the customer
samples toolkit customer_samples_src, containing sample custom Java servlets, JSPs
and supporting files as well as sample customizations.
Using the Sample Customizations

By examining the various custom configuration files and style sheets present in the
customer_samples_src toolkit, you can see how the sample customizations were
specified.
Interwoven, Inc. 30
By copying entries from the customer_sample_src toolkit to the corresponding files in

the customer_src directories and then rebuilding the web application, you can make
individual customizations.
To remove them, remove their entries from the customer toolkit and then rebuild the
web application.
Building the Customer Samples Toolkit
Alternatively, you can apply all the sample changes at once by appending the sample
toolkit to the end of the toolkit list in:
iw-home/local/config/lib/content_center/toolkits.xml
This file contains:

<<?xml version="1.0"?>
<toolkits>
<toolkit id="base" path="/usr/teamsite/private/lib/content_center/base.tk.war"/>
<toolkit id="teamsite" path="/usr/teamsite/private/lib/content_center/teamsite.tk.war"/>
<toolkit id="datacapture" path="/usr/teamsite/private/lib/content_center/datacapture.tk.war"/>
<toolkit id="vpreview" path="/usr/teamsite/private/lib/content_center/vpreview.tk.war"/>
<toolkit id="ccpro" path="/usr/teamsite/private/lib/content_center/ccpro.tk.war"/>
<toolkit id="formspub" path="/usr/teamsite/private/lib/content_center/formspub.tk.war"/>
<toolkit id="teamsite_admin"
path="/usr/teamsite/private/lib/content_center/teamsite_admin.tk.war"/>
<toolkit id="ccstd" path="/usr/teamsite/private/lib/content_center/ccstd.tk.war"/>
<toolkit id="workflowModeler"
path="/usr/teamsite/private/lib/content_center/workflowModeler.tk.war"/>
<toolkit id="ecmconnector"
path="/usr/teamsite/private/lib/content_center/ecmconnector.tk.war"/>
<toolkit id="transform" path="/usr/teamsite/private/lib/content_center/transform.tk.war"/>
<toolkit id="tagui" path="/usr/teamsite/private/lib/content_center/tagui.tk.war"/>
<toolkit id="search" path="/usr/teamsite/private/lib/content_center/search.tk.war"/>
<toolkit id="mtdialog" path="/usr/teamsite/private/lib/content_center/mtdialog.tk.war"/>
<toolkit id="vannotate" path="/usr/teamsite/private/lib/content_center/vannotate.tk.war"/>
<toolkit id="reporting" path="/usr/teamsite/private/lib/content_center/reporting.tk.war"/>
<toolkit id="metadata" path="/usr/teamsite/private/lib/content_center/metadata.tk.war"/>
<toolkit id="customer"
path="/usr/teamsite/local/config/lib/content_center/customer_out/customer.tk.war"/>
</toolkits>
Add the following element just before the closing element </toolkits>:
<toolkit id="customer_samples"
path="iw-home/local/config/lib/content_center/customer_samples_out/customer_samples.tk.war"/>
substituting for iw-home appropriately, and save this file. Change directory to:
iw-home/local/config/lib/content_center/customer_samples_src
and then rebuild the web application normally by issuing:

iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl
The resulting user interfaces should have all the sample customizations shown earlier.
NOTES
A customer_samples_out directory will automatically be created by this process.
Before doing this, consider performing, if you have not already done so, the steps
described in “Faster Web Application Builds” on page 35, because rebuilding the
ContentCenter web application can be dramatically sped up for most customizations
by turning off JSP precompilation.

Removing the Customer Samples Toolkit
To remove these customizations, comment out the customer_samples toolkit line from
toolkits.xml and then rebuild the web application (from customer_src) by issuing:
iw-home/iw-perl/bin/iwperl iw-home/install/install_webapps.ipl -i
-f content_center
NOTES
This is not the normal ContentCenter web application rebuild command.
Do not rename nor remove the file toolkits.xml. Renaming or removing the file
toolkits.xml and then rebuilding the web application will recreate this file with
entries for both the customer and customer_samples toolkits. If you accidently do
so, comment out the custom_samples entry.
Interwoven, Inc. 32
Chapter 3
Building the Web Application
This chapter details how to:

Disable the default caching within ContentCenter GUIs to easily view
customizations.
Speed up rebuilding the ContentCenter web application after specifying
customizations.
Validate custom XML configurations.
Troubleshoot this process.
Perform customizations when using other application servers.
Overview
As described earlier, the standard customization process is to:
5. Identify the feature being customized and the relevant file(s) to edit.
6. Edit the corresponding file(s) in the customer_src directories.
7. Generate the output files, placing them in the customer_out directory, and rebuild
the ContentCenter web application by:
c. changing to iw-home/local/config/lib/content_center/customer_src
d. and issuing iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl
The following diagram illustrates this process:
Figure 7 Customization Process
customer_src make_toolkit customer_out make_toolkit

directories directories web application
(source files, including (ready to merge output
(expanded and deployed)
configuration and style files)
sheet files)
internal
toolkits

Chapter 3: Building the Web Application
NOTE
While make_toolkit does its work in two phases, as illustrated by this diagram,
make_toolkit is invoked only once by the developer doing the customization.
Most customers will follow this process for the majority of their customizations.
Due to the default caching of static portions of the ContentCenter GUIs, customizations
may not be immediately visible after they are made. The section “Disabling Browser
Caching” describes how to turn off this caching, if desired on development machines.
The customization process can be dramatically speeded up in most cases by turning off
JSP precompilation and rebuilding the web application once before starting the normal
iterative customization process. This is especially useful on development machines, as
described in the section “Faster Web Application Builds”.
The make_toolkit script uses a version of Jakarta Ant installed with TeamSite to
perform XML validation of customizations as part of this build process, as described in
the section “Validating XML Customizations during the Build Process”.
The make_toolkit script, in its standard usage, attempts to compile only those portions
of the ContentCenter web application that it needs to, based on the new customizations
that have been specified since the web application was last built. Occasionally, this may
be inappropriate and other methods may be needed, as described in the section
“Troubleshooting Web Application Builds”.
The ContentCenter web application can run in other application servers, as described in
the TeamSite Installation Guide. The section “Deploying Customizations to other
Application Servers” details the manual steps needed to redeploy the ContentCenter web
application after making customizations.
NOTE
The make_toolkit script is the standard way to apply a GUI customization. The
make_toolkit script uses an underlying installation and deployment script,
install_webapps. Occasionally, you may need to invoke the underlying
install_webapps script directly, as detailed in the appropriate sections.
Disabling Browser Caching

The ContentCenter web application, by default, caches the static portions of the
ContentCenter interfaces in order to improve performance.
However, this can result in developers customizing the ContentCenter GUIs being
unable to view the changes they make. There are two options to deal with this. One
option is for developers to either disable browser caching entirely in their own browsers
Interwoven, Inc. 34
(whether they are viewing ContentCenter GUIs or not) or continuously delete their
browser cache.
The other option, particularly applicable to development systems where UITK

customizations are frequently performed, is to turn off this caching of ContentCenter
interfaces (in which case all browsers accessing this version of TeamSite will default to
their own specified caching behavior for the static portions of the ContentCenter user
interfaces).
To turn off the caching of ContentCenter GUIs, if this was not done as a post-installation
step after installing TeamSite (see the TeamSite Installation Guide), comment out the
following lines in iw-home/iw-webd/conf/httpd.conf.template and then issue
iwreset -ui:
<Location "/iw-cc">
ExpiresActive On
</Location>
<LocationMatch "^\/iw-cc\/.*\.(gif|jpe?g|png|js|css)$">
ExpiresDefault "access plus 2 hours"
</LocationMatch>
<Location "/iw-icons">
ExpiresActive On
</Location>
<LocationMatch "^\/iw-icons\/.*\.(gif|jpg)$">
ExpiresDefault "access plus 2 hours"
</LocationMatch>
Faster Web Application Builds

When the ContentCenter web application is first installed, all of its JSP pages are
precompiled as part of the installation process.
JSP precompilation will detect syntax errors in JSP pages and can greatly improve the
performance of the very first request for each JSP page, as well as all subsequent
requests on production systems with many concurrent users. Thus, JSP precompilation
is strongly recommended when building the ContentCenter web application on a
production machine.
However, JSP precompilation can be very time consuming. On a development machine,

particularly if you are making frequent, rapid customizations, it may be undesirable.
To switch JSP precompilation off when building the ContentCenter web application,
issue:
iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl -nojsp_precompile
from iw-home/local/config/lib/content_center/customer_src.

NOTE
If you are running the ContentCenter web application in other application servers than
Tomcat, JSP precompilation should have been manually turned off as a post installation
step after installing TeamSite, as described in the TeamSite Installation Guide.
Once JSP precompilation has been switched off, it will continue to be off in future
rebuilds of the ContentCenter web application until it is explicitly switched on.
To do this:
1. Stop the TeamSite server by issuing: iwreset -ui stop
2. Delete all folders and files under iw-home/servletd/work/
NOTE
Stopping TeamSite and removing the files underneath iw-home/servletd/work/will
prevent TomCat from possibly attempting to recompile outdated JSPs, instead of
serving up the newly precompiled JSPs.
3. Issue:
iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl -jsp_precompile
from iw-home/local/config/lib/content_center/customer_src.
NOTE
The TeamSite server will be automatically restarted as a result of the last command.
Once JSP precompilation has been switched on, it will continue to be on in future
rebuilds of the ContentCenter web application until it is explicitly switched off again.
NOTE
JSP precompilation for the ContentCenter web application can also be switched off and
on with -nojsp_precompile and -jsp_precompile flags when invoking the install
script iw-home/install/install_webapps.ipl. These two scripts, make_toolkit.ipl
and install_webapps.ipl will both, when invoked without one of these flags, respect
the current setting of JSP precompilation (on or off), regardless of which script last set
it.
Validating XML Customizations during the Build

Process
The make_toolkit script uses a version of Ant installed with TeamSite to perform
automatic XML validation of custom XML configuration files as part of the build process.
Interwoven, Inc. 36
If one or more of the custom configuration files does not contain well-formed XML,
then the ContentCenter web application will not be updated with the latest changes from
the customer toolkit. If any invalid XML, not conforming to the DTDs, is detected, a
warning will be issued but the ContentCenter web application will be updated with the
latest changes from the customer toolkit
Troubleshooting Web Application Builds

Normally, the make_toolkit script attempts to compile only those portions of the
ContentCenter web application that it needs to, based on the new customizations that
have been specified since the web application was last built.
Under certain circumstances, such as when a source file has been replaced by an older
version of the same file, the make_toolkit script may be unable to detect all the changes
that have been made.
Another example, which normally does not create any problems in practice, is that the
class file and web.xml entry for a deleted custom JSP are not deleted from the
ContentCenter web application when the custom JSP is deleted.
If it is ever needed to force the complete rebuilding of the ContentCenter web

application from the source files:
1. Change directory to iw-home/local/config/lib/content_center/customer_src.
2. Issue iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl -target
clobber.
This will remove the previously built version of the toolkit.

3. Issue iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl
If the ContentCenter web application should ever be left in a completely inconsistent

state (after first attempting to remove the customizations that caused problems and
rebuild the ContentCenter web application normally and then by attempting the
previously described steps), the ContentCenter web application can be reinstalled
completely by:
1. Stop the TeamSite server by issuing: iwreset -ui stop
2. Delete all folders and files under iw-home/servletd/work/
3. Issue (as a single command):
iw-home/iw-perl/bin/iwperl iw-home/install/install_webapps.ipl -i
-f content_center
NOTE
The TeamSite server will be automatically restarted as a result of the last command.

Deploying Customizations to other Application

Servers
The ContentCenter web application can run in other application servers, such as IBM
WebSphere and BEAWebLogic, as described in Appendix A of the TeamSite Installation
Guide.
NOTE
The steps described in this section assume that you have successfully performed the
configuration procedure described in Appendix A of the TeamSite Installation Guide.
However, if you are intending to do lots of customizations on a development machine,

consider turning JSP precompilation off after Step 1 of the configuration procedure
described in Appendix A of the TeamSite Installation Guide by issuing:
iw-home/iw-perl/bin/iwperl iw-home/bin/make_toolkit.ipl -nojsp_precompile
from the directory iw-home/local/config/lib/content_center/customer_src.
Customization Steps
To customize the ContentCenter web application when it is running on another
application server, you will need to perform the following manual steps each time you
make a customization:
1. Specify the desired customizations within the directory:
iw-home/local/config/lib/content_center/customer_src
2. Shut down the web application server (WebSphere or WebLogic).
3. In the directory iw-home/httpd/webapps/content_center/WEB-INF:
a. Copy the file web.xml to web_no_jsp.xml.
b. Copy the file web.xml.save to web.xml.
4. In iw-home/local/config/lib/content_center/customer_src, issue:
5. The make_toolkit script may attempt to restart the Apache Tomcat web application
server (servletd), so—under UNIX—shut down servletd:
UNIX: As root, determine the process ID of servletd and kill the process:
ps -aef | grep servletd
kill process_id
Under Windows, if servletd was disabled (as described in the TeamSite Installation
Guide) then this step can be omitted. Otherwise, from the Services control panel,
select the Interwoven Servlet Engine service and stop it.
6. In the directory iw-home/httpd/webapps/content_center/WEB-INF:
Interwoven, Inc. 38
a. Copy the file web.xml to web.xml.save.

b. Copy the file web_no_jsp.xml to web.xml.
7. Depending on the web application server, perform either:
IBM WebSphere
a. In iw-home/httpd/webapps/content_center, issue: jar cf ../iw-cc.war .
b. Copy iw-cc.war from iw-home/httpd/webapps to the WebSphere deployment
directory.
BEA WebLogic
a. Copy the iw-home/httpd/webapps/content_center directory to the WebLogic
deployment directory.
b. Rename this copied content_center directory to iw-cc.
8. Restart the web application server (WebSphere or WebLogic).
9. Test the customization (if unexpected behavior results, remove the customization
from the iw-home/local/config/lib/content_center/customer_src directory
and rebuild the ContentCenter web application by repeating steps 2-8).
Automate steps 3-7 of this process in a custom script (substituting the particular
locations of Interwoven files and the web application server deployment directory as
appropriate for your system).

Interwoven, Inc. 40
Chapter 4
Customizing GUI Behavior
This chapter describes how to customize the behavior and appearance of ContentCenter
GUIs by editing UITK XML configuration files.
Configuration Files
As described in the Chapter 2, “Toolkit Organization,” there are seven custom
configuration files located in the customer_src directory tree:
iw-home/local/config/lib/content_center/customer_src/etc/conf/customer
NOTE
This is true for new TeamSite 6.7 installations; it is true for migrations of TeamSite 6.x
to TeamSite 6.7 only after the files in customer_src_new/etc/conf/customer have
either been merged with the files in customer_src/etc/conf/customer, as described in
Appendix B, “Migrating Existing Customizations.”
When making customizations, place each custom configuration entry in one of these
files, depending on the type of customization:
If it has to do with the visual layout of UI components (portlets) on ContentCenter
Standard’s home page, edit portal_custom.xml.
If it has to do with the overall behavior of either or both of the ContentCenter GUIs,
edit application_custom.xml.
To enable and configure ContentCenter Professional’s file template feature, edit
file_template_custom.xml.
To configure the advanced search screen, edit search_custom.xml.

If it has to do with TeamSite Workflow (jobs or tasks), edit workflow_custom.xml.
If it has to do with granting access permission to custom menu items or custom tabs,
edit custom_userops.xml.
Otherwise, edit ui_custom.xml to customize general user interface elements, such
as menus, action lists, headings, display lists, columns, fields, tabs (in
ContentCenter Professional), the search results lists, and so on.
Possible customizations include:

Chapter 4: Customizing GUI Behavior
Adding custom elements, such as custom portlets, tabs, menu items or additional
separators, columns, and fields.
Configuring the search subsystem and advanced search screen as to how many
fields and what languages, content types, and extended attributes can be searched
on.
Specifying whether user invocation of custom menu items and ContentCenter
Professional custom tabs will be enforced by the TeamSite server.
Customizing attributes of Interwoven-supplied GUI elements, altering their widths,
labels, whether a portlet’s title bar is displayed, default sort behavior, what action is
invoked by a menu item, and so on.
Reordering Interwoven-supplied GUI elements, altering portlet placement and the
display order of existing columns, headings, menu items, and attributes.
Deleting certain Interwoven-supplied GUI elements, such as portlets, menu items,
columns, and fields.
Controlling the overall behavior of the ContentCenter GUIs, such as customizing
how workarea names are displayed in ContentCenter Standard, whether the final
tagging step occurs for wizards that create content, and whether the user is prompted
after modifying a form in ContentCenter Professional to associated it with a
workflow.
Customization Format
All UITK configuration files must begin with the following first line:
<?xml version="1.0" encoding="utf-8"?>
Their second line points to its XML data definition (DTD) file, used to validate XML placed
within it. For example, the file portal_custom.xml has the following second line:
<!DOCTYPE iwov-portal
PUBLIC "-//Interwoven, Inc.//DTD Portal Customizations 1.0//EN"
"../../../../reference/etc/conf/portal_custom.dtd">
The remaining lines consist of elements that follow typical XML syntax, with an element
start tag—possibly including a series of attribute-value pairs—and a matching end tag.
Each element, in turn, may contain one or more other elements.
For example, consider the following portal_custom.xml customization:

<iwov-portal>
</portlet-group>
</portlet-group>
</portal-page>
</iwov-portal>
Interwoven, Inc. 42
The iwov-portal element has no attributes and contains the portal-page element.
This element has one attribute, id, and contains two portlet-group elements, each
with two attributes: id and width.
The iwov-portal element is the placeholder element for this file. Each XML
configuration has only one outermost placeholder element.
Compare this customization with the (reformatted) reference file

ref_ccstd_portal.xml:
<iwov-portal>
<portlet id="iw.ccstd.home.how_do_i.portlet">
<title-bar id="titlebar"/>
</portlet>
<portlet id="iw.ccstd.home.content.portlet">
</portlet>
<portlet id="iw.ccstd.home.my_favorites.portlet">
</portlet>
</portlet-group>
<portlet id="iw.ccstd.home.tasks.portlet">
</portlet>
<portlet id="iw.ccstd.home.work_in_progress.portlet">
</portlet>
<portlet id="iw.ccstd.home.my_forms.portlet">
</portlet>
</portlet-group>
</portal-page>
</iwov-portal>
The customization does not include the reference file’s inner portlet elements, as they
are not being modified and will be automatically merged in when the web application is
rebuilt.
The customization does include the elements iwov-portal and portal-page, even
though they are not being modified, as they are contain the customized portlet-group
element.
When performing an XML configuration customization:

Include all containing elements that contain the element being customized.
Do not include any child elements, unless they are also being customized.
Do not include any attributes, except ids, unless they are being customized.

The possible elements, attributes, and containing relationships for XML configurations
are all described in README_base_config_types, except for the TeamSite Workflow
custom attribute element and file template feature enabling and configuration described
in README_teamsite_config_types and the Search elements described in
README_search_config_types. These files are located in the same directory as the XML
reference files and DTDs:
iw-home/local/config/lib/content_center/reference/etc/conf
For convenience, slightly reformatted copies of these files are provided in Appendix C,
“README files.”
Compare the reference file’s portlet elements with the README_base_config_types

file’s portlet element description and its example of a custom portlet element:
<portlet id="example.portlet"
label="Custom Portlet"
url="/customer/examplePortletServlet">
<title-bar id="example.titlebar" type="standard"/>
</portlet>
The label and url attributes are described primarily for adding custom portlets. They
do not appear in the ref_ccstd_portal.xml reference file as they are not exposed for
the Interwoven-supplied portlets for two different reasons:
The url attribute cannot be modified for the Interwoven-supplied portlets.
The label attribute’s value for an Interwoven-supplied portlet contains information
that is not publicly exposed (an internal property string id), although the label
attributes of Interwoven-supplied portlets can be customized.
Do not customize attributes for Interwoven-supplied elements if they are not listed in
the appropriate reference files, unless the attribute is documented elsewhere as
customizable.
In addition to these considerations:

Make sure that all id values are spelled correctly and match the capitalizations used
in the reference files.
Use a text editor with support for UTF-8 encoding, such as TextPad from Helios
Software, particularly if your entries contain multi-byte characters (in either label
or description attribute values).
XML customizations are automatically validated against the provided DTDs when the
ContentCenter web application is rebuilt, as described in “Deploying Customizations to
other Application Servers” on page 38.
Configuration IDs
All UITK elements have a unique id that identifies them.
Interwoven, Inc. 44
All ids within Interwoven internal elements are prefixed with “iw”, “iwov”, or “_iw”.
Do not use these prefixes in ids when creating new elements, such as those defining a
custom menu item or portlet.
Order Considerations
The order in which elements are listed is important. Elements in lists are processed in
the order they appear. (If two elements have the same ids, the last element encountered
takes precedence if there are any conflicting attribute values or containing
relationships.)
To move elements and insert custom elements, so that the order of Interwoven-supplied
elements and custom elements can be customized, use the operations described in the
section “Element Operations” on page 53.
Elements
This section relates the XML element names to visual elements displayed in
ContentCenter GUIs and describes their containing relationships.
Exact details on how to specify each element and its possible attributes can be found in
README_base_config_types (and the other READMEs) located in:
Copies of these files also appear in Appendix C, “README files.”
ContentCenter Standard Portlet Elements

portal-page, the initial ContentCenter Standard home page.
portlet, a GUI component displayed on the ContentCenter Standard home page.
title-bar, whether or not a portlet’s title should be rendered.
portlet-group, a series of portlets displayed as a column on the ContentCenter
Standard home page.
These elements have the following containing relationship:

<portal-page>
<portlet-group>
<portlet>
<title-bar>
</title-bar>
</portlet>
</portlet-group>
</portal-page>

Possible customizations include the width, as a percentage of the home page, that a
portlet group’s column occupies; whether a portlet’s title bar is rendered and, if so, its
textual label; as well as moving and deleting existing portlets and adding custom
portlets.
ContentCenter Professional Tab Elements

tabset, the various tab panes that users can switch between in ContentCenter
Professional. These reside below its main menu bar.
tab, an individual tab in a tabset.

<tabset>
<tab>
</tab>
</tabset>
Custom tabs can be added to the ContentCenter Professional tabset.

Interwoven-supplied tabs cannot be moved, inserted into, or deleted, though their labels
can be customized.
ContentCenter List and Attribute Elements

pagedlist, a variable length list of items, such as files, directories, tasks, jobs, and
so on which is displayed as a series of pages.
listview, a scrollable list of items.
column, a column to be displayed in a list.
These elements have either of the following containing relationships:

<pagedlist>
<column>
</column>
</pagedlist>
<listview>
<column>
</column>
</listview>
Both list types support designating a default column to sort on and a default sort
direction (these can be overridden by the end user working within the application).
The TeamSite Workflow related job and task paged lists, and the lists associated with
the file system (files, directories, branches, workareas, and so on), but not the the search
results list, can be customized for column display and order. All paged lists, including
the search results lists, can be customized for the default page size.
Interwoven, Inc. 46
A column’s label, icon, width, alignment, wrapping behavior, underlying property, and
display format can be customized. Existing columns can be moved or deleted.
Custom job and task list columns can be created, based on TeamSite Workflow job or
task properties or file properties, as exposed through ContentServices SDK objects:
CSWorkFlow for jobs, CSTasks for tasks, and CSSimpleFile for files. Custom columns
can be inserted before or after existing columns.
NOTE
Custom columns cannot be created based on stores, branches, or workareas.
Column widths must sum to 100% of page width. By default, the Name column is 30%
and the Actions column is 20%.
Displayed either in separate screens or, in the case of jobs and tasks in ContentCenter
Professional, in a section below a paged list are:
attributelist, a list of a job or task’s fields to display.
attribute, a field of a job or task to display in an area.

<attributelist>
<attribute>
</attribute>
</attributelist>
An attribute’s label, underlying property, and display format can be customized.

Attributes can be moved and deleted.
Custom attributes, similar to custom columns, can be created based on TeamSite

Workflow job or task properties in this release. Custom attributes can be inserted into
attribute lists.
NOTE
Any custom workflow attribute of type date is assumed by the UITK to be using Unix
timestamp format (as in the custom workflows supplied with TeamSite 6.0+).
ContentCenter Advanced Search Screen Fields, Languages,

and Dropdown Labels
The advanced search screen providing access to search subsystem can be customized in
the file search_custom.xml, as detailed in the file README_search_config_types in the
reference toolkit and in Appendix C, “README files.” This section describes the
customizations possible and element relationships.

NOTE
Search result lists are ContentCenter paged lists whose page size can be customized
within ui_custom.xml, not search_custom.xml.
The maximum number of specific search fields displayed in the Advanced Search
screen in the section “Content Type” can be customized.
Example
To have six fields to potentially search on in the Advanced Search screen, edit
search_custom.xml:
<custom-fields>
<property id="max-num-fields" value="6"/>
<custom-fields>
The languages which a user can select to search upon can also be customized in this file
if it is not desirable to list every supported language in the advanced search screen. To
remove a supported language, place it within an <iwov-delete> element.
Example
To remove German as a supported language to search on, edit search_custom.xml:

<languages id="iw.search.languages">
<iwov-delete>
<language id="de"/>
</iwov-delete>
</languages>
The drop down labels for the content types to be searched can be customized. Each
content type is a list of file extensions to search on, such as htm,html for HTML formatted
files, and a label to display. If no customizations are made, then only the two
predefined content types will appear: all, representing all content, and forms, TeamSite
FormsPublisher forms.

<content-types>
<content-type>
</content-type>
</content-types>
The labels displayed in the drop down menus for specifying which fields to search on,
for both extended attributes and form types, can be also be customized.
Interwoven, Inc. 48
NOTE
Using resource bundles to customize these labels will also allow them to be more easily
localized, as discussed in “Common Attribute Types” on page 55.
If no customizations are made, then all the standard types will be displayed. If any
customizations are made, then only the customized types will appear.
NOTE
If no customizations are made, then all types will appear in the drop down menu but the
names displayed will not necessarily be user friendly; they will the internal values for
that type. For instance, “TeamSite/Templating/DCR/Type” instead of, say, “Entry
Form” will be displayed.
If the content being searched on is not a form, then only extended attributes will appear
in field drop down menus. If the content being searched on includes forms, then the
drop down menus will display both the labels for extended attributes and forms.

<extended-attribute-list>
<extended-attribute>
</extended-attribute>
</extended-attribute-list>
and, for form types:

<template-types>
<template-type>
<template-field>
</template-field>
</template-type>
</template-types>
where an extended-attribute is the Interwoven extended attribute to display in the

drop down menu. Custom extended attributes can be added. These types will be
displayed if the corresponding extended attributes specified by the MetaData Capture
Form have been indexed for search. The label for an Interwoven extended-attribute
can be customized.
Similarly, a template-type is the Interwoven template type to display in the drop down
menu (such as intranet/weather). The labels for a template-type can be customized.
If a template-field is specified and indexed for search, then this TeamSite templating
field will be displayed in the “attributes” drop down of the Advanced Search screen for
that particular templating type. If a particular template-field within a templating type
is not indexed, then it will not be shown.
For more information, see the example at the end of README_search_config_types in

the reference toolkit and in Appendix C, “README files.”

ContentCenter Link, Action List, Menu, Separator, and

Heading Elements
A user clicks on a displayed action link to invoke some functionality. Several different
types of links are supported by the UITK.
link, an item associated with an HTML hyperlink.
action-list, a list of links.
menu, a list of links displayed as a popup menu.
separator, a visual horizontal bar displayed within a menu.
heading, a list of links, action lists, or menus displayed in a row at the top of a
screen area, such as the bar displaying Compare, Get Latest, Import, Edit,
Preview, and Submit for files in ContentCenter Professional.
globals, indicates that the element (a link, action-list, menu, or heading) can be
referred to globally, outside the context of a specific menu, heading, or action list.
Usually applied to links.
These elements can have various containing relationships, such as:

<action-list>
<link>
</link>
<menu>
<link>
</link>
...
<separator>
</separator>
<link>
</link>
</menu>
<menu>
...
</menu>
...
<link>
</link>
</action-list>
<heading>
<link>
</link>
<menu>
</menu>
<action-list>
</action-list>
</heading>
Interwoven, Inc. 50
<globals>
<link>
</link>
<globals>
Headings can contain a mixture of links, action lists, and menus. Action lists can
contain a mixture of links and menus. Menus cannot contain other menus as submenus,
only links and separators.
A link’s label, icon, reference, result URL, and target window behavior can be
customized. Existing links can be moved and deleted. Custom links can be created and
inserted into existing headings, action lists, and menus.
A link can contain one or more urlParam subelements, each specifying a parameter to
be added to the result URL.
<link>
<urlParam>
</urlParam>
</link>
Custom links (only) that access non-Interwoven functionality can use the attribute
operationID, to specify that TeamSite role checking should be done before possibly
displaying that link, by providing a unique id and making entries in
userops_custom.xml (see Chapter 7, “Extending GUI Functionality”).
If a link does not specify the target attribute (used internally as a standard HTML frame
target in an anchor tag), its results are displayed in the current browser window. If
target is specified with the value _blank, then a new browser window is opened. The
new browser window’s display features, if the default browser settings are not desired,
can be specified using the windowsFeatures attribute, which takes the same arguments
as JavaScript’s window.open. These are listed in README_base_config_types.
NOTE
Values for target other than _blank can be specified, such as _top or a given target
frame, producing the standard HTML results. The internal Interwoven target values
_hidden or _hierbrowser (visible in some reference files) should not be used.
Individual features of a browser window cannot be customized separately; all of these

values are concatenated together to form a single windowFeatures value. To modify
one of them, such as a window’s height, edit its value in the combined string. Most
window features used for Interwoven-supplied elements can be found in
ref_teamsite_ui_common.xml.
A menu’s reference and its display anchor’s label and image (the visible portion of the
menu before a user clicks on it) can be customized. Menus can be moved or deleted.
Custom menus can be created and inserted into action lists or headings.
Separators can be moved within a menu or deleted. New separators can be created and
inserted into menus.

Headings cannot be deleted. Action lists contained in headings can be deleted, but
action lists that are “top-level” tags (not contained in a heading) cannot be deleted,
though their subelements and labels can be.
ContentCenter Map and Entry Elements

A map defines a series of name-value pairs and is typically used to dynamically map a
property variable which is an enumerated type, such as a Workflow task’s Priority, to
the appropriate icon to display.
map, defines the property file that the map entry values index into.
entry, defines one name-value pair.

<map>
<entry>
</entry>
</map>
Interwoven-supplied maps can be customized. Creating custom maps or deleting

existing maps is not supported.
ContentCenter Applications, Application, and Parameter

Elements
These elements define application wide behavior.
applications, the list of applications whose behavior is to be customized.
application, the specific application whose behavior is to be customized.
param, the application wide parameter specifying the behavior to customize.

<applications>
<application>
<param>
</param>
</application>
</applications>
Interwoven-supplied parameters can be customized. Custom parameters cannot be

created.
Interwoven, Inc. 52
Other Elements
Some elements are listed in the reference files because some of their attributes can be
customized, even though the element itself cannot be customized:
button, its windowFeatures attribute can be customized.
Element Operations
Elements can be inserted, moved, or deleted by using element operations, specified as
XML elements placed in a customization file.
Inserting Elements
By default, custom display elements (portlets, tabs, columns, attributes, menus,
separators, and links) appear at the end of their containing element:
A custom portlet at the bottom of its portlet group column.
A custom tab at the far right of the tab set.
A custom column at the far right of its list.
A custom attribute at the far bottom and right of its display area.
A custom menu at the far right of its action list display (but to the left of any About
or Help link).
A custom separator at the bottom of its menu.
A custom link at the bottom of its menu or at the far right of its heading.
A custom tab cannot be inserted in front of the Interwoven-supplied tabs, but custom
portlets, columns, attributes, menus, separators, and links can be inserted in front of
Interwoven-supplied elements.
To insert a new element before an existing one, place it in an <iwov-insert-before>

element whose id attribute specifies the element it is to be inserted in front of.
Example
To insert a separator before the submit menu item in the Content Center Standard Work
in Progress portlet’s file menu, edit ui_custom.xml:
<iwov-ui>
<action-list id="iw.ccstd.work_in_progress.file.actionlist">
<menu id="iw.ccstd.work_in_progress.file.menu">
<iwov-insert-before
id="iw.ccstd.work_in_progress.file_menu_submit.link">
<separator id="cu.ccstd.work_in_progress.file_menu.separator1">

</separator>
</iwov-insert-before>
</menu>
</action-list>
</iwov-ui>
This menu is listed in the reference file ref_ccstd_ui_portal.xml. The id chosen for
the custom separator is similar to those used in the menu, except for beginning with cu
(using a consistent abbreviation for custom ids, such as cu for “custom” is a good
convention).
To insert a new element after an existing one, place it in an <iwov-insert-after>

element whose id attribute specifies the element it is to be inserted after.
Moving Elements
Portlets, some columns and attributes, menus, separators, and links can be moved within
their containing elements.
To move an existing element before another one, place it in an <iwov-move-before>

element whose id attribute specifies the element it is to be moved in front of.
Example
To move ContentCenter Standard’s Work In Progress portlet before the My Tasks

portlet in the second column of the home page, edit portal_custom.xml:
<iwov-portal>
<portlet-group id="iw.ccstd.home.column2.portal-group">
<iwov-move-before id="iw.ccstd.home.tasks.portlet">
<portlet id="iw.ccstd.home.work_in_progress.portlet"
label="My Modified Content">
</portlet>
</iwov-move-before>
</portlet-group>
</portal-page>
</iwov-portal>
NOTE
When moving an element, its attributes or child elements can be customized. In this
example, the portlet’s label attribute is also being customized.
To move an existing element after another one, place it in an <iwov-move-after>

element whose id attribute specifies the element it is to be moved after.
Interwoven, Inc. 54
Removing Elements
Portlets, some columns and attributes, menus, separators, and some links (those within
menus or action lists) can be removed.
To remove an element, place it within an <iwov-delete> element.
Example
To remove the Import menu item from ContentCenter Professional’s File menu (say, for
a site that enters new content only through forms), edit ui_custom.xml:
<iwov-ui>
<action-list id="iw.ccpro.filesys.menubar">
<menu id="iw.ccpro.file.menu">
<iwov-delete>
<link id="iw.ccpro.file_menu.import.link">
</link>
</iwov-delete>
</menu>
</action-list>
</iwov-ui>
Common Attribute Types

Several attribute types appear in many different elements.
Reference ID
A refid specifies the link, menu, or tab whose attributes are inherited by this link,
menu, or tab element, except where they are specifically overridden. This allows an
item, including custom items, to be specified once and then used elsewhere within the
GUIs, possibly in slightly different manners by overriding attributes as needed.
NOTE
Many links in the Interwoven GUIs, as can be seen in the reference files, consist of
simply an id and a refid. Customizing the original element (whose id is the refid’s
value) will customize it throughout the Interwoven GUIs (wherever it appears in a
refid). To customize an element in just one specific place, add the desired attributes
and their new values, leaving its original element unchanged.
By replacing a link’s refid with another id, a link’s functionality can be redefined.

Label
This specifies the label to be used when displaying a custom GUI element.
Interwoven-supplied labels can be customized as well (even though they do not appear
in the reference files). Its value can either be the literal text to display or a property
string id that identifies a resource within a property file. Using property files is
recommended in order to easily localize and translate customizations into other
languages.
Description
This attribute specifies a description for a GUI element. It is typically used to provide
tool tips that appear when that GUI element is moused over. These cannot be
customized in this release, but can be localized in a future localization release. When
creating custom elements that can have description attributes, supply a description so
that a tool tip will appear when the custom element is moused over.
ResourceBundle
This specifies the property file to be used to obtain text strings or icons. Property files
must be specified as a link element attribute, not in containing elements. Use a property
file for custom elements to enable them to be more easily localized. Custom property
files should be specified using Java package syntax.
Icon
This specifies the URL of an image to display. An image file should be specified relative
to the ContentCenter web application so that it can be located by the browser (specified
as “/” followed by its ready to merge location relative to the content_center
directory).
URL
The URL for a link, tab, or portlet to navigate to when invoked. See Chapter 7,
“Extending GUI Functionality.”
NOTE
Parameters to be supplied to a URL when it is clicked on can be specified by using the
urlParam subelement.
Interwoven, Inc. 56
XML Reference File Organization

With the exception of ui_custom.xml, the correspondence between customization files
and reference files is fairly straight forward:
For portal_custom.xml:
ref_ccstd_portal.xml, portlet arrangement on the home page.
ref_search_portal.xml, search portlet arrangement on the home page.
For application_custom.xml:
ref_teamsite_application.xml, ContentCenter-wide application settings.
ref_formspub_application.xml, FormsPublisher application settings.
ref_ccpro_application.xml, ContentCenter Professional application settings.
ref_ccstd_application.xml, ContentCenter Standard application settings.
For workflow_custom.xml:
ref_ccpro_workflow_config.xml, customizable job and task attributes.
ref_ccstd_workflow_config.xml, customizable Workflow CGI/Wizard
interaction and customizable task attributes.
userops_custom.xml has no corresponding reference file.
For ui_custom.xml, there are different reference files for each application and
subsystem being customized. Despite this, all such customizations are placed together
in one file.
For TeamSite interaction:
ref_teamsite_ui_common.xml, customizable windows settings.
ref_teamsite_ui_workflow.xml, workflow variable mappings.
For FormsPublisher interaction:
ref_formspub_ui_templating.xml, link to generate FormsPublisher files.
For file conversion interaction:
ref_transform_ui_filesys.xml, links to the file conversion subsystem.
For overall search interaction:
ref_search_ui_common.xml, link to the search subsystem.
ref_search_ui_portal.xml, search portlet’s links to the search subsystem.
ref_search_search.xml, default advanced search options configuration.
For ContentCenter Professional:
ref_ccpro_ui_common.xml, application GUI elements.
ref_ccpro_ui_filesys.xml, file system (content tab) elements.
ref_ccpro_ui_vpreview.xml, VisualPreview elements.

ref_ccpro_ui_workflow.xml, workflow Job and Task elements.

ref_reporting_ui_reporting.xml, reporting tab links.
ref_search_ui_ccpro.xml, advanced search screen links.
For ContentCenter Standard:
ref_ccstd_ui_common.xml, application GUI elements.
ref_ccstd_ui_filesys.xml, file system elements.
ref_ccstd_ui_portal.xml, GUI elements for specific portlets.
ref_search_ui_ccstd.xml, search portlet links.
ref_ccstd_ui_templating.xml, form data capture help links.
ref_ccstd_ui_vpreview.xml, VisualPreview elements.
ref_ccstd_ui_workflow.xml, workflow Task elements.
The reference files are automatically produced from Interwoven internal XML files. As
such, their innermost elements are in already rendered format, such as:
<tab id="iw.ccpro.filesys.tab" target="_top"/>
not:
<tab id="iw.ccpro.filesys.tab" target="_top">
</tab>
Sometimes it may be necessary to trace a link back through its refid to determine an
underlying value, if the comments in the reference files are not sufficient.
For example, to customize the windowFeatures value for the ContentCenter

Professional new job link, _iw.ccpro.new_job.link, tracing back its refid in the
reference file ref_ccpro_ui_workflow.xml (to _iw.ccpro.instantiator_popup.link
and then to _iw.teamsite.common.daughter_popup_long.link) will locate the desired
value in ref_teamsite_ui_common.xml.
Alternatively, because this file is the reference for windows, checking it first will lead,
due to its comments, directly to the correct set of windowFeatures to customize.
Working with Columns and Attributes

The Tasks portlet in ContentCenter Standard and the job and task lists in ContentCenter
Professional can be extensively customized. Column order, default sorting, page size,
and which columns are displayed can all be customized. Custom columns can be added
based on custom TeamSite workflow variables or on TeamSite Workflow variables as
exposed by the ContentServices SDK objects CSTask, for tasks, and CSWorkflow, for
jobs. The tasks details screen or section and the jobs details section can also be
customized.
Interwoven, Inc. 58
Example
Suppose the following ContentCenter Professional task list customizations were

desired:
When initially displayed, sort the task List by Due Date.
Remove the Requested By column supplied by Interwoven.
Move the Priority column (that displays icons) after the Task ID column.
Add a custom Release Date column, placing it before the Actions column, and
making it sortable by the end user.
To achieve this, place the following customizations in ui_custom.xml:

<iwov-ui>
<pagedlist id="iw.ccpro.task_list.pagedlist" sortColumn="due_date">
<iwov-delete>
<column id="wfownedby">
</column>
</iwov-delete>
<iwov-move-after id="id">
<column id="priority">
</column>
</iwov-move-after>
<iwov-insert-before id="actions">
<column id="release_date"
label="Release Date"
description="Release Date"
type="date"
typeFormat="SHORT"
sortable="true"
property="variable(release_date)"
width="12%"
align="middle">
</column>
</pagedlist>
</iwov-ui>
To also add Release Date as a custom variable to ContentCenter Professional’s task

details (displayed in the pane below the task list), place the following customization in
workflow_custom.xml:
<workflow-config>
<attributelist id="iw.ccpro.taskdetails.attributelist">
<attribute id="taskdetails.release_date"
label="Release Date"
description="Release Date"
property="variable(release_date)"
type="date"
typeFormat="SHORT">
</attribute>

</attributelist>
</workflow-config>
The underlying property release_date is a custom TeamSite Workflow task variable,

specified as if it were accessed through a Java Bean. For custom TeamSite variables,
the attribute id must contain the name of the custom variable specified in the property
attribute (release_date in this example).
NOTE
Task and job attribute ids can have the same name. The id of the attributelist
element containing this attribute element is what provides the context that the UITK
uses to determine that this workflow custom variable is associated with a task, not a job,
object. In the previous example, the id of the pagedlist element containing the column
element provided the necessary context.
In addition to custom TeamSite Workflow variables, the following lists the standard
TeamSite Workflow job variables that are exposed in the UITK.
Table 2 TeamSite Workflow Job Variables

Column or Attribute Element ID Attribute Property Attribute
job id id id
job owner owner owner.shortName
job owner (alt. form) ownedby owner.shortName
job name name name
job description description description
job creator creator creator
job activation time activationtime activationDate
task subelement from the parenttask workflow.parentTask.

information array of the parent task subelement
for this job
NOTE
Parent tasks are only applicable to nested workflow jobs.
Column or attribute elements based on these workflow variables are specified

identically to custom workflow variables, except for their id and property attributes.
The following table lists the standard TeamSite workflow task variables exposed in the
UITK.
Table 3 TeamSite Workflow Task Variables

task id id id
task owner owner owner.shortName
Interwoven, Inc. 60
Table 3 TeamSite Workflow Task Variables

task owner (alt. form) ownedby owner.shortName
task description description description
task activation time activationtime activationDate
the job containing this task workflow workflow.id
name of the job containing this task wfname workflow.name
owner of the job containing this task wfownedby workflow.owner.shortName
description of the job containing wfdesc workflow.description

this task
activation time of the job containing wfactivationtime workflow.activationDate
this task
subelement from the information parenttask workflow.parentTask.
array of the parent task for this task subelement
status returned (either “”, needsattention needsAttention

“conflict”, “submiterror” or
“updateerror”)
NOTE
Parent tasks are only applicable to nested workflow jobs.
NOTE
Not all standard TeamSite workflow variables are exposed by ContentServices. Nor are
all standard TeamSite workflow variables exposed by ContentServices exposed in the
UITK.
Column or attribute elements based on standard TeamSite Workflow job and task
variables are specified identically to custom workflow variables, except for their id and
property attributes.
The ids specified above must be used (their containing elements provide the necessary
context for the UITK to distinguish a job element from a task element with the same
attribute id). The property attribute for one of these variables is specified using the
listed attribute without enclosing it in variable(), such as
property="activationDate".
NOTE
Either owner or ownedby can be used in the underlying workflow queries, although in
both cases the result is returned (via ContentServices) in a owner.shortName object.
An array of parent task attributes, not a single attribute, is returned by parenttask if

only workflow.parentTask is specified as the property. To return just the desired task
attribute, specify the subelement, such as property="workflow.parentTask.name".

NOTE
For historical reasons, the ID subelement (only) for a parent task can be specified as
either workflow.parentTask.ID or workflow.parentTaskID.
The following table shows the standard TeamSite file list variables exposed in the
UITK. All of the variables shown here are case sensitive.
NOTE
It is not possible to configure a column to display extended attributes.
Table 4 TeamSite File List Variables

Column Element ID Attribute Property Attribute
file name name name.shortName
file size size size
TeamSite group(s) group group

with read/write
permission
most recent file contentModificationDate contentModificationDate
content modification
date
most recent file attributeModificationDate attributeModificationDate
attribute modification
date
file creation date creationDate creationDate
file owner owner owner.shortName
most recent user to lastModifier lastModifier.shortName

modify the file
user or group owning lockOwner lockOwner.shortName
the file lock
lock creation date lockCreationDate lockCreationDate
workarea where the lockAreaName lockAreaName
file is locked
comments entered lockComment lockComment
when the file was
locked
Example
Suppose the following ContentCenter Professional file list customizations were desired:
Remove the Last Modifier column supplied by Interwoven.
Add a Creation Date column, placing it before the Actions column, and making it
sortable by the end user.
Interwoven, Inc. 62
To achieve this, place the following customizations in ui_custom.xml:

<iwov-ui>
<pagedlist id="iw.ccpro.directory_list.paged_list">
<iwov-delete>
<column id="lastModifier"/>
</iwov-delete>
<iwov-insert-before id="actions">
<column id="creationDate"
label="Creation Date"
description="Creation Date"
type="date"
typeFormat="SHORT"
sortable="true"
property="creationDate"
width="12%"
align="middle"/>
</pagedlist>
</iwov-ui>
Enabling ContentCenter Professional’s New File

Templates Feature
The ContentCenter Professional interface can be customized to enable a new file to be
automatically created from a template file, an existing file (“stationary”) of some type
which is copied to the desired location and renamed, so that it can then be opened for
editing with the appropriate application.
Thus, within one workarea, a user who specifies a new file with an extension intended to
be a MSWord document (.doc) would be presented with the File Templates screen in
which the appropriate MSWord template files for use with that directory would be listed
(as well as any other valid template files). Upon selecting the desired template, a copy
of it is placed in the user’s current location and renamed as initially specified.
To enable this feature and set up the needed associations between different templates
and branches, edit the (empty) configuration file file_template_custom.xml as
described in the file README_teamsite_config_types in the reference toolkit and in
Appendix C, “README files.”
If no file-template element is added to this file, then the file templates feature will not
be enabled.
The allow-empty element determines whether or not an “empty” file template should
appear as a choice in the File Templates screen.
Multiple group elements (typically, one per file type) and multiple template
subelements within a given group can be specified.

Example
To supply the white_paper MSWord template file as the new file specified by the user,
when the New File command is selected from ContentCenter Professional’s File menu
within the main branch or marketing workarea of that branch, edit
file_template_custom.xml as follows:
<file-templates>
<allow-empty>false</allow-empty>
<group id="MSWord"
label="label.msword"
resourceBundle="com.mycompany.ui.filesys.template">
<locations>
<vpath-regex value="/default/main/branch1/.*"/>
<vpath-regex value="/default/main/WORKAREA/marketing/.*"/>
</locations>
<template id="White Paper"
label="White Paper"
area-relative="false"
vpath="/default/main/admin/STAGING/white_paper.doc"/>
</group>
</file-templates>
Customizing ContentCenter Application

Behavior
To configure various aspects of either ContentCenter Standard’s or ContentCenter
Professional’s behavior (or both), default-param and param elements can be modified
in application_custom.xml.
Behavior that affects all ContentCenter applications is specified using the default-parm
element at the applications level, such as:
<applications>
<default-param id="name" value="setting">
</default-param>
</applications>
If behavior can be overridden for a specific ContentCenter GUI, such as ContentCenter

Standard, this is specified using a param element at the application level, such as:
<applications>
<application id="ccstd">
<param id="name" value="setting">
</param>
</application>
</applications>
To override this behavior for ContentCenter Professional instead, ccpro would be

specified for the application id.
Interwoven, Inc. 64
NOTES
Not all default parameters can be overridden at the application level.
Some parameters cannot be overridden at the applications level and must be
overridden at the application level.
Configuring ContentCenter Maximum Saved Searches

The default behavior in ContentCenter is for users to be able to save a maximum of 20
saved searches. This parameter is customizable. To enable ContentCenter GUI users to
save up to 50 saved searches, edit application_custom.xml as follows:
<applications>
<application id="ccpro">
<param id="iw.search.maximumsavedsearches" value="50">
</param>
</application>
<param id="iw.search.maximumsavedsearches" value="50">
</param>
</application>
</applications>
This behavior must be specified for each ContentCenter GUI individually.
CAUTION
The number of saved searches, with a large number of users, may degrade performance
depending on the memory size of the TeamSite server. For systems with a low number
of TeamSite users, such as 100 users, the number of saved searches can be greatly
increased without affecting adversely performance.
Configuring ContentCenter Data Record Search

The default behavior in ContentCenter is for data record search to be enabled. To
disable this feature so that users cannot search data records, edit
application_custom.xml as follows:
<applications>
<param id="iw.formspub.searchdcr.enabled" value="false">
</param>
</application>
</param>
</application>

</applications>
This behavior is specified for each ContentCenter GUIs individually. To disable data
record search for only ContentCenter Standard, edit application_custom.xml instead
as follows:
<applications>
</param>
</application>
</applications>
Enabling Prompting after Modifying Forms (use tt-data) in

ContentCenter Professional
The default behavior in ContentCenter Professional after users create or modify a form
is to not associate the modified form with a workflow, even if such workflows (tt-data
workflows) are configured in available_templates.cfg and the user has access to
them. To alter this behavior so that users, after creating or modifying a form, are
prompted to associate it with a workflow (provided one is configured and they can
access it in their current role), edit application_custom.xml:
<applications>
<param id="ccpro-use-tt-data" value="true">
</param>
</application>
</applications>
Configuring ContentCenter Saving of Incomplete Forms

The default behavior in the ContentCenter GUIs is that incomplete forms (with missing
mandatory fields) can not be saved. Starting with TeamSite 6.7.1 Service Pack 1, this
default behavior can be overridden, if desired.
NOTE
Allowing incomplete forms to be saved can potentially create problems for workflows
(tt-data workflows) or scripts that automatically trigger off saved forms and initiate
submissions or attach them to submit workflows. Such scripts or workflow external
tasks should filter file attachments by the external attribute, iw_form_valid, new in
TeamSite 6.7.1 Service Pack 1, which is set to false for incomplete forms (true for
complete forms) by the ContentCenter GUIs.
To enable this feature so that users can save incomplete forms, edit
<applications>
Interwoven, Inc. 66
<param id="iw.formspub.allowsaveincompleteforms" value="true">
</param>
</application>
</param>
</application>
</applications>
This behavior is specified for each ContentCenter GUI individually. To enable saving
incomplete forms for only ContentCenter Professional, edit application_custom.xml
instead as follows:
<applications>
</param>
</application>
</applications>
Configuring ContentCenter Data Record Form Rendering

Starting with TeamSite 6.7.1, by default, when editing existing forms with replicant
elements that have many subelements (children), these replicants are displayed in a
collapsed format and an Collapse/Expand All Items button is provided to expand
these collapsed replicants. (New forms are always displayed in fully expanded format.)
To speed the initial display of forms with collapsed replicants, background rendering of
collapsed form replicants is turned off and replicants are rendered only when they are
expanded by users.
This behavior can be customized in various ways. It can be overwritten on a

per-data-template basis through the FormsPublisher templating.cfg file (as described
in the FormsPublisher manuals) or globally, for each ContentCenter GUI.
The default number of immediate children that triggers the display of a replicant in
collapsed format is 3. This value can be customized (on either a per-data-template basis
through the FormsPublisher templating.cfg file or globally, for each ContentCenter
GUI).
The default collapsing of replicants with many children can be disabled. If disabled, the
ContentCenter GUI will automatically expand all expandable items in data record forms
whenever displaying them, while continuing to display a Collapse/Expand All Items
button. If users then collapse the expandable items in a form, this setting will be
respected when the form is next displayed (though, if a replicant is collapsed,
background rendering of it will occur in anticipation of that replicant being later
expanded).
Disabling the default collapsing of replicants slows the initial loading of forms that have
replicants with many children, whether or not they have been collapsed, but will speed

the display of any collapsed replicants when they are later expanded by users (due to the
background rendering).
If the default collapsing of replicants is disabled, then the ContentCenter GUIs can be
customized to remove the Collapse/Expand All Items button in forms so that users
can not collapse the expandable items in a form. This customization can not be done on
a per-data-template basis.
These customizations must be specified for each ContentCenter GUI individually.
To change the number of immediate children that triggers the display of replicants in
collapsed format to 5 in ContentCenter Professional while disabling both the default
collapsing of replicants and the display of the Collapse/Expand All Items button in
forms in ContentCenter Standard (so that forms are always displayed in fully expanded
format and users can not collapse replicants), edit application_custom.xml as follows:
<applications>
<param id="iw.formspub.default.children.collapse.threshold"
value="5">
</param>
</application>
<param id="iw.formspub.default.render.mode"
value="expand-direct-children">
</param>
<param id="iw.formspub.expandall.enabled" value="false">
</param>
</application>
</applications>
Configuring ContentCenter Locking Behaviors

When a TeamSite branch is first created, its locking model is specified. There are three
branch locking models supported by TeamSite:
Submit locking—if a file is locked, only users within the workarea where it is
locked may submit the file to the staging area. Users within other workareas are still
allowed to edit their copies of this locked file but may not submit any of them until
the user who holds the lock either submits their version of the file or releases the
lock upon it.
Optional write locking—if a file is locked, only users within the workarea where it
is locked may edit (or submit) the file to the staging area. Users within other
workareas are still allowed to view their copies of this locked file but may not open
them for editing (or submit them) until the user who holds the lock either submits
that version of the file or releases the lock upon it.
Mandatory write locking—a file must be locked before it can be edited. Once
locked, users within other workareas can view their copies of this file but may not
Interwoven, Inc. 68
open them for editing (or submit them) until the user who holds the lock either
submits that version of the file or releases the lock upon it.
Submit locking is the default and least restrictive locking model. If a file is not locked
under either submit locking or optional write locking, then different copies of the same
file can be freely edited in different workareas, resulting in versions that are in conflict
once one copy has been submitted and then an attempt is made to submit another copy.
Within the ContentCenter GUIs, the merge tool then appears to allow a user to resolve
any conflicts in the actual content of the conflicting files before resolving the version
conflict.
NOTE
Locking models apply to files other than data entry forms. Mandatory write locking of
data entry forms (DCRs) is automatically enforced by FormsPublisher.
In addition to specifying a TeamSite locking model upon branch creation and, in

TeamSite 6.7+, by specifying role based locking as well, locking behavior can be
alternatively enforced by the ContentCenter GUIs on their own operations, by
configuring the ContentCenter web application to do so. However, doing so effectively
loses the option possible, in TeamSite 6.7+, to define less restrictive locking for some
users and more restrictive locking for other users on the same branch by specifying
different role based locking and assigning different users different roles on that branch.
NOTE
Locking behavior restricted by the ContentCenter GUIs, not TeamSite itself, has no
effect on TeamSite files accessed through other means, such as TeamSite Front Office,
the Intelligent File System, or the ContentServices SDK.
Two parameters can be set to enforce stricter locking policies by the ContentCenter
GUIs on branches with submit or optional write locking. By default, both of these
parameters are set to false. These parameters are overridden at the applications level,
affecting both ContentCenter Standard and Professional.
To configure the ContentCenter GUIs to automatically lock a file upon it being edited
within branches with a submit locking model (effectively enforcing mandatory write
locking on these branches), edit application_custom.xml as follows:
<applications>
<default-param id="iw.common.edit.submit_lock_model.lock_on_edit"
value="true">
</param>
</applications>
To configure the ContentCenter GUIs to automatically lock a file upon it being edited
within branches with an optional write locking model (effectively enforcing mandatory
write locking on these branches), edit application_custom.xml as follows:
<applications>
<default-param

id="iw.common.edit.optional_write_lock_model.lock_on_edit"
value="true">
</param>
</applications>
A third parameter modifies the behavior of the ContentCenter GUIs when enforcing
mandatory write locking, either due to the previous customizations, branch permissions,
or role permissions. In versions prior to TeamSite 6.7.1 Service Pack 1, if a branch had
mandatory write locking or mandatory write locking was being enforced by the
ContentCenter GUIs (or LaunchPad or the TeamPortal portlets), a lock was obtained
whenever a file was opened for any reason by a user (under the assumption the file was
being opened for editing). Starting with TeamSite 6.7.1 Service Pack 1, by default,
when a ContentCenter GUI (or LaunchPad or the TeamPortal portlets) is enforcing
mandatory write locking, a file is only locked after being modified. To turn this
behavior off (so that a lock is obtained when a file is opened but not modified), edit
<applications>
<default-param id="iw.common.edit.lock_on_modification" value="false">
</param>
</applications>
Configuring ContentCenter Extended Attribute Behavior upon

Import
By default, when a file is imported into a TeamSite workarea replacing a file of the same
name in that workarea, no extended attributes (metadata) associated with the previous
version of that file are preserved and associated with the newly imported version.
To configure the ContentCenter GUIs to preserve extended attributes associated with an

older version of a file in a workarea being replaced by an imported file, edit
application_custom.xml:
<applications>
<default-param id="iw.common.import.inherit_extended_attributes"
value="true">
</param>
</applications>
NOTE
Configuring this behavior within the ContentCenter GUIs has no effect on files
imported into a TeamSite workarea through other means, such as TeamSite Front Office,
the Intelligent File System, or the ContentServices SDK.
This behavior must be specified at the applications level.
Interwoven, Inc. 70
Configuring ContentCenter Authentication Cookie Expiration

When a user logs into a ContentCenter GUI, a browser “cookie” is generated containing
some authentication information, including a value for how long the browser should
store this cookie. By default, the lifetime of these cookies is set to be infinite,
resulting in persistent session cookies being issued and users remaining logged into
TeamSite until either their TeamSite timeout value expires or the user deliberately logs
out.
To configure the ContentCenter GUIs to issue non-persistent session cookies, so that

users will be automatically logged out from TeamSite whenever they close their
browsers, edit application_custom.xml:
<applications>
<default-param id="iw.common.authentication.cookie_lifetime" value="0">
</param>
</applications>
No values besides 0 and infinite can be specified. This behavior must be specified at
the applications level.
Configuring ContentCenter SSO Behavior

Six different authentication parameters can be set, using the UserInterface Toolkit, to
support single-sign-on (SSO) authentication within the ContentCenter GUIs, as
described in the TeamSite Administration Guide. All these parameters must be specified
at the applications level.
Configuring the ContentCenter Tagging Interface

Starting with TeamSite 6.7.1 Service Pack 1, a new tagging interface is available by
default when tagging single files. The new tagging interface is also, by default, invoked
by CGI scripts that initiate tagging steps. If desired, this default behavior can be
overridden to use the previous TeamSite tagging interface in each of these situations. To
do this, edit application_custom.xml as follows:
<applications>
<param id="iw.tagui.singleFileUI" value="old">
</param>
<param id="iw.tagui.CGIEnv" value="old">
</param>
</application>
<param id="iw.tagui.singleFileUI" value="old">
</param>
<param id="iw.tagui.CGIEnv" value="old">
</param>

</application>
</applications>
This behavior is specified for each ContentCenter GUI individually.
NOTES
The new tagging interface can be used in ContentCenter while the old one is used by
CGI scripts (for compatibility with existing custom CGI scripts), though this will
not be consistent to end users. See Appendix B, “Migrating Existing Customizations”
for how to migrate custom CGI scripts so that they are compatible with the new
TagUI.
A third parameter, iw.tagui.multiFileUI, is also exposed but its current only
permitted value is old.
Eliminating the Tagging Step from ContentCenter Standard

Wizards
The default behavior for many ContentCenter Standard wizards is to invoke a tagging
(or metadata capture) screen as their final step before invoking a TeamSite workflow. If
existing workflows already invoke a custom tagging step of their own, this produces a
redundant tagging step for end users. The ContentCenter Standard application can be
configured to have the Import, New Form, Edit, Submit, and Tag Wizards always skip
their tagging step by editing application_custom.xml:
Example
<applications>
<param id="skip-tag-step" value="true">
</param>
</application>
</applications>
Controlling File Tagging in ContentCenter Standard Wizards

Many ContentCenter Standard wizards, such as Copy, Import, New Form, Edit, and
Submit, invoke a tagging (or metadata capture) screen. The default tagging behavior of
these wizards is to tag all files that they are processing. The ContentCenter Standard
application can be configured to filter out certain files by file type, as specified by
regular expressions, so that they are not tagged by these wizards.
NOTE
Such filtering does not apply to the Tag wizard itself. It will always tag all the files
presented to it.
Interwoven, Inc. 72
An empty regular expression means that no filtering takes place and all files are tagged.
A regular expression, such as .* (matches all files) or \.txt (matches all text files) has to
be wrapped in two identical alphanumeric delimiters, such as //, to be valid.
Example
To filter out all files ending in .txt from being tagged in ContentCenter Standard, edit
<applications>
<param id="filtered-file-type-regex" value="/\.txt/">
</param>
</application>
</applications>
Eliminating the Submit Wizard Step after ContentCenter

Standard file operations
The default behavior for ContentCenter Standard is to invoke a submit wizard after the
following file operations:
Edit
Copy
Delete
Move
Rename
Import
New DCR
ContentCenter Standard can be configured to omit the submit wizard following these
operations. When the submit wizard is omitted, these operations result in a file
remaining as a work in progress file until a user explicitly submits this file by clicking
the Submit button.
To omit the default submit wizard step after file operations, edit
application_custom.xml so that the value of skip-submit-step is true:
Example
<applications>
<param id="skip-submit-step" value="true">
</param>
</application>
</applications>

Configuring ContentCenter Standard Workarea Names

Workarea names in ContentCenter Standard can be configured to appear in one of four
different formats, depending on what value param is set to:
branch_workarea, names appear as branch : workarea. This is the default.
workarea, only the workarea names are displayed.
branch, only the branch names are displayed.
description, only the workarea’s description is displayed.
NOTE
Depending on how many workareas ContentCenter Standard users have access to and
the actual site naming conventions, some of these options could lead to end user
confusion (with users unable to tell which workarea they are currently in). Do not use
the branch option if ContentCenter Standard users have access to more than one
workarea on a branch. Do not use the workarea option if duplicate workarea names are
used on the same branch. Avoid duplicating both branch and workarea names in
combination; if you must do so, then supply different descriptions and use the
description option.
This applies to all places workareas are displayed in ContentCenter Standard:

My Workareas, My Favorites, New Forms, and Work in Progress portlets.
File chooser (in the drop-down menu).
Task details screen.
Directory listings.
To configure only the workarea names to be displayed, edit application_custom.xml:

<applications>
<param id="iw.common.workarea_display_name.property"
value="workarea">
</param>
</application>
</applications>
Enabling ContentCenter Standard “Edit My Workareas”

feature
Workareas in ContentCenter Standard can be configured to appear in the ContentCenter
Standard “My Workareas” portlet by each user selecting which workareas appear,
instead of having all the workareas that the user has been granted write permissions to
automatically appear (the default behavior). This can potentially reduce user confusion
and improve performance, if users have access to many different workareas, some of
Interwoven, Inc. 74
which are no longer relevant to their immediate tasks. If this behavior is desirable, it
can be enabled by editing application_custom.xml:
Example
<applications>
<param id="iw.common.my_workareas.configurable.property" value="true">
</param>
</application>
</applications>
Enabling Directory Browsing instead of Editing Directories

with VisualPreview
As discussed in the TeamSite Installation Guide, the default behavior when a TeamSite
workarea name is selected in ContentCenter Standard’s My Workareas portlet or Task
Details screen is to assume:
1. That the underlying content web server (typically, Apache) has been configured to
forward this directory request to a file (typically, index.html), which will display
the directory listing as HTML (and that such a file exists).
2. That iwproxy has been properly configured to follow this forwarding, so that the
VisualPreview toolbar can then be used to edit this HTML file.
3. That this behavior, allowing the end user to edit the directory listing as HTML (as
opposed to browsing the workarea in a ContentCenter list view), is desired by the
end user (this may well be the case but it may not).
If the HTML file does not exist or the system is not configured properly, errors will result.
To avoid such errors or to simply alter the behavior to browsing the workarea in a
ContentCenter Standard list view, edit application_custom.xml:
Example
<applications>
<param id="iw.common.view_area_action.property" value="browse">
</param>
</application>
</applications>
The value for this parameter as supplied by Interwoven (to enable editing the directory
file with VisualPreview) is preview.

NOTE
The emails generated by ContentCenter Standard use the URL command viewarea to
ensure that their behavior (browse or preview) matches the value set by this parameter.
Extending ContentCenter’s Behavior

With the customizations described in this chapter, it is possible to alter the behavior and
appearance of the ContentCenter GUIs as supplied by Interwoven considerably.
Additional functionality can be added by specifying custom menu items, tabs, and
portlets that can invoke, in addition to links within the ContentCenter web application:
URLs outside of ContentCenter, CGIs, and custom Java code (servlets and JSPs), as
described in Chapter 7, “Extending GUI Functionality.”
Interwoven, Inc. 76
Chapter 5
Customizing GUI Appearance
This chapter describes how to customize the external appearance of the ContentCenter
GUIs by editing HTML cascading style sheets or placing a custom logo for co-branding.
Style Sheet Customizations

Style sheet customizations are made by overwriting portions of Interwoven defined
styles in the appropriate custom.css style sheet. If desired, new styles—for example, a
special style needed for a custom module—can also be defined in these style sheets.
Using Custom Style Sheets

Each HTML page displayed by the UITK includes the base toolkit style sheet, plus any
relevant style sheets from other toolkits. Whenever any given Interwoven style sheet is
included, its corresponding custom.css style sheet is included immediately afterwards.
Because these are cascading style sheets, any change to an Interwoven defined style by
a custom style sheet takes precedence over the attributes of the defined style that it
modifies.
Each Interwoven defined style name begins with the prefix “.iw-”. New customer
styles (as opposed to customized Interwoven styles) should not use this prefix.
To customize an Interwoven style, copy its style definition name from the reference
style sheet into its custom style sheet, make the desired changes or additions, and
rebuild the web application.
Do not copy the entire style definition into the custom style sheet; copy only those
attributes that you are actually customizing.
NOTE
By copying only attributes that you are customizing, you ensure that any changes made
by Interwoven in a future release to attributes which you are not customizing will be
automatically applied when the (new) web application is rebuilt.

Chapter 5: Customizing GUI Appearance
Style Sheet Scope

Because style sheets are provided on a per toolkit basis, changes can be made either
globally in the base toolkit or at a more specific toolkit level.
For example, by specifying different colors in the custom base toolkit style sheet and a
custom logo in the base/images directory, all ContentCenter interfaces would be
affected. Then, by specifying different font styles in the ContentCenter Standard
custom style sheet, only the fonts in that interface would be changed while fonts in the
ContentCenter Professional interface would remain unchanged.
This is useful because many styles can look nice in one interface but not in another
interface.
In iw-home/local/config/lib/content_center/customer_src:
To apply a style change globally, edit custom.css in /web/base/styles.
To apply a change to ContentCenter Standard, but not to ContentCenter
Professional, edit custom.css in /web/ccstd/styles.
To apply a change to ContentCenter Professional, but not to ContentCenter
Standard, edit custom.css in /web/ccpro/styles.
To apply a change to FormsPublisher, in all the UIs in which it appears, edit
custom.css in /web/formspub/styles.
Reference files ref_toolkit_iw.css, for each of these toolkits, exist in:

iw-home/local/config/lib/content_center/reference/toolkit/styles
These files contain the Interwoven styles that can be customized, organized by the
internal toolkit in which they are used by Interwoven.
Important. Even though an Interwoven style may be defined in the base/iw.css style
sheet, it does not mean that it must be customized in the base toolkit custom.css style
sheet. If the change should apply only to ContentCenter Standard, not Professional,
then this style should be customized in the ContentCenter Standard custom style sheet.
NOTE
Styles defined in one of the ContentCenter GUI’s reference file, such as
csstd/iw.css for the ContentCenter Standard GUI, should only be customized in the
corresponding custom.css file.
Similarly, if a base style is to be customized in two different ways, one for each
ContentCenter GUI, then it should be customized in each of their custom style sheets.
Example
The style iw-base-heading, in the base reference style sheet base/iw.css, defines the
background and border attributes of a heading in the Interwoven GUIs:
Interwoven, Inc. 78
.iw-base-heading
{
background-color: #ffffff;
background-image: url(../images/heading_bg.gif);
border-top: solid 1px #999999;
border-left: solid 1px #999999;
border-bottom: solid 1px #999999;
border-right: solid 1px #999999;
}
NOTE
Specify URLs for style sheet images relative to the styles directory.
Working from iw-home/local/config/lib/content_center, to change headings in

ContentCenter Standard to use a dark blue background color instead of the
Interwoven-supplied background image, place the following entry in:
/customer_src/web/ccstd/styles/custom.css
.iw-base-heading
{
background-color: #003366;
background-image: none;
}
To change headings in ContentCenter Professional to use a light gray background color

instead of the Interwoven-supplied background image and a dark gray border color,
place the following entry in:
/customer_src/web/ccpro/styles/custom.css
.iw-base-heading
{
background-color: #cccccc;
background-image: none;
border: 1px solid #999999;
}
NOTE
Background images need to be turned off explicitly if they are not wanted.
Custom Styles within Custom Portlets

ContentCenter Standard styles—and any custom styles specified in the base or ccstd
custom.css files—are automatically applied to custom portlets. Because custom
portlets are attached to the ContentCenter home page with a Java include (and can
therefore not contain an HTML HEAD element), any additional custom styles must be
specified as inline attributes.

Examining ContentCenter Styles

A tool that can be used to inspect style usage within the ContentCenter GUIs is the
DOM Inspector feature of the Mozilla web browser. It can assist developers in figuring
out the styles used by various visual features in the ContentCenter GUIs.
The DOM Inspector can be used to inspect the live DOM (Document Object Model) of
any web document or web application, such as the ContentCenter GUIs. Information
regarding it can be found at:
http://www.mozilla.org/projects/inspector
To use it, view the live document (in this case, a ContentCenter GUI) in the lower pane
of the Mozilla browser. The upper left pane displays the DOM of the current document
as a structured tree. To inspect a particular feature, click on the Inspect graphical button
displayed on the Mozilla toolbar and then click on the desired ContentCenter visual
feature displayed in the live pane. The Inspect button freezes the selected feature
(instead of activating it) and the DOM structured tree (in the upper pane) then
automatically scrolls to that feature and highlights it, displaying its class and css style
name.
NOTE
Not all aspects of the ContentCenter GUIs will necessarily display properly in the
Mozilla DOM Inspector. This is an unsupported tool that developers may find useful.
Co-branding
Each ContentCenter GUI has an application logo occupying the upper, left-hand corner
(next to the “powered by Interwoven” logo) that can be overridden by a custom logo
placed in the customer toolkit, allowing co-branding of the customized GUI.
NOTE
The “powered by Interwoven” logo cannot be replaced.
In addition, the TeamSite login “splash” screen can also be customized.
Example
To co-brand ContentCenter Professional, create an images subdirectory in:

iw-home/local/config/lib/content_center/customer_src/web/ccpro
Place the custom logo in it, naming it logo.gif. After rebuilding the ContentCenter
web application, the custom logo will appear next to the “powered by Interwoven” logo
in ContentCenter Professional, but not ContentCenter Standard.
Interwoven, Inc. 80
Example
To co-brand the TeamSite login screen, create an images subdirectory in:

iw-home/local/config/lib/content_center/customer_src/web/teamsite
Place the custom logo in it, naming it login_splash.gif. After rebuilding the
ContentCenter web application, the custom logo will appear in the TeamSite login
screen.
Per Form Customizations

In addition to customizing the FormsPublisher GUI as a whole, it is possible to
customize individual entry forms. This can be used to emphasize certain form elements
to speed form data entry.
This per form customization capability uses the older (non-UITK) customization
mechanisms. To make changes:
Edit templating.cfg.
Issue iwreset -ui for your changes to take place (instead of rebuilding the
ContentCenter web application).
Because these customizations are not in the customer toolkit, you are responsible for
preserving them across a future release.
For more information on customizing data entry forms on a per form basis, see the
TeamSite FormsPublisher Developer’s Guide.

Interwoven, Inc. 82
Chapter 6
Customizing Online Help
This chapter describes how to customize ContentCenter online help.
Types of Online Help

Two types of online help are provided as part of the ContentCenter interfaces:
Online help pages accessed when a user clicks on a GUI help link. ContentCenter
Standard and Professional each have an integrated help system with a table of
contents, index, and search capability.
Figure 8 TeamSite Online Help System
Help Link
Help Page
Navigation
Section
Current
Screen Help

Chapter 6: Customizing Online Help
The ContentCenter Standard help system can also be accessed from the home page
introductory How do I component.
Wizard topic help that appears when a user clicks on one of several questions
displayed in a ContentCenter Standard wizard’s topic help area.
Figure 9 TeamSite Wizard Help Topics
Wizard
Wizard Help
Topics
Answers
Screen
NOTE
Do not confuse help topics with the “tool tips” that appear whenever a user mouses over
a button within the UIs. Tool tips are not customizable in this release of the UITK.
They are provided on a per locale basis and are localized as described in a future
localization release.
Underlying Files
Online help pages are HTML pages.
Each set of wizard topics consists of two files, a JSP “snippet” file that contains the
questions and an HTML file that displays the answers.
Interwoven, Inc. 84
NOTE
The ContentCenter Standard introductory component has a similar JSP “snippet” file
containing its “How do I” topics, but no corresponding HTML file as its links point to
ContentCenter Standard help pages.
Customization Tools
An Interwoven-supplied online help system consists of HTML pages containing both help
content and indexing, search, and navigational aids, produced using WebWorks
Publisher Professional 7.0 from Quadralay, plus—to provide search
capability—Dreamweaver 4.0 from Macromedia with the Deva Tools extension from
deva associates.
Straight forward help customizations can be done either in any HTML editor or by editing
the raw HTML in any text editor.
More complex customizations to entire help systems, requiring indices and tables of
contents to regenerated, should be done using a help creation tool, such as Macromedia
Dreamweaver with the Deva Tools extension.
Online Help File Organization

Each help system resides in an internal toolkit directory. The contents of this directory
are copied into the reference/toolkit/help/toolkit/help/locale directory under
content_center.
For example, the English reference help system for the ContentCenter Standard UI is in:
reference/ccstd/help/csstd/help/en
Within each help directory will be found, for that help system:
Contents.html, its table of contents file.
IX.html, its index file.
An images directory, containing images used by the help system.
iw.css, its style sheet.
custom.css, an empty style sheet to make customizations in.
<prefix>_<help_screen>.html, such as s_submitfiles.html, for every help page.
The prefix for ContentCenter Standard is “s”; for ContentCenter Professional it is “p”.
For each set of wizard “Why must I” topics there are two question and answer files:
<prefix>_<wizard_name>_why.jsp, such as s_deletefile_why.jsp.

<prefix>_<wizard_name>_why_page.html, such as s_deletefile_why_page.html.
The ContentCenter Standard introductory “How do I” component’s question file is

s_how_portlet.jsp.
Other files (used to provide search capability, plus JavaScript files to provide pop-ups,
collapsible menus, and so on), as well as supporting images, also exist in these
directories. When copying an entire help system to a working directory, these files and
folders should be copied as well. Otherwise, they can be ignored.
When copying help files in order to customize them, make sure to place them
underneath the corresponding customer_src/web/toolkit/help/locale directory.
Help Style Sheets
As discussed previously, the online help system uses its own set of style sheets so that
its appearance is visually distinct from the UIs themselves.
The base help styles are defined in the base toolkit (reference/base/help/iw.css).
Each toolkit also has a iw.css style sheet defining one style that is different for the two
applications, as well as an empty custom.css file.
Customizing Online Help Pages

Customizations to online help content are done by:
Copying files from the appropriate reference toolkit help directory into the
corresponding customer_src toolkit help directory.
Editing them.
Rebuilding the web application.
NOTE
Copy these files—do not simply move them—so that the changes you make can be
undone by simply removing the corresponding modified files from the customer toolkit,
rebuilding the web application, and then having the original reference files on hand in
order to attempt another customization.
Making Simple Changes to Online Help

Straight forward changes to online help, such as adding an explanation of a custom
menu item to an already existing help page, can be done by simply copying the relevant
HTML page into the corresponding directory of the customer toolkit and editing it as
needed.
Interwoven, Inc. 86
Once you are done, rebuild the web application and your modified help page will
automatically replace the Interwoven-supplied one.
Example
To modify ContentCenter Professional’s Getting Started help page, supplying help for
the three custom tabs added as part of the customer samples toolkit, copy
reference/ccpro/help/ccpro/help/en/p_user_interface.html to
customer_src/web/ccpro/help/en and edit it to:
Remove the note under the summary of the content and workflow tabs.
Add a summary of the custom DevNet, Current User, and Writing Guide tabs,
following by a heading “Screen Elements” to provide a transition to the next image
in this help file:
<h4>Custom Tabs</h4>
<ul>
<li>Use the <b>DevNet</b> tab to access the Interwoven Developer
Network.</li>
<li>Use the <b>Current User</b> tab to see what role you are currently
logged in as.</li>
<li>Use the <b>Writing Guide</b> tab to view the Ajuba Corporate Writing
Guide.</li>
</ul>
<h4>Screen Elements</h4>
Rebuild the web application, with the customer samples turned on. Here is a screen shot
showing this customization

Figure 10 TeamSite Customized Online Help
NOTE
The link that brings up the User Interface help screen for all custom tabs cannot be
customized for each custom tab. If extensive detailed help is needed for a specific
custom tab, add a custom help page linked from this page.
To undo a change, remove the modified help page from the relevant customer toolkit
help directory and then rebuild the web application.
NOTE
When a future Interwoven release occurs, you will need to merge any help pages that
you have modified (residing in the customer toolkit) with the corresponding ones
supplied by Interwoven that contain updated or additional information. If you fail to do
this, then—because the help pages in the customer toolkit will be the ones
displayed—the new information supplied by Interwoven in this later release will not be
visible.
Interwoven, Inc. 88
Making Complex Changes to Online Help

Very complex changes to an online help system, such as adding a set of new HTML
pages that you wish to cross reference and index with the ones provided by Interwoven,
are best done by copying all the Interwoven-supplied help pages into a working
directory—not the corresponding toolkit help directory—and then editing them in a
help creation tool, such as Macromedia Dreamweaver with Deva Tools, so that the
index, search, and table of contents for that help system can be automatically
regenerated.
Use a working directory when making complex changes to an online help system and
copy only the new and modified files into the customer toolkit when you are done.
After doing this, copy only your new and modified files, plus the regenerated table of
contents, index, and search files, into the relevant customer toolkit help directory and
then rebuild the web application.
NOTE
This process ensures that you will have to do a minimum amount of work when merging
your modifications with updated Interwoven-supplied files with a new TeamSite release
or upgrade. To do this merge, copy the new help files into a working directory, merge
your modified files with the newly supplied ones, regenerate the index and table of
content files, and then copy only the modified files to the relevant customer toolkit
directory.
To undo a complex change, remove the modified help pages, plus the index, search, and
table of content files, from the relevant customer toolkit help directory and then rebuild
the web application.
Customizing Wizard Help Topics

Each set of wizard help topics consists of two question-and-answer files:
The JSP “snippet” file that contains the topics as a set of HTML link references.
The HTML file that displays the corresponding help information for these topics.
The JSP snippet is inserted in the actual UI wizard JSP using a Java Include and must
therefore get its context path dynamically when constructing its links.
For example, here is the JSP snippet file, s_delete_file_why.jsp, for ContentCenter
Standard’s Delete wizard:
<%
final String contextPath = request.getContextPath();
%>

<table width="100%" border="0" cellpadding="4" cellspacing="0">

<tr>
<td>
<a href="#" class="iw-base-link-help" onClick="window.open('<%=
contextPath %>/ccstd/help/en/s_delete_file_why_page.html#wp1002624',
'help','scrollbars=yes,resizable=yes,width=600,height=400,left=410,
top=20,screenX=410,screenY=20')">I made a mistake; can I undo it?</a>
</td>
</tr>
<tr>
<td>
top=20,screenX=410,screenY=20')">Why do I have to submit a deletion?</a>
</td>
</tr>
<tr>
<td>
top=20,screenX=410,screenY=20')">What if I want to change the page that
points to this one and publish both of them at the same time?</a>
</td>
</tr>
</table>
To edit a topic’s question, you do not need to edit the HTML file; just the JSP snippet.
To edit a topic’s answer, you do not need to edit the JSP snippet; just the HTML file.
To add a custom topic or to remove a topic, you need to edit both files.
The introductory How Do I component supplied with ContentCenter Standard is

organized very similar to a wizard’s help topic section. It consists of a portlet and a JSP
snippet of links, s_how_portlet.jsp, that index into general HTML help system pages.
To edit the introductory portlet’s help topics, remove a topic, or add a new one, follow
these same steps, with the exception that instead of editing the HTML “answer file”, you
instead edit the actual help pages as needed.
Interwoven, Inc. 90
Chapter 7
Extending GUI Functionality
This chapter describes how to extend the ContentCenter GUIs by adding custom menu
items, tabs (in ContentCenter Professional), and portlets (in ContentCenter Standard)
that invoke ContentCenter functionality, web pages, CGIs, or custom Java code.
Custom Menu Items

Custom menu items can access web pages and invoke CGIs, custom Java code, or
ContentCenter functionality.
Adding ContentCenter Functionality

If desired, custom menu items can be created to access additional ContentCenter
functionality.
Example
As supplied by Interwoven, it is not possible to delete directories in the ContentCenter

Standard file browser. To add that functionality, a link is added to its directory actions
menu (which is, by default, empty and not displayed until an element is added to it) by
placing this entry in ui_custom.xml:
<iwov-ui>
<action-list id="iw.ccstd.list_directory.dir_list.actionlist">
<menu id="iw.ccstd.list_directory.dir_actions.menu"
titleImage="/base/images/icn_menuarrow.gif">
<link id="cu.ccstd.delete_directory.link"
label="Delete Folder"
description="Delete Folder"
refid="_iw.ccstd.common.delete.link">
</link>
</menu>
</action-list>
</iwov-ui>
Because the menu is empty, no insert operation is needed. In this example, the delete
link (which invokes the Delete wizard on the selected file system element, in this case
the directory that this menu is anchored to) is already existing functionality.

Chapter 7: Extending GUI Functionality
Link URL Attribute

A link element can access an external web page, CGI, or ContentCenter web page,
servlet, or JSP, using its url attribute. Specify the url attribute in the XML files as
follows:
To access a web page external to the ContentCenter web application, use its absolute
URL.
To access a CGI located in iw-home/iw-bin, use /../iw-bin/cginame.

To access a servlet, JSP, or web page within the ContentCenter web application, use
its location relative to the ContentCenter web application, with “/” prepended. Do
not prepend either the server or the ContentCenter web application to this URL.
Accessing Static Content

Static web content can be placed within the ContentCenter web application and accessed
by custom menu items by specifying its relative URL.
Example
In the customer_samples toolkit, an example corporate writing guide is provided. If

deployed into the customer toolkit, this content could be accessed from a custom link in
the action list on the top, right hand side of ContentCenter Standard by placing this entry
in ui_custom.xml:
<iwov-ui>
<action-list id="iw.ccstd.common.actions_top.actionlist">
<link id="cu.customer.writing_guide.link"
label="Writing Guide"
description="Writing Guide"
url="/customer/style_guide/writing_guide/index.html"
target="_blank">
</link>
</action-list>
</iwov-ui>
Accessing Web Pages outside ContentCenter

A web page outside of the ContentCenter web application can be accessed by custom
menu items by specifying its absolute URL.
Example
To access Interwoven’s developer site, DevNet, from a custom link in the action list on
the top, right hand side of ContentCenter Standard, place this entry in ui_custom.xml:
<iwov-ui>
Interwoven, Inc. 92
<action-list id="iw.ccstd.common.actions_top.actionlist">
<link id="cu.devNet.absolute.link"
label="DevNet"
description="Interwoven Developer Site"
url="http://devnet.interwoven.com"
target="_blank"
addPropertiesToUrl="false">
</link>
</action-list>
</iwov-ui>
The addPropertiesToUrl attribute, when set to false, specifies that the vpaths
normally supplied as parameters to the url (as described in the next section) should not
be sent. The default value is true, so this attribute can be omitted when these
parameters are desired.
Accessing CGIs from ContentCenter

A CGI located in iw-home/httpd/iw-bin can be accessed by custom menu items.
When invoked, all files that the user has currently selected in the invoking GUI will, by
default, be passed as TeamSite vpath parameters to the CGI in an array.
If the user has selected no files and the script is being invoked from ContentCenter
Professional, then the user’s current directory is passed as a vpath parameter.
A vpath is a path within the TeamSite content repository, as described in “Specifying

VPaths” in Chapter 9, “Using URL Commands,” except that each vpath passed by
ContentCenter has its server hostname prepended to it as //server.
NOTE
This is a change in behavior from how CGIs were passed parameters from previous
Interwoven GUIs. See the discussion in “Custom Menu Items” in Appendix B,
“Migrating Existing Customizations” on migrating existing CGIs forward or using an
Interwoven-supplied adapter script to invoke them.
Other custom parameters can be passed to the target CGI as well, except for parameters
already used by either wdpro_menu.ipl or iw_cgi_wrapper.cpp. This includes vpath,
arid, brid, dirid, waid, cwd.vpath, done_page, full_redirect, and iw_locale. If
more than two custom parameters are passed, this must be done using valid XML and
escaping the & in the url attribute of the link element.
Example
To access a custom reporting CGI from the ContentCenter Professional View menu,
place this entry in ui_custom.xml:
<iwov-ui>

<menu id="iw.ccpro.view.menu">
<link id="cu.report_menu_item.link"
label="Prepare Report"
description="Month"
url="/iw-bin/report.cgi"
target="_blank"
operationID="cu.ccpro.prepare_report.op">
</link>
</menu>
</action-list>
</iwov-ui>
Accessing Custom Java Code from ContentCenter

To access custom Java code servlets from the ContentCenter web application, modify
the standard J2EE deployment descriptor file, web.xml, as described in “Editing the
Deployment Descriptor” in Chapter 8, “Adding Custom Java Code,” and use the URL
specified there in the custom menu item link.
To access custom JSPs that do not include Java code, specify their location relative to
the deployed ContentCenter web application. Do not modify the deployment
description file, web.xml.
As described in the previous section, when a link is invoked, all files that the user has
currently selected in the invoking GUI (or, if no files are selected, the current directory
from ContentCenter Professional) will, by default, be passed as TeamSite vpath
parameters to the custom Java code. The custom code can then treat them as an array of
strings which it can pass to ContentServices for TeamSite to obtain the corresponding
CSSimpleFile objects.
Example
To access a servlet that displays the TeamSite Workflow tasks associated with a file
from the ContentCenter Standard File Browser’s file action dropdown menu, modify
web.xml and place this entry in ui_custom.xml:
<iwov-ui>
<action-list id="iw.ccstd.list_directory.file_list.actionlist">
<menu id="iw.ccstd.list_directory.file_actions.menu">
<link id="cu.tasks_for_file"
label="custom.menu.tasks_for_file"
description="custom.menu.tasks_for_file"
url="/showtasksforfile"
target="_blank">
</link>
</menu>
</action-list>
</iwov-ui>
Interwoven, Inc. 94
The URL /showtasksforfile should match the URL specified in web.xml for this servlet.
Restricting Custom Links by TeamSite Role

If the attribute operationID is specified in a link, then that link can be restricted by
TeamSite role by defining it in the file custom_userops.xml as an operation element,
with an id equal to the operationID.
NOTE
Only links to non-Interwoven-supplied functionality can be restricted by role. Custom
links to refid elements cannot be restricted by role.
Entering an operation in this file will, after the ContentCenter web application is rebuilt,
result in it being listed, by the value of its display-name attribute, as an item within the
TeamSite role category “Custom User Operations” displayed in the TeamSite
Administration Edit Role screen.
Its access to TeamSite users will then be automatically permitted or restricted,

depending on the permissions of the branch in which the operation is being attempted
and role permissions set for the “Custom User Operations” category, just as standard
TeamSite operations (as specified by their respective categories’ role permissions) are
automatically permitted or restricted.
Example (continued)
To automatically restrict the custom reporting link described two examples ago (which
defined cu.ccpro.prepare_report.op as an OperationID), place this entry in
custom_userops.xml:
<custom-operations>
<operation description="custom_report_menu_item"
display-name="report_menu_item"
id="cu.ccpro.prepare_report.op"/>
</custom-operations>
Adding Custom Tabs

Custom tabs can be created in ContentCenter Professional to access web pages and
custom code in a manner very similar to custom menu items, displaying the results
within the tab frame.
Example
To add three custom tabs to ContentCenter Professional to access:

A web site outside the web application,

A custom servlet specified in a web.xml deployment descriptor file,
A static HTML web page within the ContentCenter web application,
place the following entry in ui_custom.xml:

<iwov-ui>
<tabset id="iw.ccpro.common.tabset">
<tab id="cu.devnet.tab"
label="DevNet"
url="http://devnet.interwoven.com"
target="_top">
</tab>
<tab id="cu.show_user.tab"
label="Current User"
url="/showcurrentuser"
target="_top">
</tab>
<tab id="cu.writing_guide.tab"
label="Writing Guide"
url="/customer_samples/style_guide/writing_guide/index.html"
target="_top">
</tab>
</tabset>
</iwov-ui>
Restricting Custom Tabs by TeamSite Role

Custom tabs that access non-Interwoven-supplied functionality can be restricted by role
in a manner similar to custom links as described in “Restricting Custom Links by
TeamSite Role” on page 95. To do so, specify an operationID attribute in the custom
tab element definition and then place the appropriate entries for all roles in
custom_userops.xml.
Adding Custom Portlets

ContentCenter Standard portlets differ from other UITK GUI elements in that they are
attached internally to the ContentCenter home page using a Java include. (This is also
true for wizard topic help questions, which are attached to ContentCenter Standard’s
wizards with a Java include.)
A a result, a portlet element’s url attribute cannot be a URL to:

An HTML page.
A servlet or JSP that outputs HTML with HTML, HEAD, or BODY tags.
A servlet the performs a forward or redirect.
Interwoven, Inc. 96
Within these limits, a portlet can access static web content or external web pages
through a JSP or servlet.
Example
To create a portlet that displays a corporate style guide located within the ContentCenter
web application, place the following entry in portal_custom.xml:
<iwov-portal>
<portlet id="cu.style_guide.portlet"
label="Corporate Style Guide"
url="/customer/style_guide/index.jsp">
<title-bar id="titlebar" type="standard">
</title-bar>
</portlet>
</portlet-group>
</portal-page>
</iwov-portal>
NOTE
The specified URL goes to an index.jsp, not an index.html page.
Example
To create a portlet that displays a web page outside the ContentCenter web application,
such as Interwoven’s Developer Network, place the following entry in
portal_custom.xml:
<iwov-portal>
<portlet id="cu.devNet.portlet"
url="/customer/iwov_devnet.jsp">
<title-bar id="titlebar" type="custom">
</title-bar>
</portlet>
</portlet-group>
</portal-page>
</iwov-portal>
The file iwov_devnet.jsp is a JSP “snippet” that invokes the desired URL:
<iframe name="devnet"
id="devnet"
src="http://devnet.interwoven.com"
width="100%"
height="620"
border=0

frameborder=0
scrolling="yes">
</iframe>
Example
To create a portlet that invokes a Java servlet, modify the web.xml deployment
description file and place the following entry in portal_custom.xml:
<iwov-portal>
<portlet id="cu.show_current_user.portlet"
label="Who am I Logged in as?"
url="/showcurrentuser">
<title-bar id="titlebar" type="standard">
</title-bar>
</portlet>
</portlet-group>
</portal-page>
</iwov-portal>
Interwoven, Inc. 98
Chapter 8
Adding Custom Java Code
This chapter describes how to add custom Java code to the ContentCenter web
application and to access the services provided by the ContentServices SDK from within
such code.
Overview
Developers can add custom Java code to the ContentCenter web application by
deploying their compiled output and supporting files into the customer toolkit, editing
the customer toolkit web.xml deployment descriptor (an XML configuration file), and
then rebuilding the ContentCenter web application.
Rebuilding the ContentCenter web application merges these customer deployed files
with Interwoven’s own deployed files (from the other Interwoven toolkits) to produce
the ContentCenter web application. This permits customer supplied code to be
preserved across future releases, in the customer toolkit, as Interwoven’s own internal
toolkits evolve.
Placing custom Java code within the ContentCenter web application permits it:
To access the same instance of the ContentServices SDK accessed by the
ContentCenter GUIs (without having to instantiate a separate CSClient object),
making use of ContentCenter’s internal authentication mechanism.
To be invoked, manipulated, and accessed as a ContentCenter GUI element, either
as a custom menu item, a ContentCenter Standard custom portlet, or a
ContentCenter Professional custom tab.
Alternatively, custom Java code can exist in its own web application, completely
separate from the ContentCenter web application. It can still be invoked by a
ContentCenter custom menu item or tab (but not a ContentCenter Standard custom
portlet), though less efficiently as this external request is now crossing web applications.
Such a web application could have its own separate version of the ContentServices
SDK, which it would have to instantiate, using the CSJavaFactory object, and do its
own authentication within, as described in the ContentServices SDK documentation. It
would also need to explicitly import the ContentServices Java libraries, located in
iw-home/cssdk/java, and it would be unable to access any ContentCenter functionality
except through externally visible ContentCenter URLs (and, again, crossing web
application boundaries with these requests).

Chapter 8: Adding Custom Java Code
NOTE
For TeamSite 6.7.1 Service Pack 1, java programs in a separate web application from
the ContentCenter web application will also need to import cssdkiface.jar, located in
iw-home/cssdk.
Place custom Java code accessed from within ContentCenter GUIs within the
ContentCenter web application, unless there is a good reason not to do so.
The remainder of this chapter discusses different code deployment options, the
deployment descriptor XML file, how to invoke custom Java code from within
ContentCenter, and how to access the ContentServices SDK from within custom code
deployed in the ContentCenter web application.
Custom Code Deployment

The ContentCenter web application is laid out in standard J2EE format. Custom code
developers work from within iw-home/local/config/lib/content_center/customer_src.
Custom code output will be placed by make_toolkit.ipl in the customer_out directory

and includes the various custom XML configuration files, in addition to .jar files.
If multiple developers are making changes to code and configurations on the same
server, they will need to coordinate their changes so that they do not overwrite each
other’s customizations.
Use a source control mechanism when there are multiple custom code developers or
designers.
Within the customer_src directory is a set of empty Java development directories (src,
lib, etc, web), laid out for custom code development within the ContentCenter web
application.
NOTE
The src directory is empty. You will need to add subdirectories, such as the standard
com/corporatation-name/product-name directories. Code samples in the
customer_sample_src directory are under src/com/corp/custom.
The Ant build script used by make_toolkit.ipl is build.xml, located in the reference
directory (top level). It should be robust enough to handle most source file
organizations in customer_src without having to be modified.
Interwoven, Inc. 100

Third Party Software

Deploying custom Java code within the ContentCenter web application requires the
using the same versions of the third party libraries and servers, such as the Java JDK and
the Apache Tomcat application server, as used by the ContentCenter web application.
Replacing libraries in the ContentCenter web application with later versions is not
supported and, most likely, will prevent the ContentCenter web application from
rebuilding properly. Do not do this.
TeamSite 6.1 uses several third party servers and libraries:

Apache Tomcat Application Server, version 4.1.24.
Java Virtual Machine/Java Development Kit, version 1.3.1_07.
Xerces XML Parser, version 2.5.0.
Xalan XSL Style Sheet Processor, version 2.2D6.
The following third party .jar files should not be placed in customer_src/lib. The
versions deployed within the ContentCenter web application are given:
commons-beanutils.jar (version 1.4.1)
commons-collections.jar (version 1.1)
commons-digester.jar (version 1.3iw1)
commons-logging.jar (version 1.0.1)
jakarta-oro.jar (version 2.0.6)
log4j.jar (version 1.2.5)
jakarta-regexp-1.2.jar (version 1.2)
regex.jar (version 1.1)
standard.jar (version 1.0.3)
Editing the Deployment Descriptor

In addition to deploying the custom code output files, the standard J2EE deployment
descriptor file, web.xml, located in:
iw-home/local/config/lib/content_center/customer_src/etc
must be edited for each custom code servlet you create.
Three entries must be added:

A filter mapping entry, enabling the servlet to be authenticated within the
A servlet entry, associating the servlet with its Java class.

A servlet mapping entry, associating the servlet with the URL which invokes it.
NOTE
An authentication filter mapping entry is needed only for servlets, not JSPs.
Example
<web-app>
<filter-mapping>
<filter-name>authentication</filter-name>
<servlet-name>custom1</servlet-name>
</filter-mapping>
<servlet>
<servlet-class>com.corp.custom.custom1</servlet-class>
</servlet>
<servlet-mapping>
<url-pattern>showcustom1</url-pattern>
</servlet-mapping>
</web-app>
Additional servlet mapping entries may be added if more than one URL is going to
invoke a given custom servlet.
The web.xml file, while located separately from the other XML configuration files, should
also be managed by a source control mechanism.
NOTE
The file webapp.ver, also located in this directory, is needed to rebuild the
ContentCenter web application. Do not edit or remove it.
Invoking Custom Code

The URL listed in the web.xml URL pattern entry for a given servlet is what appears in the
url parameter within a given link entry (for a custom menu item) or tab entry (for a
custom tab) in the file ui_custom.xml or within a portlet entry (for a custom portlet)
in the file portal.xml, as described in Chapter 7, “Extending GUI Functionality.”
Example
<portlet id="custom1"
label="custom.portlet.iwov_servlet_current_user.title"
url="/showcustom1">
<title-bar id="titlebar" type="standard"/>
</portlet>

Code Development
To add custom Java code to the ContentCenter web application, you need to:
1. Write your custom code (including servlet code, JSPs, HTML pages, images, and so
on).
2. Attach it to the ContentCenter GUIs, by adding custom menu item, portlet, or tab
entries to the relevant ContentCenter .xml configuration files and editing web.xml
within the customer_src directories).
3. Compile your code and deploy all the relevant output (including JSPs, HTML pages,
images, and updated XML configuration files) to the customer_out directories and
rebuild the ContentCenter web application, typically by running make_toolkit.ipl.
4. Test your custom code.
Servlets or JSPs?
Custom Java code can be written as JSPs, servlets, or a combination of both.
JSPs embed Java requests in HTML, which lends itself to coding data presentation and
user interaction.
Servlets emit HTML output from Java code, which lends itself to coding control
flow.
In either case, combining presentation logic (displaying web pages) together with
control and data handling logic can lead to source code that is hard to debug and
maintain.
One approach, for anything but the simplest of programs, is to separate these two
functions, placing the main control logic in a servlet that then dispatches presentation
requests to JSPs. This approach is used in the three custom servlets provided in the
customer_samples toolkit.
If a program is not making any requests to the server, as in the corporate style guide
example in the customer_samples toolkit, then use only a JSP.
Including CSS files

While custom portlets will always use ContentCenter Standard styles (plus custom
styles specified in the base or ccstd custom.css files), other custom JSPs will need to
explicitly include their css files.
It is not possible for custom JSPs to determine, at runtime, which ContentCenter user
interface has invoked them to determine which css style sheets to include. If
dramatically different styles are being used in each ContentCenter GUI and consistency
with these styles is important within custom JSPs, separate versions of custom JSPs, to

be invoked by the different ContentCenter GUIs, should be defined that include

different css files
Accessing ContentServices SDK

To access the Java ContentServices SDK from within ContentCenter custom Java code
(either a servlet or JSP), obtain an object of type CSClient to use in ContentServices
methods, as shown by the following:
Example
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
CSClient client = (CSClient) request.getAttribute("iw.csclient");
if (!client.isValid())
throw new ServletException("No valid user");
...
}
HTML Links within ContentCenter Custom Code

HTML links created by a JSP or servlet can be relative to that page, though it is
recommended that they follow the same rules as for JSP “snippets”, such as
ContentCenter portlets, that get attached by a Java include.
JSP snippets are not complete pages and cannot assume anything about the URL they
are being rendered under. Instead, they should build links dynamically by concatenating
the current context path with a path specified relative to the ContentCenter web
application.
From a JSP using embedded Java:

<% request.getContextPath() + "/relativepath" %>
From a Java servlet:

request.getContextPath() + "/relativepath"
Alternatively, the path can be built in Javascript, using Javascript to extract the context.
Be especially careful to avoid specifying URLs relative to a given application server as

this can possibly lead to authorization problems (when the “logical” application server
is really several servers and the particular server the user who is invoking this code is
authorized against is different than the server specified within the code).

Specify all HTML references to ContentCenter files (property files, images, and so on),
JSPs, and Servlets relative to the ContentCenter web application, not the current URL.
Accessing ContentCenter Functionality

Custom code can use URL commands to invoke ContentCenter functionality as
described in Chapter 9, “Using URL Commands.” A sample Java mail notification class
invoked by a URL command is provided in the customer samples toolkit and described
in “Customizing the UrlExternalTask Command to Send Email” on page 129.
Custom code can use ContentServices calls to obtain data which is then passed as
parameters when invoking ContentCenter functionality with a URL command .
For an example of this, see the “Show Tasks for File” servlet in the customer_samples
toolkit. It displays a list of tasks associated with a file—obtained from ContentServices
SDK objects—as HTML links. If a task is selected, the ContentCenter Task Details screen
for it is displayed. Here is a portion of the presentation JSP that generates this list of
task links:
Example
<%
int[] taskIds = file.getRelatedTaskIds();
CSTask[] tasks = client.getWorkflowEngine().getTasks(taskIds);
if (tasks == null)
tasks = new CSTask[0];
for(int i = 0; i < tasks.length; i++) {

String taskUrl = "/iw-cc/viewtaskdetails?taskid=" +
tasks[i].getId();
%>
<tr>
<td><a href="<%= taskUrl %>"><%= tasks[i].getId() %></a></td>
<td><%= tasks[i].getDescription() %></td>
<td><%= tasks[i].getOwner() %></td>
</tr>
<%
} // end for loop of task list
%>
NOTE
An improvement would be to build up the viewtaskdetails URL dynamically (as
discussed in the previous section), instead of hard coding the ContentCenter web
application name, /iw-cc, within it:

String taskUrl = request.getContextPath() +

"/viewtaskdetails?taskid=" +
tasks[i].getId();
Logging Services
The ContentCenter web application uses the third party Apache log4j classes. These
classes are available to custom code developers. In TeamSite versions 6.7.1+, the
logging jar files are located in iw-home/servletd/common/lib.
Users can add a log4j appender to debug their custom Java code. To enable this
debugging feature, define loggers in log4j.xml located in
iw-home/local/config/lib/content_center/customer_src/etc/conf/customer.
Example
<appender name="CUSTOM" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="${log100.iwlogs}/iwui/custom.log"/>
<param name="MaxFileSize" value="100MB"/>
<param name="MaxBackupIndex" value="10"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %c (%x) - %m%n"/>
</layout>
</appender>
<logger name="com.mycompany.mypackage.*" additivity="false">
<level value="debug"/>
<appender-ref ref="CUSTOM"/>
</logger>
In the custom Java source codes, use:

private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class.getName());
...
LOGGER.debug("myVariable = " + myVariable);
...
The logs will be in iw-home/local/logs/iwui/custom.log.
Troubleshooting
When rebuilding the ContentCenter web application with custom code, it is possible that
the Apache Tomcat servlet container may experience problems (particularly if some
Interwoven-supplied output files were overwritten). Tomcat (installed with
Interwoven), unless configured differently during installation, writes to the following
log files:
iw-home/servletd/logs/localhost_log.date
iw-home/servletd/logs/catalina.out

NOTE
Under Unix, if the install is done in console mode—not through the Installer
GUI—these logs are created under /var/adm (bug 46253).
Errors such as nonexistent servlet references in web.xml or incorrect references in the

ContentCenter .xml configuration files can be found in either of these log files.
NOTE
The log file catalina.out is created only if Tomcat is started as a service from the
Windows Control Panel or from startup.sh under Linux.
If problems are encountered, remove the custom code output from the customer toolkit
and then rebuild the ContentCenter web application.


Chapter 9
Using URL Commands
This chapter describes how users can access ContentCenter functionality by invoking
URLs embedded in emails generated by TeamSite Workflow or from web pages
(including JSPs) located either inside or outside the ContentCenter web application.
URL Commands
URL Commands invoke portions of the ContentCenter functionality, displaying a
relevant portion of the GUI so that the user can then achieve a desired result.
For example, the URL command copy displays either ContentCenter Standard’s copy
wizard or ContentCenter Professional’s copy screen, prepopulated with the name of the
file to be copied and, if a destination was supplied, the directory in which to copy it.
The URL command does not do the copy. The user, after altering or adding any needed
information, performs the action by clicking, in this case, the Done button. The copy is
then performed and the wizard or screen is closed.
(Alternatively, the user could click Cancel or close the browser window displaying the
GUI element, in which case no copy would be performed.)
In almost all cases, URL Commands do not perform actions by themselves; they instead
serve as entry points into the ContentCenter web application which, in turn, displays a
GUI element that the user then interacts with to display information or to possibly
perform an action.
Some URL commands simply display information. For example, the viewdirectory URL
displays a directory’s contents in either ContentCenter Standard’s file browser or
ContentCenter Professional’s area navigation view. After viewing this information, the
user could simply close the browser window in which it was displayed.
In many cases, the GUI element displayed could either present information or result in
some action being taken, depending on how the user interacts with it. For example, the
properties URL displays a file’s properties. However, if the user owns that file or has
TeamSite Master or Administrator privileges, the user could then edit some of the
displayed fields.
Only authorized TeamSite users can access ContentCenter functionality. If a user

invokes a URL command and that user does not currently have a valid TeamSite session,
then the ContentCenter login screen will be displayed and the user will be prompted to

Chapter 9: Using URL Commands
login. After doing so, the URL command is then processed normally. If a user already
has a valid TeamSite session, then the ContentCenter login screen is not displayed.
In TeamSite releases prior to TeamSite 6.0, ten URL commands were exposed and
supported as the Casual Contributor Interface (CCI). With the ContentCenter GUIs, the
number of available URL commands is increased to over 50, with legacy support
provided for the older commands.
Using URL Commands within TeamSite Workflow

URL commands are HTML links, which can be embedded within emails, web pages, or
JSPs.
Their primary use is to be embedded as ordinary HTML links within emails generated by
TeamSite Workflow.
For example, a submit workflow might generate an email requesting approval of some
submitted content. The embedded links might allow the user to do one or more of the
following by clicking on them:
View the modified files.
Compare a file version submitted for approval against the existing (STAGING)
version.
Choose to approve or reject the submission.
Such workflows can be developed for companies where email is used for interacting
with automated business processes, instead of ContentCenter’s task and job displays.
At sites where ContentCenter’s task and job displays are used, URL commands can
augment these displays by providing email notification of pending tasks with an
embedded URL command link (viewtasklist) that, when clicked, takes the user to the
appropriate task list display or portlet with the actual review task displayed in the task
details section.
At sites where some users use ContentCenter heavily and others do not, workflows can
be designed for both types of users. For example, a submit-for-comment workflow
could be designed to send out an email with an embedded VisualAnnotate review URL to
occasional ContentCenter users (along with a vainstall URL for those users who do not
have the VisualAnnotate toolbar installed) and an ordinary task notification for the
regular ContentCenter users.
NOTE
In order to use a URL command, the user has to be a valid TeamSite user, even if that user
rarely, if ever, uses the ContentCenter GUIs.

The URL command syntax is given in this chapter. For information on writing TeamSite
workflows and sample workflows that generate emails, see the TeamSite Workflow
Developer’s Guide.
Other Uses
URL commands can also be used in other ways:
As custom entry points into the ContentCenter GUIs.
For example, a login URL command could be placed as a link on a company’s
intranet page.
As “quick edit” links for specific content edited by occasional ContentCenter users.
For example, a web page consisting of paired edit and submit URLs for specific
Human Resources web documents (such as holiday schedules, building hours,
payroll reporting deadlines, the company policy manual, and so on) could be
designed to facilitate easy updating of this material on the company’s Web site.
To customize ContentCenter Standard’s functionality by adding a URL command,
either statically or dynamically.
For example, if it is desirable to expose the Local File Manager’s capability to
associate file extensions with editing applications for “advanced” ContentCenter
Standard users (who wished to customize which editing application would appear
when they clicked Edit), a custom help item could be added. This help would
include the (static) URL command localfilemgrsetup—which users could click on
to invoke the Local File Manager’s setup screen—along with an explanation of how
to make these associations.
For an example of how to build a URL command dynamically within a JSP, see
“HTML Links within ContentCenter Custom Code” in Chapter 8, “Adding Custom
Java Code.”
To enable access to ContentCenter functionality for ContentServices SDK
applications.
ContentServices SDK code running in another web application (such as a Portal
integration) can use URL commands to access some ContentCenter functionality,
such as the various file comparison screens, if this is desirable.
URL Command Format

The ContentCenter URLs presented below are divided into three main groups (plus the
legacy URLs):
General commands, such as login, logout, or vainstall.
File commands, such as compare, copy, or viewmodifiedfiles, including the search
commands (which return files).

Workflow commands, such as addtaskcomment, transitiontask, or viewjoblist.
(This grouping is somewhat arbitrary because some file related commands, such as
submit, interact strongly with TeamSite Workflow.)
Each command description lists the ContentCenter GUIs applicable to it, the GUI
element that is displayed when it is invoked, and what parameters it can take.
URL commands have the following format:

http://hostname/iw-cc/command-name?parameter1=value1&parameter2=value2...
NOTE
The HTTPS protocol and port number can be used instead of http://hostname, just as
with the normal ContentCenter login.
Some URL commands have required or optional parameters. Optional parameters are
listed in the command descriptions in italics. Some parameters (such as done_page) are
discussed in more detail following the URL command tables. Parameters can be given
in any order.
NOTE
Some undocumented internal parameters may be visible in URL commands used by the
ContentCenter GUIs themselves. Do not use these parameters. They are unsupported
for customer use, though they may be exposed in a future release.
When supplying multiple parameters of the same type (such as 1+ files to download),
list each parameter as a name=value pair.
Example
http://server1/iw-cc/download?vpath=default/main/WORKAREA/wa/file1.html&
vpath=default/main/WORKAREA/wa/file2.html
Additional Parameters
In addition to the parameters listed in the tables, all non-legacy URL commands can take
two other optional parameters:
iw_which_ui, specifying which ContentCenter GUI (Standard or Professional) the
user should be logged in under.
When a user who is not already logged into a ContentCenter GUI invokes a URL
command, the user is presented with the login screen. This screen includes a “drop
down” that allows the user to choose which GUI to access. If this parameter is set,
this drop down is not presented and the user, after being authenticated, will be
logged into the indicated ContentCenter GUI, either Standard (if set to ccstd) or
Professional (if set to ccpro).

This parameter is intended to apply only at login. It should not be used to jump
from one ContentCenter GUI to another (even to access functionality not available
in the current ContentCenter GUI), except when using the switchui URL
command. Attempts to do this when using other URL commands may result in an
error.
iw_sessionstring, which passes in a ContentServices SDK session string so that a
user already authenticated outside of ContentCenter (through ContentServices) is
not presented with the ContentCenter login screen upon the URL being invoked.
This parameter is not needed if the user is already logged into ContentCenter.
When building a URL command within ContentServices, the session string can be
obtained from the CSClient object as follows:
url += "&iw_sessionstring=" +
csclient.getContext().getSessionString();
Specifying VPaths
A vpath (“version path”) is a path within the TeamSite content repository, specified as
one of the following:
/store/branch+/EDITION/edition
/store/branch+/WORKAREA/area/directory*/file
/store/branch+/STAGING/directory*/file
where “+” indicates 1 or more; * indicates 0 or more, and a path may omit the elements
below it in order to specify just a directory, area, branch, or store.
A branch may not be named EDITION, WORKAREA, or STAGING. STAGING is a special area
that every branch has. Thus, a URL command parameter that is an area requires either a
workarea (specified as WORKAREA/workareaname) or STAGING.
The following are all valid vpath specifications:

/default, a store.
/default/main, the branch main.
/default/main/pubs, the branch pubs.
/default/main/pubs/EDITION/initial, the edition initial.
/default/main/pubs/STAGING, the STAGING area for the pubs branch.
/default/main/pubs/WORKAREA/uitk, the workarea uitk.
/default/main/pubs/WORKAREA/uitk/guide/examples, a directory.
/default/main/pubs/WORKAREA/uitk/guide/examples/example1, a file.
/default/main/pubs/WORKAREA/uitk/README, a file directly under a workarea.
The path delimiter can be either “/” or “\” when specifying a TeamSite path, but will be
output as: “/” (Unix) or “\” (Windows).

Optionally, a vpath can include the server name by prepending //servername to it,
though doing so is generally not needed.
CAUTION
Browser limitations on the maximum length of their internal URL operations (which vary
from browser to browser, but are typically around 2000 bytes) place a maximum length
on the size of URL commands. Internal ContentCenter GUI operations rarely involve
more than threevfully specified vpath arguments at a time; thus, the recommended
maximum length for a vpath (a consideration when laying out directories and content in
the TeamSite ContentStore) is 600 bytes, as discussed in the TeamSite Administration
Guide. Since some URL commands (such as the advanced search URL command) can
have more than three vpath arguments, very long vpath names can potentially result in
errors when issuing URL commands with more than three arguments.
For more information on specifying a vpath, see the TeamSite Command-Line Tools
manual.
Role Restrictions
Some URL Commands access functionality which is not accessible to all TeamSite
users based on the role they are currently logged in. URL Commands respect the same
role restrictions as described in the TeamSite Administration Guide for specific TeamSite
functionality.

General URL Commands

Table 5 General URL Commands
CC CC
URL Name GUI Element Displayed Parameters
S P
ccpro Y Y ContentCenter Professional home -
page.
ccstd Y Y ContentCenter Standard home -
page.
localfilemgrsetup Y Y Local File Manager setup screen, -
so user can associate file
extensions with applications (for
editing).
login Y Y Login screen. -
logout Y Y Login screen. -
switchui Y Y The home page of the specified iw_which_ui: the GUI to switch to
ContentCenter GUI. (see “Additional Parameters”
above).
vainstall Y Y Visual Annotate client-side install -
dialog.
vfinstall Y Y Visual Format client-side install -
dialog.
viewmycc Y - ContentCenter Standard home -
page.
viewmyfavorites Y Y My favorites component/view. -
File URL Commands

Italicized parameteres are optional.
Table 6 File URL Commands

CC CC GUI Element Displayed
URL Name Parameters
S P
advancedsearch Y Y Advanced search page vpath: the TeamSite area to search in or
(CCP) the 1+ files and directories, all in
the same area, to search.
any_words: a set of space delimited
keywords to prepopulate the “any
words” search criteria field in the
advanced search page.


CC CC
S P
compare - Y Compare screen. vpath: 1+ files in the same area to
compare.
other.vpath: area with files to compare
against (default: STAGING).
done_page: the URL or URI of the page
to go to after this operation is complete.
If this parameter is omitted, the browser
window will instead be closed.
convert Y Y Convert a Document wizard vpath: file to convert (CCS); 1+ files to
(CCS) or Conversion convert, all is the same workarea (CCP).
Selection screen (CCP). done_page: the URL or URI of the page
copy Y Y Copy wizard/screen. vpath: file to copy (CCS); 1+ files and/or
directories to copy (CCP).
dest.vpath: directory to populate
screen.
delete Y Y Delete wizard/confirmation vpath: file to delete (CCS); 1+ files or 1
dialog. directory to delete (CCP).
download - Y My local files view. vpath: 1+ files to download.
edit Y Y Appropriate edit wizard/my vpath: file to edit.
local files view with the file done_page: the URL or URI of the page
opened in native to go to after this operation is complete.
application. If this parameter is omitted, the browser
editwith - Y My local files view with the vpath: file to edit.
choose application dialog done_page: the URL or URI of the page
open. to go to after this operation is complete.


CC CC
S P
getlatest - Y Get latest screen. vpath: 1+ files, directories, and/or
workareas to get the latest versions of.
overwrite: preselected conflict behavior
to display, either true (to ignore conflicts
and overwrite) or false (report
conflicts).
import Y Y Import wizard/My Local vpath: destination directory or workarea
Files screen. to place the imported file(s).
move Y Y Move wizard/screen. vpath: file to move (CCS); 1+ files
and/or directories to move (CCP).
dest.vpath: directory to populate
screen.
newdirectory Y Y New folder screen. vpath: parent directory in which to create
the new directory.
newfile - Y New file templates screen. vpath: parent directory in which to create
the new file.
newform Y Y Form entry window, if the vpath: the blank form to display,
form was specified; specified as a form or generated asset of
otherwise the choose new that type within a workarea, or the
form screen. workarea in which to create the form.
iw_tdt: the blank form to display,
specified as category/type.


CC CC
S P
previewfile Y Y Virtualized view of the vpath: file to preview.
specified file with the
VisualPreview toolbar
displayed.
properties Y Y Appropriate properties vpath: the file properties to display
screen. If the user owns the (CCS); the file, directory, area, edition,
specified item (or has branch, or store properties to display
Master or Administrator (CCP).
role), some fields may be done_page: the URL or URI of the page
editable. to go to after this operation is complete.
rename Y Y Rename screen. vpath: file to rename (CCS); file or
directory to rename (CCP).
name: new name to populate screen.
review Y Y Virtualized view of the vpath: the file to annotate (or the most
specified file (or review recent or first review snapshot of this file
snapshot of that file) with instead, depending on the current state of
the VisualAnnotate bar the VisualAnnotate review process and
activated. VisualAnnotate’s workflow
configuration).
snapshotid: the id (such as “3”) of the
VisualAnnotate review snapshot of the
file to view and, possibly, further
annotate.
taskid: the task whose attached files are
to be annotated. If not set and the file is
attached to multiple tasks belonging to
this user, then a task chooser dialog
appears.
search Y Y Search results page vpath:the TeamSite area to search in. In
CCP this vpath must be followed by the
parameter scope="area"
any_words: a set of space delimited
keywords to search on.
sourcediff - Y Source differences screen vpath: the file whose source to compare;
or, if the files are in conflict, if merged, the results are saved to this
the merge tool. file.
other.vpath: the area with the file to
compare against (default: STAGING).


CC CC
S P
submit Y Y Submit wizard/workflow vpath: the 1+ files and/or directories to
chooser screen, to choose submit.
the submit workflow iw_template_file: the submit workflow
template to use or, if template to use, specified as a file
iw_template_file is set,
relative to iw-home/local/config/wft.
the specified workflow’s
screen. iw_template_name: text to display as the
workflow screen title (default:
description in
available_templates.cfg).
Note: the submit operation may append a
query string to this URL; therefore, the
specified page must be able to function
with extra parameters. If this parameter
is omitted, the browser window will
instead be closed.
tag Y Y Metadata capture vpath: the 1+ files whose metadata is to
wizard/screen. be captured.
undo Y Y Undo changes dialog. vpath: the file whose changes are to be
undone.
upload - Y My local files view. vpath: the 1+ files to upload.
versions Y Y File versions screen. If the vpath: the file whose versions are to be
user owns the file (or has displayed.
Master or Adminstrator done_page: the URL or URI of the page
role), then the file may be to go to after this operation is complete.
reverted to an older version. If this parameter is omitted, the browser
viewdiff Y Y Visual differences screen. vpath: the file whose visual differences
to display.
other.vpath: the area with the file to
display against (default: STAGING)
(CCP).


CC CC
S P
viewdirectory Y Y directory listing/area vpath: the directory to view (CCS); the
navigation view. directory, area, store, branch, or edition
to view (CCP).
viewlocked - Y Locked files view. vpath: the directory or workarea whose
locked files will be displayed.
viewmodified - Y Modified files view. vpath: the directory or workarea whose
modified files will be displayed.
viewmylocal - Y My local files view. -
viewmylocked - Y My locked files view. vpath: the directory or workarea whose
files locked by the user will be displayed.
viewmymodified Y Y Work in progress vpath: the workarea whose files
component/my modified modified by the user will be displayed
files view. (CCS); the directory or workarea whose
files modified by the user will be
displayed (CCP).
viewmyworkareas Y Y Content component/my -
workareas view.
Workflow URL Commands

Italicized parameters are optional.
Table 7 Workflow URL Commands

CC CC
S P
addnewfiletotask - Y Attach new file screen. taskid: the task to attach 1 newly
created workarea file to.
done_page: the URL or URI of the
page to go to after this operation is
complete. If this parameter is
omitted, the browser window will
instead be closed.


CC CC
S P
addnewformtotask Y Y New form entry screen, taskid: the task to attach the new
if the form is specified; form to.
otherwise the choose vpath: the blank form to display,
new form screen. specified as a form or generated asset
of that type within a workarea, or the
workarea in which to create the form.
iw_tdt: the blank form to display,
specified as category/type.
instead be closed.
addtaskcomment Y Y Task details screen. taskid: the task to add comments to.
instead be closed.
assign Y Y Assign wizard/workflow vpath: the 1+ files to attach to this
chooser screen, to job.
choose the assignment iw_template_file: the workflow
workflow template to template file to use, specified relative
use or, if to iw-home/local/config/wft.
iw_template_file is
set, the specified iw_template_name: text to display as
workflow’s screen. the workflow screen title (default:
description in
complete. Note: the assign operation
may append a query string to this
URL; therefore, the specified page
must be able to function with extra
parameters. If this parameter is
instead be closed.
attachexistingfiletotask Y Y Attach files screen, taskid: the task to attach 1+ workarea
showing all files. files to.
instead be closed.


CC CC
S P
attachmodifiedfiletotask Y Y Attach files screen, taskid: the task to attach 1+ modified
showing modified files. workarea files to.
instead be closed.
converttask - Y Document Conversion
Selection screen
(showing all MS Word
documents currently
attached to the
workflow invoking this
command as a CGI task
with its readonly flag
set to f).
importfiletotask Y Y Import and attach taskid: the task to attach the 1+
dialog. imported files to.
instead be closed.
newjob Y Y Workflow chooser vpath: the 1+ files and/or directories
screen, to select the or the workarea whose content is to be
workflow template to associated with this job.
use or, if iw_template_file: the workflow
iw_template_file is
template file to use, specified relative
set, the specified to iw-home/local/config/wft.
workflow’s screen.
iw_template_name: text to display as
the workflow screen title (default:
description in
complete. Note: the newjob operation
may append a query string to this
URL; therefore, the specified page
must be able to function with extra
parameters. If this parameter is
instead be closed.
resolveconflicts - Y File compare/merge taskid: the conflict task.
screen. done_page: the URL or URI of the
instead be closed.


CC CC
S P
taketask Y Y Task details screen. taskid: the group task which the user
wishes to take ownership of.
instead be closed.
taskfilecomment Y Y Task file comment taskid: the task with the attached file
screen. whose comments are to be edited.
vpath: the file whose comments are to
be edited.
instead be closed.
transitiontask Y Y Task transition dialog. taskid: the task that the user wishes
to transition.
cgi_transition: transition the
specified task, which must be a CGI
task, either starting it (false) or
forcing the next transition of an
already started CGI task (true). If
unspecified, the default is
cgi_transition=false.
instead be closed.
vatransition Y Y VisualAnnotate review taskid: the VisualAnnotate task being
summary screen transitioned.
showing either all the transition: the workflow transition
attached files to be to take or the value of either the
transitioned or, if vpath va_approve or va_reject variables
is set, the one file to be (the first/second “stamps” displayed).
transitioned.
vpath: the attached file to apply the
transition to, instead of the entire task.
instead be closed.


CC CC
S P
viewarea Y Y Folder Browser (CCS vpath: the area to be displayed.
with browse set) or a
virtualized view of the
specified area with the
VisualPreview toolbar
displayed (CCS with
preview set or CCP).
To set this CCS
application parameter,
see “Configuring
ContentCenter Standard
Workarea Names” on
page 74.
viewjobdetails - Y Job details screen. jobid: the job to view details of.
viewjoblist - Y Job list screen. jobid: the job whose details should be
shown in the lower pane. If not
specified, the first job in the list is
displayed.
viewtaskdetails Y Y Task details screen. taskid: the task to view details of.
show_comments: specifies whether all
(true) or only the most recent (false)
task comment(s) should be displayed
(default: false, most recent only).
instead be closed.
viewtasklist Y Y Tasks component/task taskid: the task whose details should
list screen. be shown in the lower pane (CCP). If
not specified, the first task in the list is
displayed.
wffeedback Y - Wizard confirmation taskid: the task to display the
page. confirmation page for.
jobid: the job to display the
confirmation page for.
vpath: the list of files to display if no
valid taskid or jobid was passed in.
workflow_command: one of assign,
submit, new job, task_transition,
or tt_data, to display as the
confirmation page title (default:
“Operation Successful”).
instead be closed.


CC CC
S P
urlexternaltask Y Y None -- invokes a Classname: the name of the Java class
custom external task to be invoked.
target_task_name: the name of the
custom external task.
followed by a series of key-value
variable pairs to be passed to the
invoked Java class.
Legacy URL Commands

For backward compatibility, the previously available Casual Contributor Interface (CCI)
URLs now automatically forward to functionally equivalent ContentCenter Professional
URL commands.
Table 8 Legacy URL Commands

URL Name Behavior/Parameters
assign as described for CCP assign.
edit as described for CCP edit.
sce as described for CCP previewfile.
task as described for CCP viewtasklist.
tag as described for CCP tag.
newdcr as described for CCP newform.
filedetails as described for CCP properties.
visualdiff as described for CCP viewdiff.
transitiontask as described for CCP transitiontask.
taketask as described for CCP taketask.
New TeamSite Workflows or web pages should use the new URLs, not these ones. To
take advantage of the ContentCenter Standard Wizards, revise existing Workflows to
access the new URL commands, not these legacy ones.
Display Behavior
When a ContentCenter Standard component (portlet) is the GUI element displayed, the
ContentCenter Standard home page will be shown and scrolled so that the named
component is in view.

NOTE
If a component removed from the home page as a customization is to be displayed by a
URL command, then nothing is displayed. Do not write workflows that rely on URL
commands that display components and then remove these components from the home
page.
After URL Commands Complete

For the URL commands that can optionally specify a done_page parameter, when a user
completes an action, the browser window will display the specified page or close.
NOTE
The done_page parameter is not supported for URL commands that open pages with no
defined exit point (such as copy) or which automatically navigate to another page upon
the action being completed.
Customers can either supply custom done pages or use one of the Interwoven-supplied
done pages located in iw-home/httpd/webapps/content_center/teamsite/common:
close_window.html closes the current browser window. (This page is called by the
URL commands that accept a done_page parameter when none is supplied.)
refresh_parent_and_close_window.html looks in the current browser window for
a Javascript window.opener and tries to refresh it before closing the current
window.
When supplying these pages as a parameter, specify them relative to the server, such as:
done_page=/iw-cc/teamsite/common/close_window.html.
NOTE
Since these pages are used by the ContentCenter GUIs, do not modify these pages.
Custom done pages can be specified either absolutely or relative to the server (not the
ContentCenter web application), such as in the previous example. Custom code should
build a done page’s URL dynamically when specifying it relative to the server.
Browser Behavior and Workflow URL Commands

In previous versions of the UITK, if a URL command was generated by TeamSite
Workflow, the intended behavior (not true in all cases) was that a daughter window was
opened and then closed when the action is finished.

In TeamSite 6.1+, the optional done_page is provided for many URL commands in
order to give greater control over browser behavior to workflow developers. Workflow
CGI tasks may require special handling as described in the next section.
Workflow CGI Tasks and Done Pages

Every workflow CGI task invoked from ContentCenter is passed a done_page
parameter. This parameter can be passed on when the CGI task is either transitioned or
displays a feedback page, so that the appropriate browser window behavior occurs.
Alternatively, the CGI can substitute a custom done page for the done page passed in as
a parameter.
Transitioning Workflow CGI Tasks and Done Pages
To transition itself, a CGI should invoke the URL command transitiontask (instead
of using the old Perl callback methods as done in previous TeamSite GUIs), setting its
parameter cgi_transition to true, and passing in either the done_page parameter or a
custom done page. This can be done using either a GET or a POST method.
Examples
To transition a CGI task using the passed in done_page parameter using GET:
window.location = /iw-cc/transitiontask?taskid=$taskid&
cgi_transition=true&done_page=$donePage
To transition a CGI task using a custom done page using POST:

<form name="transitiontask" method="POST" action="/iw-cc/transitiontask">
<input type="hidden" name="taskid" value="$taskId">
<input type="hidden" name="cgi_transition" value="true">
<input type="hidden" name="done_page" value="customDonePage">
</form>
document.forms['transitiontask'].submit();
NOTE
If you are also passing in the optional comment parameter to transitiontask, the POST
method is recommended.
A detailed example illustrating a CGI transition can be found in:

iw-home/httpd/iw-bin/sample_cgi_task.ipl.
Cancelling Workflow CGI Tasks and Done Pages
If a CGI is simply aborting itself (due to a user clicking a Cancel button, say), the CGI
can go directly to either the passed in done page or a custom done page:
window.location=$donePage;

Displaying a Workflow Feedback Page from a CGI Task
If a CGI is completing and implicitly transitioning itself (instead of using the explicit
URL command transitiontask) and wishes to display a feedback page for
ContentCenter Standard users, then it should determine if it was invoked by
ContentCenter Standard and, if so, call the URL command wffeedback, passing in
either the done_page parameter that it received or a custom done page.
To determine which ContentCenter GUI called it, the CGI should examine the
JavaScript object window.opener. If its value is not null, then it was opened by
ContentCenter Professional and it can simply forward to the appropriate done page. If
its value is null, then it was opened from ContentCenter Standard and it should call
wffeedback.
Generally, the workflow job or task id is sufficient context for the ContentCenter
workflow feedback page to display any associated files. However, if the workflow CGI
task immediately precedes a TeamSite submit task, it is possible that this submit task
may complete before the feedback page is displayed, preventing the feedback page from
showing the files that were submitted. To prevent this, pass in the list of submitted files
as vpath parameters to the wffeedback URL command (using a POST method to do so
if many files are involved).
Example
Here is a code snippet illustrating this. It assumes that the submitted files are in an array
called vpaths.
print <<EOS;
<form name="feedbackform" method="POST" action="/iw-cc/wffeedback">
<input type="hidden" name="workflow_command" value="submit"/>
EOS
foreach my $vpath (@vpaths)

{
print "<input type=\"hidden\" name=\"vpath\" value=\"$vpath\">\n";
}
print "<input type=\"hidden\" name=\"done_page\" value=\"$donePage\">\n";
print <<EOS;
</form>
<script type="text/javascript">
try
{
var x = window.opener.name;
}
catch(e)
{
window.opener = null;

if (window.opener !=null && !window.opener.closed) {

//in CCPro, go to done_page
window.location = "$donePage";
} else {
//in CCStd, show workflow feedback page
document.forms['feedbackform'].submit();
}
</script>
EOS
Customizing the UrlExternalTask Command to Send Email

Sample Java code to invoke a custom external task to send email is provided in
customer_samples_src/src/com/corp/custom/MailNotificationTask.java within
the customer toolkit.
To demonstrate this capability as part of the customer samples tookit:

1. Edit the MAIL_SERVER and WEB_HOST values in MailNotificationTask.java
appropriately.
2. Build the customer samples toolkit as described in “Building the Customer Samples
Toolkit” on page 31.
3. Create a sample workflow using the following job specification:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE workflow SYSTEM "../iwwf.dtd">
<workflow name='sample_notification_job'
owner="__owner__"
creator="__creator__"
description="A demo job spec for email notification">
<externaltask name="mail_notification"
owner="__owner__"
start="t"
description="notify author">
<areavpath v="/default/main/WORKAREA/wa1/"/>
<successors>
<successorset description="submit">
<succ v="author_work"/>
</successorset>
</successors>
<command v='http://localhost/iw-cc/urlexternaltask'/>
<variables>
<variable key="ClassName" value="com.corp.custom.MailNotificationTask"/>
<variable key="target_task_name" value="author_work"/>
<variable key="mail_template" value=
"/iwadmin/main/config/STAGING/workflow/email/samples/sampleAuthorNotification.xsl"/>

</variables>
</externaltask>
<usertask name="author_work" owner="__author__" readonly="f">
<areavpath v="/default/main/WORKAREA/wa1/"/>
<successors>
<successorset description="End">
<succ v="End"/>
</successorset>
</successors>
</usertask>
<endtask name="End"/>
</workflow>
Substitute valid values for __owner__, __creator__, and __author__ in the above job
description.
NOTE
Make sure that the user set as __author__ in this job specification has an email address
set within TeamSite by checking that user’s properties under the Content Center
Professional Administration tab.
4. Save this filled out sample job specification as email_demo.xml.

5. Instantiate this job by issuing: iw-home/bin/iwjobc -i email_demo.xml.
The author user should receive an email according the the email template located in
/iwadmin/main/config/STAGING/workflow/email/samples/sampleAuthorNotification.xsl
on the local TeamSite ContentStore.
After demonstrating this capabilty remove the sample toolkit as described “Removing
the Customer Samples Toolkit” on page 32.
This XSL email template (substituting for the supplied Interwoven logo and styles) and
sample MailNotificationTask.java code can be customized as needed for customer
business needs when generating email notifications from workflows.

Appendix A
Recommended Best Practices
This appendix collects together the Best Practices mentioned in this guide.
From the section “Before Making Customizations” in Chapter 1, “Customization

Overview”:
Test UI customizations on a development server running TeamSite, such as the one

provided by Interwoven’s Developer Suite, before making them on the production
server.
From the section “Some Practical Considerations” in Chapter 1, “Customization

Overview”:
Back up the entire customer toolkit (customer_out and customer_src directories) by

copying them to a location outside of the content_center directory, so that the toolkit
can be restored to its original state if needed.
From the section “Deploying Customizations to other Application Servers” in Chapter 3,

“Building the Web Application”:
Automate portions of the process for customizing the ContentCenter web application for
other web application servers in a custom script (substituting the particular locations of
Interwoven files and the web application server deployment directory as appropriate for
your system).
From the section “Making Complex Changes to Online Help” in Chapter 6, “Customizing
Online Help”:
Use a working directory when making complex changes to an online help system and
copy only the new and modified files into the customer toolkit when you are done.

Appendix A: Recommended Best Practices
From the section “Custom Code Deployment” on page 100 in Chapter 8, “Adding
Custom Java Code”:
Place custom Java code accessed from within ContentCenter GUIs within the
ContentCenter web application, unless there is a good reason not to do so.
From the section “Custom Code Deployment” on page 100 in Chapter 8, “Adding
Custom Java Code”:
Use a source control mechanism when there are multiple custom code developers or
designers.
From the section “HTML Links within ContentCenter Custom Code” in Chapter 8,
“Adding Custom Java Code”:
Specify all HTML references to ContentCenter files (property files, images, and so on),
JSPs, and Servlets relative to the ContentCenter web application, not the current URL.

Appendix B
Migrating Existing
Customizations
This guide consists of three sections, the first two of which are related:
How to migrate earlier customizations made using UITK technology to a later
version of TeamSite, either:
To TeamSite 6.7+.
From TeamSite 6.0 or 6.0L to either TeamSite 6.1 or TeamSite 6.5.
The status of customizations that were possible for WebDesk Pro (and WebDesk) in
TeamSite 5.5.2 (using non-UITK technology) within the new ContentCenter user
interfaces.
In addition, all customers migrating from earlier TeamSite versions to TeamSite 6.5+,
should be aware that some customizations affecting the behavior of the client GUIs that
were previously specified in iw.cfg are now specified using the UITK. See the
TeamSite Release Notes for further details.
Migrating to TeamSite 6.7.1 Service Pack 1

In TeamSite Version 6.7.1 Service Pack 1 and later, custom CGI scripts that invoke or
are invoked by the new TagUI use a slightly different calling environment than the old
TagUI. The new TagUI, by default, is used for CGI scripts unless each ContentCenter
GUI, configured separately, has iw.tagui.CGIEnv set to the value old (see “Configuring
the ContentCenter Tagging Interface” on page 71).
If the new TagUI is used by CGI scripts, custom CGI scripts will need to be updated to
expect and pass the new TagUI calling environment. To do this, two changes need to be
made:
Area_path values will need to be fully specified vpaths, not physical paths.
TagUI form variable names need to be fully specified, with their metadata
categories.
For example, the old TagUI form variable name-value pair Business_Unit Finance
would be specified as Default Rule/Description/Business_Unit Finance in the
new TagUI calling environment.

Appendix B: Migrating Existing Customizations
Migrating to TeamSite 6.7

To ensure that customizations made by customers are never overwritten by Interwoven
changes to TeamSite, the new configuration files in /etc/conf/customer were not
installed directly into customer_src; instead they were placed under
customer_src_new. If you have made customizations that these files affect, you will
need to manually merge these new files with your existing customizations before
rebuilding the ContentCenter web application.
NOTE
The directory tree customer_src_new is always installed, even for a new TeamSite 6.7
installation; in that case, its contents are then copied into customer_src.
Advanced Search Screen Customizations

In 6.7+, advanced search screen customizations are now made in search_custom.xml,
not ui_custom.xml. Move any previous search screen customizations out of
customer_src/etc/conf/customer/ui_custom.xml into the empty “skeleton” version
of customer_src_new/etc/conf/customer/search_custom.xml and place it in
customer_src/etc/conf/customer.
Migrating Role Restrictions on Custom Menu Items and

Custom Tabs
In 6.7+, role restrictions on custom menu items and tabs that invoke non-Interwoven
supplied functionality are now made by entering their operationIDs in
custom_userops.xml, not roles_custom.xml.
For backward compatibility, TeamSite 6.7 continues to support the old method of
specifying role restrictions for custom menu items and tabs, but only for the predefined
roles of Author, Editor, Administrator, and Master. This allows customers to defer
migrating already defined custom menu items and tabs to the new permission scheme as
long as they are working with just these roles (not Reviewer), as defined out-of-the-box.
NOTE
One minor change in behavior will occur, due to a small change in the semantics of the
Master role. In TeamSite 6.7+, the Master role is never subject to role restrictions.
Thus, any previous custom menu item or tab that set isPermitted for the role Master to
false will be treated as true by TeamSite 6.7+.
No role restrictions based on the new out-of-the-box role of Reviewer, nor on any
custom roles, nor on any changes made to the category Custom User Operations for the
Interwoven predefined roles will be respected for custom menu items and tabs whose

operationIDs are listed in roles_custom.xml. Attempting to specify role elements

for Reviewer or custom roles in roles_custom.xml will result in the ContentCenter web
application failing to build correctly. Do not do this!
To migrate previously defined role restrictions to the TeamSite 6.7+ scheme:

1. Remove their operation entries from roles_custom.xml.
2. Create operation entries for these custom menu item and tabs in
custom_userops.xml (as described in “Restricting Custom Links by TeamSite Role”
on page 95).
3. Move customer_src_new/etc/conf/customer/custom_userops.xml into
customer_src_new/etc/conf/customer/custom_userops.xml and rebuild the
4. On the TeamSite server, issue iwreset -ui. This will result in these custom
operations being displayed within the Custom User Operation category for each
role (including the Reviewer role and any custom roles) being edited in the
TeamSite Administration Edit Role screen.
5. Edit permissions for this category as needed for each different role to achieve the
desired permission restrctions.
Migrating other New Customization Files

Move customer_src_new/etc/conf/customer/file_template_custom.xml into
customer_src/etc/conf/customer, adding elements to it if desired to enable this
feature.
Migrating 6.0 or 6.0L Customizations

This section can be ignored by customers who are migrating directly from pre-6.0
TeamSite to TeamSite 6.1+.
Customers who did not make any customizations to the ContentCenter GUIs in
TeamSite 6.0 or 6.0L, should delete the contents of
iw-home/local/config/lib/content_center before installing TeamSite 6.1. No other
steps are necessary.
Upgrading to 6.1
In TeamSite 6.0 or 6.0L, ContentCenter customizations could be made in either the
customer_src directory (as in TeamSite 6.1) or in the customer directory within the
customer toolkit.

In TeamSite 6.1, ContentCenter customizations can be made only in the customer_src

directory.
If you made TeamSite 6.0 or 6.0L customizations in the customer_src directory, your
customizations should continue to work with a few migration steps.
TeamSite 6.0 or 6.0L customizations made in the customer directory should continue to
work in 6.1, as long as they are not overwritten by any new customizations made in the
customer_src directory.
NOTE
If the content_center directories were not removed before upgrading to TeamSite 6.1,
then the customer_src directory was not overwritten. Instead, it was installed as
customer_src_new.
However, in order to safely make more customizations and take advantage of new
features, you will first need to manually merge any 6.0 or 6.0L customizations from the
files in the old customer directory within the customer toolkit into the corresponding
files in the customer_src directory and then rebuild the ContentCenter web application:
1. Make backup copies of the customer and customer_src directories.
2. Copy any customizations made in the customer directory to customer_src, as well
as any static files (such as online help files and style sheets) that are not present in
customer_src/web.
If you customized the XML configuration files in

content_center/customer/WEB-INF/conf/customer, instead of
content_center/customer_src/etc/conf/customer, be sure to copy those files
into the customer_src/etc/conf/customer directory.
3. Create an empty directory customer_src/lib.
4. Edit iw-home/local/config/lib/content_center/toolkits.xml. Replace the
final portion of the path listed for the customer toolkit element as follows:
path="C:\iw-home/local/config/lib/content_center/customer"/>
to
path="C:\iw-home/local/config/lib/content_center/customer_out/customer
.tk.war"/>
5. Copy the DOCTYPE headers (second line) from the XML configuration files in
customer_src_new/etc/conf/customer to customer_src/etc/conf/customer.
6. From within iw-home/local/config/lib/content_center/customer_src, issue:
7. If your customizations successfully deployed to the ContentCenter web application,
you can now delete the scripts make.sh, make.bat, and the customer directory.

NOTE
However, you may wish to keep the customer directory in order to compare the 6.0
reference files against the 6.1 reference files supplied by Interwoven.
Other 6.0 Migration Issues

In addition to upgrading, there are a few specific migration issues to consider.
New Reference File Locations
In TeamSite 6.1+, all reference files have been moved out of the customer toolkit into a
reference toolkit: iw-home/local/config/lib/content_center/reference. 6.0 and
6.0L users will need to compare the reference files from those releases to the reference
files in the new location to determine the updates occurring within the
Interwoven-supplied files.
Property File Specification Change
In TeamSite 6.0L and 6.1, a property file must be specified as a link element’s
resourceBundle attribute and not, as in TeamSite 6.0, in a custom XML configuration
file’s placeholder element or other containing element. Customizations that used this
6.0 reference mechanism will need to be migrated forward by specifying
resourceBundles for each relevant link element.
Changed Column Name in Task List
The TeamSite Workflow variable conflict is now renamed to needsattention. Any

customizations (such as columns) based on the conflict workflow variable need to be
migrated forward to the new variable name.
Enabling Directory Browsing instead of Editing Directories with VisualPreview.
In TeamSite 6.0 or 6.0L, this customization was achieved by redefining two links in the
file ui_custom.xml:
<iwov-ui>
<link id="iw.ccstd.my_content.wa_vpreview.link"
refid="_iw.ccstd.directory_browse_inline.link">
</link>
<link id="iw.ccstd.task_details.wa_vpreview.link"
refid="_iw.ccstd.directory_browse_inline.link">
</link>
</iwov-ui>

In TeamSite 6.1+, this customization is achieved by setting a parameter in

application_custom.xml, as described in “Configuring ContentCenter Standard
Workarea Names” on page 74.
To migrate this customization to TeamSite 6.1, remove the link entries above from
ui_custom.xml, add the new param entry to application_custom.xml, and then rebuild
the ContentCenter web application.
Disabling Editor Publish Capability
In TeamSite 6.1, unlike TeamSite 6.0 or 6.0L, this older WebDeskPro customization,
using iw.cfg, now applies to the ContentCenter interfaces as well as WebDeskPro. See
the TeamSite Administration Guide for details on how to make this customization.
NOTE
This customization by TeamSite role mechanism was replaced by the new role
customization method in Version 6.7.0.
Changed Invocation of Legacy WebDeskPro CGIs.
To support legacy WebDeskPro CGIs in TeamSite 6.0, an adapter script was available
for download from the Interwoven support site to emulate the WebDeskPro calling
environment when invoking a legacy WebDeskPro CGI from a ContentCenter link.
This legacy support script, iw-home/httpd/iw-bin/wdpro_menu.ipl is now fully

supported in TeamSite 6.1+. However, in TeamSite 6.1+, it is invoked with the link
element url attribute value: "/iw-bin/wdpro_menu.ipl/legacy_name.cgi", not, as in
TeamSite 6.0, "/../iw-bin/wdpro_menu.ipl/legacy_name.cgi" (starting with /../).
While the older style will work in many environments, it may not continue to work.
Therefore, migrate the url attribute values forward for all links invoking the
WebDeskPro adapter script to use the new address form.
WebDeskPro Customizations Overview

Some previously supported GUI customizations, such as the number of open preview
windows, do not make sense within the design of the new ContentCenter user interfaces
and are not supported by them. These customizations are still supported in TeamSite
6.0+ for the older WebDesk Pro user interface.
Customization instructions for the WebDesk Pro interface have not changed and are
located in an appendix of the TeamSite Administration Guide.
Some customizations altering GUI behavior in older versions of TeamSite affected the
underlying server behavior. Some of these customizations are still possible in TeamSite

6.0+. These are specified as they were in earlier TeamSite versions, not using the UITK
(which is used only for GUI customizations). Thus, these customizations (only) will
now affect both WebDesk Pro and the new ContentCenter user interfaces.
To migrate past customizations of this type to TeamSite 6.0+, update the TeamSite
configuration file iw.cfg with your earlier customizations, as described in the TeamSite
Administration Guide.
Other customizations that used to be specified within iw.cfg are now specified using
the UITK. These will need to be migrated forward, if they are desired in the new
ContentCenter GUIs, changing how they are specified to match the new UITK
technology.
In some cases, due to the different designs of the user interfaces, you may need to make
different customizations in order to achieve a desired effect.
This appendix briefly describes what has changed to enable an assessment of what
migration effort, if any, will be needed, depending on the extent and types of
customizations done to the previous TeamSite GUIs.
Previous Customization Status

WebDesk Pro customizations are listed below in the same order as chapter 5 of the 5.5.2
TeamSite Administration Guide. A few items that were listed in this chapter were not
customizations and are included in this document simply for completeness.
TeamSite Labels
Not available in ContentCenter GUIs.
Edition Views
Editions are displayed in ContentCenter Professional as a paged list. Its page size
cannot be configured with the UITK in this release, but it is anticipated that it will be
configurable in a future release.
File History Views

File versions are displayed in ContentCenter Professional as a paged list. Its page size
cannot be configured with the UITK in this release, but it is anticipated that it will be
configurable in a future release.

User Profiles/Set Home Page

This is an end user preference (replaced by My Favorites in the ContentCenter GUIs),
not a configurable or customizable GUI feature.
Disabling Editor Publish Capability

This iw.cfg specified customization now affects both the WebDeskPro and
ContentCenter interfaces. It is anticipated that it will be replaced by another mechanism
in some future release.
Enable/Disable VisualPreview (Smart Context Editing, SCE)

The ability to enable and disable VisualPreview by branch and file type is a TeamSite
server configuration and is still available in TeamSite 6.0+ (specified in iw.cfg as
before).
In addition, VisualPreview menu items can be globally configured in TeamSite 6.0+

(just like any other menu items), using the UITK.
End user VisualPreview button preferences are not available in TeamSite 6.0+.
URL Commands (Casual Contributor Interface)

For backward compatibility, the CCI URLs officially supported in earlier releases (only)
are supported in TeamSite 6.0+ by being automatically forwarded to functionally
equivalent ContentCenter Professional URL commands. See Chapter 9, “Using URL
Commands.”
NOTE
While these commands are functionally equivalent, different GUI elements
(ContentCenter Professional, not WebDesk Pro) are displayed to end users.
To allow casual contributors to take advantage of the easier to use ContentCenter

Standard Wizards, revise existing Workflows to access the new URL commands, not the
legacy URL commands.
Setting the Local File Manager (LaunchPad) Interface

The Local File Manager applet (formerly LaunchPad), not the LaunchPad application, is
always used by the ContentCenter GUIs. (The intent to discontinue support for the
LaunchPad application was announced in the TeamSite 5.5.2 Service Pack 2 release.)

Setting Unique Server Names for the Local File Manager

(LaunchPad) to Recognize
This is a TeamSite server configuration and is still available in TeamSite 6.0+ (specified
in iw.cfg as before).
Setting Login Authentication Expiration

Configuring Preview Windows

This is not available in (and does not really make sense for) the ContentCenter GUIs.
Custom Menu Items

Custom menu items are discussed in Chapter 7, “Extending GUI Functionality.”
ContentCenter custom menu items are now specified in UITK custom configuration
files, not iw.cfg. The UITK provides much more flexible menu placement and ordering
than was previously available in WebDesk Pro. To be accessed from the ContentCenter
GUIs, existing custom menu items will need to be migrated to this new format (they will
continue to function in WebDesk Pro as before, without any porting).
ContentCenter custom menu items can be restricted by role. This is now done through
the UITK, not iw.cfg. Existing custom menu items that are migrated to the UITK will
need to specify their role restrictions in this new format.
NOTE
This format is different for TeamSite 6.0-6.5 and TeamSite 6.7+.
WebDesk Pro custom menu items that invoke HTML pages can be migrated to the new
UITK format directly.
Custom menu items invoking Java code within the web application were not supported
in WebDesk Pro. These are now supported in the ContentCenter web application, but
only as described in Chapter 8, “Adding Custom Java Code.”
ContentCenter custom menu items invoke CGI scripts differently than in WebDesk Pro,
with regard to how parameters are passed.

WebDesk Pro custom menu items that invoke CGI scripts without making use of passed
parameters can be migrated directly to ContentCenter custom menu items.
WebDesk Pro custom menu items that invoke CGI scripts that make use of passed
parameters will need to either be modified or invoked using an adapter script when
migrated to ContentCenter custom menu items.
The primary difference between how CGI programs are invoked in the two GUIs is that
WebDesk Pro specifies files using file system paths while the ContentCenter GUIs
specify files using Interwoven vpaths. To migrate a WebDesk Pro custom menu item
that uses passed file parameters to the ContentCenter GUIs:
1. Create a new copy of the existing CGI program under a different name.
2. Modify the program to accept vpaths, instead of file system paths.
3. Invoke this new CGI program from custom links specified in the ContentCenter
GUIs.
Alternatively, legacy WebDesk Pro CGIs can be called using an adapter script that
emulates the WebDesk Pro calling environment when called from a ContentCenter GUI:
iw-home/httpd/iw-bin/wdpro_menu.ipl
This is useful in an environment in which WebDesk Pro will continue to be used along
with the ContentCenter GUIs, so as to avoid having to support two versions of each CGI
that uses passed file parameters.
Within a ContentCenter custom menu item, to invoke the adapter script after installing
it, modify the url attribute within the custom menu item’s link element to invoke not
the WebDesk Pro CGI program, but the adapter script with the name of the WebDesk
Pro CGI program appended to it.
Example
The following entry could be added to ui_custom.xml.
<menu id="iw.ccpro.view.menu">
<link id="acme.custom_menu_item.link"
label="Reports"
description="Run the old Reports program"
url="/iw-bin/wdpro_menu.ipl/report.cgi"
windowFeatures="width=640,height=570,scrollbars=yes,
menubar=yes,titlebar=no,resizable=yes,
status=yes,center=true,dependent=false"
target="_blank" />
</menu>
</action-list>
In addition to the file parameters automatically picked up and converted to vpath

paramters, other custom parameters could be passed to the target CGI as well, except for
parameters already used by either wdpro_menu.ipl or iw_cgi_wrapper.cpp. This

includes vpath, arid, brid, dirid, waid, cwd.vpath, done_page, full_redirect, and
iw_locale. If more than two custom parameters are passed, this must be done using
valid XML and escaping the & in the url attribute of the link element.
The adapter script is to be used only for legacy CGI programs called from
ContentCenter (not WebDeskPro). Any new CGI programs should be created to work
directly from the ContentCenter GUIs.
Configuring Submit Button Behavior

“Submit Direct” is not available in the ContentCenter GUIs. Instead, a “no approval”
submit workflow is provided with TeamSite 6.0+.
Disabling Menu Items

All Interwoven-supplied ContentCenter menu items (as opposed to a limited list, plus
delete DCR if FormsPublisher was installed) can be removed globally within either
ContentCenter Standard or Professional, using the UITK (not iw.cfg).
NOTE
Removing too many menu items could, obviously, result in the ContentCenter GUIs
being unable to perform their intended functions.
Interwoven-supplied (not custom) ContentCenter menu items cannot be disabled by role

in this release. However, by removing an operation (such as Copy) in ContentCenter
Standard but not in ContentCenter Professional, one can effectively limit a class of users
(those who use only ContentCenter Standard) from performing certain operations.
Disabling Directory Operations

This is not available within the ContentCenter GUIs, except that file operations which
can act on directories can be removed, as described in the previous section.
Disabling Unlocked File Auto-Upload


Setting the Number of Jobs Listed in the To Do List

Jobs and Tasks are displayed in the ContentCenter GUIs as paged lists, whose page size
can be configured.
Configuring Job Attribute Filters and Settings

Custom job attributes previously specified in iw.cfg will need to be migrated to
ContentCenter Professional.
Custom job attributes can be specified, using the UITK, as columns to be displayed in
ContentCenter Professional’s job attribute list view. As such, end users can then filter
displayed job lists using these columns. Custom job attributes can also be specified as
attributes to be displayed in the job details section.
The range of possible values previously specified for custom job attributes in older
TeamSite GUIs are not used by the ContentCenter GUIs and cannot be migrated
forward.
Configuring Email Settings

Other Customization’s Status

Several other Interwoven products interacted with the older TeamSite GUIs in a
configurable manner. Here is their status with regard to the new ContentCenter GUIs in
TeamSite 6.0+ (their status with regard to WebDesk Pro is unchanged).
DataDeploy
The optional Interwoven-supplied custom menu item Search Extended Attributes,
which could be disabled by role within iw.cfg, is not available within the
ContentCenter GUIs in this release.
FormsPublisher
The optional Interwoven-supplied custom menu item Search DCRs, which could be
disabled by role within iw.cfg, is not available within the ContentCenter GUIs in this
release.

The Workflow/FormsPublisher interactions which could be specified within iw.cfg (see

the TeamSite FormsPublisher Developer’s Guide for details) is a TeamSite server
configuration and is still available in TeamSite 6.0+.
Metadata Capture
The metadata capture screens are still available (and can still be customized) within
iw.cfg in this release. They do not use UITK technology.
Metadata Capture/Workflow
The ContentCenter Standard wizards, by default, invoke a tagging (metadata capture)
step before invoking a TeamSite workflow. If existing workflows also include a tagging
step, this then produces a redundant step for end users. ContentCenter Standard can be
customized to have its wizards skip the default tagging step instead. See“Enabling
ContentCenter Standard “Edit My Workareas” feature” in Chapter 4, “Customizing GUI
Behavior.”
WebDesk Favorites and Recents

These are end user preferences (WebDesk Favorites is replaced by My Favorites in the
ContentCenter GUIs) and are neither configurable nor customizable GUI features.
New ContentCenter users will need to recreate their old WebDesk Favorites list by
hand.
Workflow CGI Tasks

In previous TeamSite releases, Workflow CGI tasks were opened in a new window,
which was closed at the end of the user interaction with the CGI.
ContentCenter Professional continues to invoke Workflow CGI tasks in the same

manner. However, ContentCenter Standard, by default, displays Workflow CGIs in the
same browser window (it does not launch a new browser window).
This behavior can occur in two places in ContentCenter Standard:

Task details. If the workflow task is a CGI task, transitioning this task invokes its
CGI.
Wizards. If the user transitions a task (instead of selecting either the New Job or
Keep Work in Progress options) and the next task in the workflow is a CGI task,
its CGI is immediately invoked.

To ensure that CGI tasks do not close the browser window that ContentCenter Standard
is currently in upon exiting, edit your Workflow CGIs.
Determine which ContentCenter GUI the CGI was invoked from by examining the
window.opener JavaScript object:
If its value is null, the CGI was opened from ContentCenter Standard.
If its value is not null, the CGI was opened from ContentCenter Professional (or
WebDesk Pro).
If the CGI was invoked from ContentCenter Standard, when it is done—instead of

closing its window—forward to the workflow feedback URL command, wffeedback, so
that the ContentCenter Standard confirmation page will be properly displayed to the end
user.
See “Displaying a Workflow Feedback Page from a CGI Task” in Chapter 9, “Using URL
Commands” for details on the workflow feedback URL command.
Alternatively, rewrite the CGI to use the URL command transitiontask to force its
own transition (instead of using the older Perl callback methods) as described in
“Transitioning Workflow CGI Tasks and Done Pages” in Chapter 9, “Using URL
Commands.”
Workflows with Custom Date Attributes

The format used for workflow custom dates changed in TeamSite 6.0+ to Unix
timestamp. This is the format expected by the UITK. Any code that relies on older
date/time formats should be converted to the newer format.
Workflow Instantiation within ContentCenter Standard

Because ContentCenter Standard renders the TeamSite Workflow instantiation screen
inside an iframe, some existing workflow HTML customizations, such as buttons, may not
behave the same within ContentCenter Standard and may need to be migrated forward.

Appendix C
README files
The following README files from the reference toolkit are reprinted here for
convenience:
README_base_config_types
README_teamsite_config_types
README_search_config_types
README_debug_custom_codes
These files are located in the reference toolkit in:

README_base config_types
1. Base configuration types
---------------------------
1.1 Overview
----------------------------------------------------
Each toolkit contains several XML configuration files that define the UI and
behavior of the ContentCenter application. These files can be categorized as follows:
ui*.xml - contains XML that describes miscellaneous UI elements, including:

menus
headings
action lists
tabsets
links
tabs
maps
columns
pagedlists/listviews
portal*.xml - contains XML that describes portlets on a portal page.
application.xml - contains XML that describes miscellaneous application-specific attributes.
roles.xml - contains XML that describes custom menu item access and filtering
1.2 ui*.xml elements

----------------------------------------------------
<link> - This describes a link or a menu item. Links can be contained by menus and
action lists. A link has the following attributes:
id - The ID for this link. This should be unique.
refid - When specified, the link will inherit all the attributes from the
link specified by the refid. Any attribute that this link has will override
any inherited attribute.
label - The text of the link. This can be either text or a property string id
that is located in the property file specified in resourceBundle.

Appendix C: README files
icon - URL of image to display. If the URL begins with "/" then it is assumed
to be relative to the web application.
resourceBundle - Property file to get strings from.
operationID - The operation ID of this link; to be used for role checking. If

roles.xml disallows the operation for the user's current role
the link will be hidden from the user.
target - Specifies the target window to open the link in.
url - URL that is navigated when the link is clicked
windowFeatures - When a link is opened in a new window, this specifies the

attributes of the new window. This is a string of several
attributes, similar to the string that the Javascript
window.open method accepts. The following attributes are
supported:
- width (width of window; integer value)

- height (height of window; integer value)
- scrollbars (whether to display left/bottom scrollbars if needed;
possible values are 0,1,false,true)
- menubar (whether to display a browser menubar;
- resizable (possible values are 0,1,false,true)
- status (whether to display a statusbar at the bottom;
- center (whether to pop the window up in the center of the screen;
possible values are true and false)
- relative (whether to popup and size the window up relative to
its parent;
possible values are true and false)
- dependent (whether the window should be modal; possible values are
true and false)
addPropertiesToUrl - Indicates whether URL parameters should be added to this link's url.
The following is an example of a link:
<link id="example.link"
refid="example.refid.link"
operationId="example.operationid"
href="http://www.example.com"
icon="/customer/example.gif"
label="example.description"
resourceBundle="com.example.strings"
windowFeatures="width=440,height=165,scrollbars=0,menubar=0,resizable=1,status=0,center=true,relative=true,
dependent=true"
/>
Links also have an additional subelement:
urlParam - A parameter to add to this link's url.
The following adds a parameter to the link above, so that the resulting href is
http://www.example.com?x=20
<link id="example.link">
<urlParam id="x" value="20"/>
</link>
<tab> - This describes an individual tab within a tabset. It has the following
attibutes:
id - The ID for this tab. This should be unique.
refid - See definition under link.
label - See definition under link.
resourceBundle - See definition under link.

url - URL that is navigated when the tab is clicked. Content will appear
below the tabset.
operationID - See definition under link.
The following is an example of a tab:
<tab id="example.tab"
label="Example Tab"
url="http://www.interwoven.com"
/>
<separator> - This describes a separator in a menu. It has the following

attribute:
id - The ID for this separator. This should be unique.
The following is an example of a separator:
<separator id="example.separator"/>
<menu> - This describes a popup menu and can be used within an action list. Menus
contain links to describe menu items. Menus can not contain other menus.
Menus have the following attributes:
id - The ID for this menu. This should be unique.
refid - See definition under link.
label - Text to display in the menu anchor.
titleImage - Image to display in the menu anchor.
The following is an example of a menu:
<menu id="example.menu"
label="example.menudescription"
titleImage="/base/images/icn_menuarrow.gif" >
<link id="example1.link"
label="example.description" />
<separator id="example.separator1" />
</menu>
<heading> - Headings appear at the top of many application pages. Headings can contain
action lists and links. Only modifying existing Interwoven headings is supported.
Headings have the following attributes:
id - The ID for this heading. This should be unique.
title - Text to display in the heading.
The following is an example of a heading:
<heading id="example.heading"
title="Example Heading">

</heading>
<action-list> - An action list contains menus and/or links. Action lists have the following
attributes:
id - The ID for this action list. This should be unique.
The following is an example of an action list:
<action-list id="example.actionlist">
</action-list>
<tabset> - A tabset defines a series of tabs. Only adding new tabs to existing Interwoven tabsets is
supported.
<map> - A map defines a series of name/value pairs. A map's purpose depends on how
it is used. Only modifying existing Interwoven maps is supported. Maps support
the following attributes:
id - The ID for this map. This should be unique.
resourceBundle - Property file that child entries will use.
The following is an example of a map:
<map id="example.map"
resourceBundle="com.interwoven.ui.teamsite.workflow" >
<entry id="0" value="example.value1" />
<entry id="1" value="example.value2" />
</map>
<column> - A column in a listview or pagedlist. A column has the following attributes:
id - The ID for this column. This should be unique.
icon - URL of the image to display in the column header.
width - The width of the column. Can be an absolute number (in pixels)
or a percentage.
align - The alignment of the column display. Possible values are:

left
middle
right
sortable - Indicates whether the user can sort the list on this column.
Possible values are:
true
false
nowrap - Indicates whether data that is too long for this column
should be clipped or wrapped.
Possible values are:
true - data will be clipped if too long for this column
false - data will be wrapped if too long for this column
property - Specifies the bean notation of the property to display. The bean
notation is applied to the object being displayed in each
list entry. For example, in the task list, CSTasks from the
CSSDK are being displayed. Specifying a property name will retrieve
a property on the CSTask object.

typeFormat - Depends on what the type is (see below).
propertyMap - Depends on what the type is (see below).
type - The display type for the data being displayed. Possible values are:
string - typeFormat is ignored
actionlist - typeFormat is the ID of the actionlist to display
link - typeFormat is the ID of the link to display. The value

retrieved from the property is set as the link's text. For
example, in the task list, the task id is retrieved and
displayed as a link.
icon - propertyMap is the ID of the map in which to look up the icon.

The value retrieved from the property is used as an index
into the map. For example, in the task list, the task's
priority value is used to look up an icon to display from the
specified priority icon map.
date - typeFormat specifies the type of date. Possible values are:

DEFAULT
SHORT
MEDIUM
LONG
FULL
<listview> - A listview is a list of information that has different layout modes. The
listview contains <column>s that define the information that it will display. Not
all listview instances support having their columns or attributes customized.
Refer to the documentation for each instance to see what is supported. Only modifying
existing Interwoven listviews is supported. The listview has the following attributes:
sortOrder - Direction to sort. This may be overriden by the user's preference.
sortColumn - The initial column to sort on. This may be overriden by the
user's preference.
<pagedlist> - A pagedlist is a listview that supports pagination for long lists. Only modifying
existing Interwoven pagedlists is supported. The pagedlist supports the same attributes
the listview supports, and additionally the following:
pageSize - The number of rows per page. This may be overriden by the user's
preference.
The following is an example of a pagedlist:
<pagedlist id="example.pagedlist"
sortOrder="asc"
sortColumn="example.column1"
pageSize="10"
resourceBundle="com.example.strings" >
<column id="example.column1"
icon="//customer/example.gif"
description="Priority"
property="variable(priority)"
propertyMap="iw.teamsite.job.priority.icon.map"
width="5%"
align="center"
sortable="true"
type="icon"
nowrap="false" />
<column id="example.column2"
description="Job ID"
type="link"
sortable="true"
typeFormat="iw.ccpro.job_details.link"
property="id"
width="10%" align="left"/>
</pagedlist>

1.3 portal*.xml elements

----------------------------------------------------
<portal-page> - Contains portlet groups that define a portal page. Only modifying
Interwoven portal pages is supported. A portal page has the following attributes:
id - The ID for this portal page. This should be unique.
<portlet-group> - This type defines the group of portlets that represent a unit
for layout. A portal group has the following attributes:
id - The ID for this portal group. This should be unique.
width - Width is the width (%) relative to the holding table for
the layout. The group width needs to add up to 100%.
<title-bar> - This defines the type of titlebar for the portlet to use and is contained within
a portlet tag. The title bar supports the following attribute:
type - Possible values are:

standard - Renders a standard porlet title bar
custom - No title bar is rendered
<portlet> - This type defines an individual portlet component within a portal group. A
portlet has the following attributes:
id - The ID for this portlet. This should be unique.
label - Defines the portlet title.
URL - Defines the URL that should be included to render the

portlet. The URL must be relative url to the webapp.
The following is an example of a portlet:
<portlet id="example.portlet"
label="Custom Portlet"
url="/customer/examplePortletServlet">
<title-bar id="example.titlebar" type="standard"/>
</portlet>
1.4 application*.xml elements

----------------------------------------------------
<application> - Specifies the application to which elements apply.
(Currently, only ContentCenter Standard uses application*.xml.)
<param> (sub-element) - Defines an application-specific property.
Refer to comments in ref_ccstd_application.xml for an explanation of the param

properties that are used in the ContentCenter Standard application.
There are currently two <param> properties that are used in the
ContentCenter Standard application.
1.5 roles.xml elements

----------------------------------------------------
<role> - Contains a set of UI operations that are enabled for a
particular role (author, editor, administrator, or master).
<operation> (sub-element) - Defines an operation and specifies whether

it is enabled.
It has the following attributes:
id - the unique identifier for the operation

isPermitted - whether the operation is displayed in the UI for the given role.
For example, the following XML disables a custom menu item for authors:
<role id="author">
<operation id="my.custom.menu.item" isPermitted="false"/>
</role>
2. Interwoven default configurations

-----------------------------------------
Interwoven defines a series of configurations for the default display. For customization
purposes a series of reference XML files have been generated and placed in the customer
toolkit. Use these reference files to find the part of the application you want to
customize.
Only configurations listed in the reference files are supported for customization. Only
tags and attributes listed in this document are supported to be customized.
3. Methods for customizing configurations

-----------------------------------------
3.1 Overriding Interwoven default configuration attributes
----------------------------------------------------
You can override an existing configuration by matching its placement in the
XML DOM tree and then specifying the attributes you wish to override.
The following is an example of overriding an existing Interwoven configuration:
CCPro: Change the windowFeatures for New Job to use a longer window (from 600 to 700 px).
<globals>
<link id="_iw.ccpro.new_job.link"
windowFeatures="width=600,height=700,scrollbars=1,menubar=0,titlebar=0,resizable=1,status=1,center=true,
dependent=false" />
</globals>
3.2 <iwov-insert-before> and <iwov-insert-after>

----------------------------------------------------
New configurations can be inserted before and after existing configurations.
Match the XML DOM tree placement of the configuration where you wish to insert a new
configuration.
The following is an example of using iwov-insert:
<iwov-portal>
<iwov-insert-before id="iw.ccstd.home.how_do_i.portlet">
<portlet id="custom_current_user"
label="custom.portlet.iwov_servlet_current_user.title"
url="/showcurrentuser">
<title-bar id="titlebar" type="standard" />
</portlet>
</portlet-group>
</portal-page>
</iwov-portal>
3.3 <iwov-move-before> and <iwov-move-after>

----------------------------------------------------
Existing configurations can be moved from their existing placement to
somewhere else within the same parent. Additionally you can override
an existing configuration attribute while moving the configuration.
The following is an example of using iwov-move:
<iwov-portal>
<iwov-move-before id="iw.ccstd.home.tasks.portlet">
<portlet id="iw.ccstd.home.work_in_progress.portlet"
label="My Modified Content" />
</iwov-move-before>
</portlet-group>
</portal-page>
</iwov-portal>
3.4 <iwov-delete>
----------------------------------------------------
Existing configurations can be deleted by using iwov-delete. Note: not all
configuration instances can be deleted.

The following is an example of using iwov-delete:
<iwov-portal>
<iwov-delete>
<portlet id="iw.ccstd.home.my_forms.portlet" />
</iwov-delete>
</portlet-group>
</portal-page>
</iwov-portal>
README_teamsite_config_types
1. Teamsite configuration types
---------------------------
1.1 Overview
----------------------------------------------------
The teamsite toolkit adds two additional configuration types:
workflow*.xml - contains XML that describes miscellaneous workflow attributes such
as custom job/task attributes to display on the job/task details screens.
file_template*.xml - contains XML that describes file templates for New File.
1.2 workflow*.xml elements

----------------------------------------------------
<attributelist> - Describes a list of custom workflow attributes. Used by the ContentCenter application to
determine which attributes appear on the Job/Task Details screens. Contains
<attribute> sub-elements. You may only modify existing Interwoven attribute lists.
<attribute> - Describes a custom workflow attribute. It has the following attributes:
id - The ID for this attribute. This should be unique.
property - See definition under column.
propertyMap - See definition under column.
typeFormat - See definition under column.
type - The display type for the data being displayed. Possible values are:
string - An text area is displayed.
map - A dropdown list is displayed.
date - typeFormat specifies the type of date. A calendar widget

is displayed. Possible values are:
DEFAULT
SHORT
MEDIUM
LONG
FULL
The following is an example of an attribute:
<attribute id="example.attribute"
label="example.description"
resourceBundle="com.example.strings"
propertyMap="iw.teamsite.task.priority.map"
type="map"/>
1.3 file_templates*.xml elements

----------------------------------------------------

<file-templates> - Describes a list of file template groups. Contains <allow-empty> and <group>
sub-elements.
<allow-empty> - Describes if an empty file template should show up on UI. This element can
only appear zero or once. The element content is "true" or "false".
<group> - Describes a group of templates. Contains <locations> and <template>

sub-elements. It has the following attributes:
id - The ID for this element. This should be unique.
label - The key in property files for a label. If resourceBundle

is not provided, this will be used as label.
resourceBundle - The resourceBundle in which the label will be looked up

based on the key (label attribute).
<locations> - Describes where this template group should be available. Contains <vpath-regex>
sub-element.
<vpath-regex> - Describes a valid vpath regex for the template group. Please refer to JavaDoc
(java.util.regex.Pattern) for the regex information. It has one attribute:
value - A regex for vpath.
<template> - Describes a template file. Contains <label> and <dir-regex> sub-elements. It has
id - The name of the template file.
label - The key in property files for a label. If resourceBundle

is not provided, this will be used as label.
resourceBundle - The resourceBundle in which the label will be looked up

based on the key (label attribute).
area-relative - Specify the "path" attribute is an absolute path or

workarea relative path. "true" means relative path and "false" absolute
path.
vpath - The vpath of the template file.
The following is an example of a file-templates:
<file-templates>
<allow-empty>false</allow-empty>
<group id="MSWord"
label="label.msword"
resourceBundle="com.mycompany.ui.filesys.template">
<locations>
<vpath-regex value="/default/main/branch1/.*"/>
<vpath-regex value="/default/main/WORKAREA/wa1/.*"/>
</locations>
<template id="White Paper"
label="White Paper"
area-relative="false"
vpath="/default/main/admin/STAGING/white_paper.doc"/>
</group>
</file-templates>
README_search_config_types
1. Search configuration types
---------------------------
1.1 Overview
----------------------------------------------------
The search toolkit adds one additional configuration type:

search.xml - contains XML that describes miscellaneous search

attributes such as number of fields displayed on
a page and what fields/labels are displayed.
1.2 search.xml elements

----------------------------------------------------
Languages:
--------------
<languages> - Describes a list of configured languages

available for the user to select for search.
Used by the ContentCenter application to
determine which languages appear on the
Advanced Search screen. Contains
<language> sub-elements. You may
only modify existing Interwoven
languages list. You may customize
resourceBundle - The property file to use for the child

elements if any child elements do not
specify their own. (optional)
<language> - Describes a language type. It has

id - ID for this language. This should be ISO 639

language code and optionally a country code
(ISO 3166). An example would be "en" for English
and "en_us" for English - United States.
en (English), de (German) , fr (French), ja
(Japanese), ko (Korean), zh (Simplified
Chinese), and zh_tw (Traditional Chinese) are
presented out of the box. (required).
label - See definition under link (base toolkit). This
could be a literal string or a string id
contained in the property file. It provides
a user friendly description of the content
type. (optional)
resourceBundle - The property file to use for the label string

id. This overrides the file specified
in the parent element. (optional)
The following is an example:
<languages id="iw.search.languages">
<language id="es"
label="advanced_search.language.spanish.label"

resourceBundle="com.example.strings"/>
</languages>
Content types:
--------------
<content-types> - Describes a list of content types to search on.

determine which types appear on the
<content-type> sub-elements. You may
content-types lists. You may customize

<content-type> - Describes a content type. It has

id - ID for this attribute. This should be unique

and is a comma delimited list of file
extensions. i.e. "htm,html" or "txt". The
content types "all" and "forms" are system
types to represent all content and form types.
These are presented out of the box.
(required).
contained in the property file. It provides
a user friendly description of the content
type. (optional)

<content-types id="iw.search.content_types">
<content-type id="htm,html"
label="html.type.description"
</content-types>
Extended attributes:

--------------------
<extended-attribute-list> - Describes a list of custom extended attributes.

determine which attributes appear on the
<extended-attribute> sub-elements. You may
extended-attribute lists. You may customize

element if any child elements do not
<extended-attribute> - Describes a custom extended attribute. It has

id - ID for this attribute. This should be unique.

(required).
contained in the property file. (optional)
<extended-attributes id="iw.search.attribute_list">
<extended-attribute id="custom.attribute"
label="custom.attribute.description"
</extended-attributes>
Templating fields:
------------------
<templating-types> - Describes a list of templating type fields.

determine which attributes appear on the
<templating-type> sub-elements. You may
templating-types lists.


<templating-type> - Describes a templating type. It has

id - ID for this attribute. This should be the

actual templating type. i.e. intranet/weather.
(required)
contained in the property file. It's not
necessary but can be used as a friendly label.
(optional)
in the parent element. The file is also
used for the child "templating-field" elements
if they do not specify their own file.
(optional)
<templating-field> - Describes a templating type field. It has

id - ID for this attribute. This should be the

indexed templating fieldname. i.e.
MinBidAmount for templating type
internet/auction. (required)
label - See definition under link (base toolkit).
This could be a literal string or a string id
contained in the property file. It's not
necessary but can be used as a friendly label
alternative to the id. (optional)
resourceBundle - The property file to use for the label
string id. This overrides any file
mentioned in the parent elements. (optional)
<template-types id="iw.search.template_types">
<template-type id="intranet/weather"
label="weather.label"
resourceBundle="example.strings">
<template-field id="Announcement"
label="Weather Announcement"/>
</template-type>
<template-type id="internet/auction">
<template-field id="MinBidAmount"
label="auction_amount.label"
resourceBundle="example.strings"/>
</template-type>

</template-types>
README_debug_custom_codes
1. Debug custom Java codes
---------------------------
1.1 Overview
----------------------------------------------------
Users can add a log4j appender to debug their custom Java codes. This is
specially useful for URLExternalTask and XSLTPTCompiler.
To enable this debugging feature, define loggers in log4j.xml shipped in
customer_src\etc\conf\customer, for example:
<appender name="CUSTOM" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="${log100.iwlogs}/iwui/custom.log"/>
<param name="MaxFileSize" value="100MB"/>
<param name="MaxBackupIndex" value="10"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %c (%x) - %m%n"/>
</layout>
</appender>
<logger name="com.mycompany.mypackage.*" additivity="false">
<level value="debug"/>
<appender-ref ref="CUSTOM"/>
</logger>
In the custom Java source codes, you can use:
private static final Logger LOGGER =

LoggerFactory.getLogger(MyClass.class.getName());
...
LOGGER.debug("myVariable = " + myVariable);
...
All logs from customized codes will be in IWHOME/local/logs/iwui/custom.log.

Glossary
Cascading Style Sheet

The files used to specify HTML styles governing the appearance of rendered web
pages.
Component
The visual “module” displayed on the screen associated with a ContentCenter
Standard portlet.
Configuration File
The XML files used to specify customizations within the UITK.
ContentCenter Web Application

The web application associated with the ContentCenter GUIs. By rebuilding this
web application, specified customizations are applied to the ContentCenter GUIs.
ContentCenter Standard
The ContentCenter GUI intended for TeamSite Content Contributors, such as
Authors and Reviewers.
ContentCenter Professional
The ContentCenter GUI intended for experienced TeamSite users and
administrators, including Editors, Administrators, and Masters.
ContentServices SDK
The application programming interface to Interwoven functionality exposed as web
services. Used by the ContentCenter GUIs, through the standard ContentServices
Java client libraries, to access TeamSite on the Interwoven server.
Custom Menu Item

Used in the older TeamSite GUI, WebDesk Pro, to access web pages and outside
functionality. Replaced by links in the ContentCenter GUIs.
Customer Samples Toolkit

An additional toolkit of sample customizations that can be merged with the

Glossary
Customer Toolkit
The toolkit in which ContentCenter GUI customizations are specified and preserved
across releases.
Customer_src Directories
The customer toolkit directories in which custom code and customizations are
placed.
Customer_out Directories
The ready to merge directories of the customer toolkit in which the output of the
customer source directories is placed before rebuilding the ContentCenter web
application.
Data Content Record

The (.dcr) file containing the underlying data for content structured, entered, and
formatted using forms and TeamSite FormsPublisher.
Form
The displayed screen form that a user fills out to enter structured content.
FormsPublisher
The TeamSite product that deals with entering and formatting structured content.
home page
The ContentCenter Standard initial page that contains components or portlets.
JSP
Java Server Page: a web page with embedded Java code served by a web application
server to the user’s browser.
JavaScript
Web scripting language embedded in web pages and executed by the browser.
Link
A UITK element that can access both UITK functionality and custom functionality,
such as external web pages, CGIs, and custom Java code. Links can appear in many
different places within the ContentCenter GUIs, including action lists, heading bars,
and popup menus.
Local File Manager

The web application, formerly known as LaunchPad, used to associate file
extensions with local editing applications on the end user’s machine.

Glossary
Portal Framework
An internal UITK application framework that behaves similarly to, but is not, a true
web portal. It consists of a home page and attached portlets.
Portlet
A component displayed by the UITK portal framework that behaves similarly to
portlets displayed by web portals.
Servlet
A Java web application that runs on the application server and displays output to a
browser. When used in combination with JSPs, the servlet typically handles data
and control logic, dispatching display requests to JSPs.
TeamSite
The server application providing access to an Interwoven content repository and its
associated versioning, workflow, and templating capabilities. Its functionality is
exposed to end users through the ContentCenter GUIs.
TeamSite Repository
The Interwoven virtual file system that versions content stored within it.
TeamSite Roles
TeamSite users have one or more roles assigned to them. A user acting in a given
role on a given branch is prevented from doing certain TeamSite operations
available to more capable roles. The standard out-of-the-box TeamSite roles, in
increasing order of capability, are: Author, Reviewer, Editor, Administrator, and
Master. Access to custom links and tabs in the UITK can be specified by role.
TeamSite Workflow
The TeamSite job and task management system used to implement business work
processes.
Toolkit
A subsystem of the UITK, merged together with other toolkits—including the
customer toolkit—to produce a web application.
UITK
The User Interface Toolkit technology that underlies the ContentCenter web
application.
URL Command
A request, formatted as a URL, that accesses some or all of the functionality of the
ContentCenter web application, to be displayed in a browser to the end user.
Typically, URL commands are embedded in emails produced by a TeamSite
workflow. A much smaller set of URL commands, formerly known as the Casual
Contributor Interface, was supported in earlier TeamSite releases.

Glossary
VPath
The virtual path describing the location of content within the TeamSite repository.
VisualPreview
An editing toolbar displayed over TeamSite content, formerly known as the SCE
(SmartContext editing) toolbar.
Web Application
A server application whose output is displayed as web pages in client browsers. The
ContentCenter web application underlies both ContentCenter GUIs.
Web Application Server

The server container/application that serves web pages and other server applications
to client browsers.
WebDesk
An older TeamSite GUI, not supported in Interwoven 6.0.
WebDesk Pro
An older TeamSite GUI, no longer supported by TeamSite. It is customized using
older Interwoven technology, not the UITK.

Index
A JSP 94, 102, 103, 109, 110
action-list element 50, 52, 92 servlet 94, 102, 103
addPropertiesToUrl attribute 93 custom link 51
Apache Tomcat 101, 106 custom logo 77, 80
application element 52 custom menu 51
application_custom.xml 41, 57, 64, 74 custom menu item 91, 92, 99, 141
applications element 52 custom portlet 99
attribute element 47, 54, 55 custom tab 53, 95, 99
attribute types 55 custom_userops 41
attributelist element 47 custom_userops.xml 95
customer output directories 19, 26, 33
customer samples toolkit 19, 30, 92
B customer source directories 19, 26, 33
base toolkit 18, 20, 25, 78 customer toolkit 19, 21, 22, 25, 26, 39
button element 53
button Workflow customization 146 D
deployed web application 25
C deployment descriptor file 94, 99, 101
Casual Contributor Interface 110, 140 description attribute 56
ccpro toolkit 25 development server 23
ccstd toolkit 25
CGI 91, 93, 141, 145 E
CGI adapter script 93, 142
column 46, 47, 54, 55, 58 element operations 53
sort direction 46 entry element 52
sorting 46, 58
component 18 F
configuration files 20, 21, 26, 29, 41 file_template_custom.xml 41, 63
configuration ID 44, 55 filter mapping entry 101
ContentCenter logging services 106 form customizations 81
ContentCenter login 109, 113 formspub toolkit 25
ContentCenter Professional 11, 17, 25, 41, 46, 50, FormsPublisher 11, 25, 81, 143, 144
55, 58, 64, 78, 91, 93, 99, 139, 145
ContentCenter Standard 11, 15, 21, 25, 41, 45,
54, 58, 64, 72, 75, 78, 91, 99, 111, 125, G
145 global element 50
wizard 72
wizard topic help 84 H
ContentCenter web application 33, 35
ContentServices 47, 58, 94, 99, 104, 111, 113 heading element 50, 52
custom attribute 47, 144 homepage 15, 41, 45, 46, 54, 96, 125
custom column 47, 144 How do I... component 84, 85
custom elements 42 HTTPS protocol 112
custom Java code 91, 103

Index
I portlet 18, 41, 44, 45, 54, 55, 56, 75, 91, 102, 125
icon element 47, 56 portlet-group element 45
image file 56 property file 56
iw_sessionstring 113
iw_which_ui URL parameter 112 R
iwov-delete 48, 55 README_search_config_types 44
iwov-insert-after 54 README_xml_config 44, 51
iwov-insert-before 53 reference file 27, 43, 57, 58
iwov-move-after 54 reference ID 55
iwov-move-before 54 refid 55, 58
resourceBundle 56
J
JavaScript 97, 146 S
JSP precompilation 34, 35, 38 search_custom.xml 41, 48
separator 50, 51, 54, 55
L servlet entry 101
label attribute 44, 47, 51, 56 servlet mapping entry 102
LaunchPad 140 style sheets 20, 26, 77
link 50, 54, 55, 56, 58, 91, 102 scope 20
submit
listview element 46
locking 68
Local File Manager 140
locking Submit locking 68
Submit, defined 68 submit locking 68
locking model 68
T
M tab 46, 55, 56, 91, 102
make 103 tabset element 46
mandatory write locking 68 tagging step 72
map element 52 target attribute 51
menu 50, 54, 55 TeamSite role 51, 95
display anchor 51 TeamSite Workflow 21, 41, 46, 47, 58, 72, 94,
metadata capture 72, 145 109, 110, 112, 125, 126
third party libraries 101
title-bar element 45
O toolkit 18, 20, 25, 85
online help files 20, 22, 26, 28 toolkits.xml 31
complex changes 89
organization 85 U
style sheets 29, 86
wizard help topics 90 ui_custom.xml 53, 55, 57, 59, 91, 92, 93, 96
operationID attribute 51, 95 UITK technology 11, 18, 25
optional write locking 68 URL 56, 79, 92, 95, 102
url attribute 44
URL commands 105, 109, 111, 112, 140
P UTF-8 encoding 44
page size 58
pagedlist element 46 V
param element 52
placeholder element 21, 27, 43 VisualPreview 75, 140
portal framework 18 vpath 93, 113, 142
portal_custom.xml 41, 42, 54, 57, 97, 98
portal-page element 45

Index
W
web application 18, 21, 22, 56, 99, 101, 103, 109
web.xml 94, 98, 99, 101, 102
webapp.ver 102
WebDesk 133
WebDesk Pro 11, 133, 141, 144
windowFeatures attribute 51, 58
workarea names 74
Workflow CGI task 145
workflow feedback URL command 146
workflow_custom.xml 41, 57, 59
X
XML syntax 42
XML validation 36

Index

Ts 671sp1 Custom v01 en

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ts 671sp1 Custom v01 en

Caricato da

Copyright:

Formati disponibili

TeamSite ®

Interwoven, ConfirmSite, ContentServices, ControlHub, DataDeploy, DeskSite, FileSite, iManage,

TeamSite User Interface Customization Guide

TeamSite User Interface Customization Guide 3

Chapter 4: Customizing GUI Behavior 41

Chapter 5: Customizing GUI Appearance 77

TeamSite User Interface Customization Guide 5

Other Uses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Configuring Submit Button Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

TeamSite User Interface Customization Guide 7

TeamSite User Interface Customization Guide 9

TeamSite User Interface Customization Guide 11

All customizers should read chapters 1 and 2.

Designers should also read chapter 3, 4, and 5.

Interwoven Integrators should also read chapters 6 and 8.

Java Developers should also read chapters 6, 7, and 8.

Table 1 Notation Conventions

TeamSite User Interface Customization Guide 13

This chapter presents an overview of the customization process, describing:

What UI Features can be Customized

Figure 1 ContentCenter Standard before Customization

TeamSite User Interface Customization Guide 15

And here it is after a number of customizations have been applied:

Figure 2 ContentCenter Standard after Customization

Co-branded Logo Custom

Different UI Component Layout

Here is the ContentCenter Professional user interface as it is supplied by Interwoven:

Figure 3 ContentCenter Professional before Customization

Here it is after the customizations have been applied:

Figure 4 ContentCenter Professional after Customization

Co-branded Custom Tabs

New Column Custom

TeamSite User Interface Customization Guide 17

UITK Toolkit Structure

An Interwoven-supplied customer samples toolkit (and customer_sample_src

How Customizations are Preserved across

TeamSite User Interface Customization Guide 19

How Customizations are Specified

Changes to HTML Cascading Style Sheets

Changes to XML Configuration Files

After the web application is rebuilt, the UI components (portlets) displayed in

In addition to redefining Interwoven-supplied entries, entries can be added to

TeamSite User Interface Customization Guide 21

Changes to Online Help Files

Before Making Customizations

Back up the entire customer toolkit (customer_out and customer_src directories) by

Before performing any customizations, consider performing the steps described in

How to Make Customizations

The standard customization process is shown below.

Figure 5 Customization Process

customer_src make_toolkit customer_out make_toolkit

Some Practical Considerations

Recommended Best Practice

TeamSite User Interface Customization Guide 23

To rapidly prototype UI Customizations, an additional desktop server license (typically

TeamSite User Interface Customization Guide 25

and an empty placeholder element (such as in portal_custom.xml)

into which customizations will be placed.

Do not remove any of these lines.

Reference Configuration Files

The reference toolkit, iw-home/local/config/lib/content_center/reference,

For example, ref_csstd_ui_filesys.xml lists elements of ContentCenter Standard

To configure the advanced search screen, edit search_custom.xml.