Customizing Documentum Webpublisher: March, 2002

Customizing Documentum
WebPublisherTM
Version 4.4
March, 2002
Copyright 1999-2002 by Documentum, Inc. 6801 Koll Center Parkway Pleasanton, CA 94566
Documentum® Documentum RightSite®, Documentum Server®, Docbasic®, Documentum DocPage Server®, Now You Know®, Documentum WorkSpace®,
Documentum SmartSpace®, Documentum ViewSpace®, AutoRender Pro™, Docbase™, DocInput™, Docobject™, DocPage Builder™, Documentum 4i™,
Documentum Administrator™, Documentum CADLink™, Documentum Commerce Server Integrators™, Documentum Application Server Integrators™,
Documentum Content Authentication Services™, Documentum Content Personalization Services™, Documentum ContentCaster™, Documentum Corrective
Action Manager™, Documentum Desktop Client™, Documentum Developer Studio™, Documentum DocControl Manager™, Documentum DocLoader™,
Documentum DocViewer™, Documentum Dynamic Content Assembler™, Documentum eConnector for CAD™, Documentum eConnector™ for IBM
WebSphere® (IBM and WebSphere are trademarks of IBM) Documentum eConnector for SAP™ (SAP is a trademark of SAP AG), Documentum eConnector™,
Documentum eConnector™ for BEA Weblogic® (BEA is a registered trademark of BEA Systems Inc) Documentum eConnector™ for JDBC, Documentum
eConnector™ for ATG Dynamo® (ATG and Dynamo are registered trademarks of Art Technology Group), Documentum eConnector™ for Lotus Notes® (Lotus
Notes is a registered trademark of Lotus Development Corporation) Documentum eContent Server™, Documentum Engagement Services™, Document
Engagement Server™, Documentum ftpIntegrator™, Documentum Intranet Client™, Documentum iTeam™, Documentum Reporting Gateway™, Documentum
Site Delivery Services™, Documentum Web Development Kit™, Documentum Web Gear™, Documentum WebCache™, Documentum WebPublisher™,
GMPharma™, GXPharma™, GDPharma™, GSPharma™, Momentum™, Virtual Document Manager™ (VDM), and Documentum Selfrepair™ are trademarks
or registered trademarks of Documentum, Inc. in the United States and throughout the world. All other company and product names are used for identification
purposes only and may be trademarks of their respective owners.
Contents
Preface .............................................................................................................................. ix
Purpose of the Manual .......................................................................................................... ix
Intended Audience ............................................................................................................... ix
Organization ........................................................................................................................ x
Conventions ....................................................................................................................... xi
Related Documentation ......................................................................................................... xi
HTML and JavaScript References ............................................................................................. xii
Chapter 1 Functional Overview and Architecture .......................................... 1–1

What is WebPublisher? ...................................................................................... 1–1
WebPublisher Architecture ................................................................................. 1–3
Installed Components .................................................................................... 1–4
Web Server Components ................................................................................ 1–4
Docbase Components .................................................................................... 1–5
Object Model ............................................................................................... 1–6
Relations ................................................................................................... 1–21
Chapter 2 Customization Overview .................................................................... 2–1

Components to Customize .................................................................................. 2–1
DocApps ..................................................................................................... 2–1
WebPublisher Editor Templates ....................................................................... 2–5
Web Server Files and Docbase Files ................................................................. 2–6
Existing Web Sites ........................................................................................ 2–7
Browser Settings ........................................................................................... 2–7
Components to Customize .................................................................................. 2–7
DocApps ..................................................................................................... 2–7
WebPublisher Editor Templates ..................................................................... 2–11
Web Server Files and Docbase Files ............................................................... 2–12
Existing Web Sites ...................................................................................... 2–13
Browser Settings ......................................................................................... 2–13
Customization Process ..................................................................................... 2–13
Customization Guidelines ............................................................................. 2–13
About Customizing Web Server Components ................................................... 2–27
Chapter 3 Customizing WebPublisher’s Default Settings ........................... 3–1

Enabling and Disabling Role Selection .................................................................. 3–1
Modifying Filename Lengths .............................................................................. 3–2
Chapter 4 Customizing the Properties Page ................................................... 4–1

Copying the attributes.xml File ............................................................................ 4–4
TM
Customizing Documentum WebPublisher i
Contents
Adding and Removing Object Attributes ............................................................... 4–6

Deleting Attributes ........................................................................................ 4–6
Adding Attributes ......................................................................................... 4–7
Suggesting Appropriate Attribute Values ............................................................... 4–9
Adding Value Assistance ................................................................................ 4–9
Adding Value Selection ................................................................................ 4–11
Displaying Value Selection ........................................................................... 4–12
Creating Scripts .............................................................................................. 4–14
Changing which Attributes to Display ................................................................. 4–16
Altering the Content of Property Pages................................................................ 4–19
Testing Customizations .................................................................................... 4–20
Chapter 5 Modifying a List Item .......................................................................... 5–1

Creating a New List Item .................................................................................... 5–1
Copying the list_items.xml File ....................................................................... 5–2
Adding List Item Attributes ............................................................................ 5–3
Modifying a Thumbnail List Item......................................................................... 5–5
Copying the list_items.xml File ....................................................................... 5–6
Modifying List Item Attributes ........................................................................ 5–6
Chapter 6 Customizing Search Pages ............................................................... 6–1

Customizing the Advanced Search Page ................................................................ 6–1
Copying the search_facility.xml File ................................................................ 6–2
The search_facility.xml File ........................................................................... 6–3
Starting the Customization ............................................................................. 6–3
Adding a Custom Object ................................................................................ 6–6
Customizing the Simple Search Page .................................................................... 6–9
Copying the search_facility.xml File .............................................................. 6–10
The search_facility.xml File ......................................................................... 6–11
Starting the Customization ........................................................................... 6–11
Creating a New Search Option ........................................................................... 6–12
Copying Files ............................................................................................ 6–12
The Search Header Files .............................................................................. 6–13
Chapter 7 Customizing Content Pages ............................................................. 7–1

Customizing the Import Page .............................................................................. 7–1
Copying the XML Files.................................................................................. 7–3
Customizing the Create Page Tab ......................................................................... 7–5
Copying the XML File ................................................................................... 7–6
Chapter 8 Creating a Custom Feature ............................................................... 8–1

Customizing the Action List ................................................................................ 8–1
Copying the actionlist.xml File ........................................................................ 8–3
Creating a New Action Folder ......................................................................... 8–3
Adding a New Feature ................................................................................... 8–4
Chapter 9 Creating Process Workflows and Lifecycles ............................... 9–1

Creating Simple Process Workflows ..................................................................... 9–2
Creating Translation Workflows........................................................................... 9–4
TM
ii Customizing Documentum WebPublisher
Contents
Troubleshooting Translation Workflows .............................................................. 9–13

Engagement Services ................................................................................... 9–13
WebPublisher Configuration ......................................................................... 9–14
Translation Workflow Configuration ............................................................... 9–14
Custom Dynamic Performer Values .................................................................... 9–15
Creating a Dynamic Perfomer Value ............................................................... 9–15
Chapter 10 Creating a Web Site .......................................................................... 10–1

WebPublisher Editor and Templates .................................................................... 10–1
Creating Editor Rules Files ........................................................................... 10–3
The Content Template ................................................................................. 10–71
The Editor Presentation File ......................................................................... 10–78
The Thumbnail File .................................................................................... 10–83
Verifying WebPublisher Editor Templates ........................................................... 10–84
Importing Templates and Files ...................................................................... 10–84
Validating Templates .................................................................................. 10–85
Associating Templates ................................................................................ 10–85
Adding New Content .................................................................................. 10–85
Promoting Content ..................................................................................... 10–85
Publishing to a Private Web Site ................................................................... 10–86
Example DocApp Customization ...................................................................... 10–86
Testing your DocApp, Lifecycle, and Workflow ............................................... 10–88
Updating the XSL File for Previewing Documents Created from XML
Templates ..................................................................................................... 10–90
Appendix A Troubleshooting ................................................................................ A–1

Working Around Memory Caching Issues ............................................................ A–1
Locating Docbasic Errors by Line Number........................................................... A–2
When Your Form Calls an External .ebs File .................................................... A–2
When Your Docbasic Script Is In-line ............................................................. A–2
Glossary ...................................................................................................................... GL–1
Index .......................................................................................................................... Index–1
TM
Customizing Documentum WebPublisher iii
Contents
TM
iv Customizing Documentum WebPublisher
List of Figures
Figure 1–1. Documentum 4i System ......................................................................................... 1–2

Figure 1–2. WCM Folder Subfolders ........................................................................................ 1–4
Figure 1–3. WebPublisher Configuration Cabinet ........................................................................ 1–5
Figure 1–4. WebPublisher Object Model .................................................................................... 1–8
Figure 2–1. Product Folder Subdirectories................................................................................ 2–28
Figure 5–1. Default Document View ......................................................................................... 5–2
Figure 6–1. Default Advanced Search Page ................................................................................ 6–2
Figure 6–2. Default Search Link ............................................................................................ 6–10
Figure 6–3. Default Search Link ............................................................................................ 6–12
Figure 7–1. Default Import Page .............................................................................................. 7–2
Figure 8–1. Default Channel Action List .................................................................................... 8–2
Figure 9–1. Simple Process Workflow with Translation Task ......................................................... 9–4
Figure 10–1. Textline field ...................................................................................................... 10–4
Figure 10–2. Content field ...................................................................................................... 10–6
Figure 10–3. Choice field ...................................................................................................... 10–15
Figure 10–4. Graphic selector ................................................................................................ 10–17
Figure 10–5. Text selector ..................................................................................................... 10–29
Figure 10–6. Checkbox ......................................................................................................... 10–41
Figure 10–7. Table ............................................................................................................... 10–43
Figure 10–8. Set of repeatable fields ........................................................................................ 10–45
Figure 10–9. xselector fields .................................................................................................. 10–49
Figure 10–10. Accelera Product Page ...................................................................................... 10–86
TM
Customizing Documentum WebPublisher v
Contents
TM
vi Customizing Documentum WebPublisher
List of Tables
Table 1–1. WebPublisher Folders on Web Server ....................................................................... 1–4

Table 1–2. WebPublisher Docbase Folders ................................................................................ 1–6
Table 1–3. dm_sysobject ....................................................................................................... 1–9
Table 1–4. wcm_auto_naming .............................................................................................. 1–10
Table 1–5. wcm_channel ..................................................................................................... 1–10
Table 1–6. wcm_change_set................................................................................................. 1–11
Table 1–7. wcm_config ....................................................................................................... 1–12
Table 1–8. wcm_edition ...................................................................................................... 1–18
Table 1–9. wcm_edition_fld ................................................................................................. 1–18
Table 1–10. wcm_locale ....................................................................................................... 1–19
Table 1–11. wcm_user_pref ................................................................................................... 1–20
Table 1–12. wcm_category .................................................................................................... 1–22
Table 1–13. wcm_default_workflow ....................................................................................... 1–23
Table 1–14. wcm_doc_template ............................................................................................. 1–23
Table 1–15. wcm_dynamic_content ........................................................................................ 1–24
Table 1–16. wcm_layout_template .......................................................................................... 1–24
Table 1–17. wcm_my_template .............................................................................................. 1–25
Table 1–18. wcm_process_workflow ....................................................................................... 1–25
Table 1–19. wcm_publishing_template .................................................................................... 1–26
Table 1–20. wcm_rules_template ............................................................................................ 1–26
Table 1–21. wcm_template_thumbnail ..................................................................................... 1–27
Table 2–1. Dispatcher Arguments and Values .......................................................................... 2–20
Table 2–2. Environment Variables ......................................................................................... 2–22
Table 2–3. Docbasic Global Variables .................................................................................... 2–23
Table 2–4. Product Folder Subfolder Descriptions .................................................................... 2–32
Table 9–1. Language Codes and Email Addresses .................................................................... 9–11
Table 10–1. <textline> Attributes ............................................................................................ 10–5
Table 10–2. <content> Attributes ............................................................................................ 10–7
Table 10–3. <choice> Attributes ............................................................................................ 10–15
Table 10–4. <graphic> Attributes ........................................................................................... 10–18
Table 10–5. <textselector> Attributes ..................................................................................... 10–30
Table 10–6. <checkbox> Attributes ........................................................................................ 10–42
Table 10–7. <tabledef> Attributes .......................................................................................... 10–44
TM
Customizing Documentum WebPublisher vii
Contents
Table 10–8. <repeatdef> Attributes ........................................................................................ 10–46

Table 10–9. <xselector> Attributes......................................................................................... 10–49
Table 10–10. Group and Folder Aliases .................................................................................... 10–89
TM
viii Customizing Documentum WebPublisher
Preface
Purpose of the Manual

This manual describes how to customize WebPublisher. It describes WebPublisher
architecture, customization methodology, and provides example cuxtomizations
including stepping you through the creation and deployment of a sample Web site.
Intended Audience
This manual is primarily intended for system integrators who customize and deploy
WebPublisher. This manual assumes you are familiar with JavaScript and HTML and
that you have experience working with the following Documentum systems:
• Documentum WebPublisher
• Documentum Developer Studio
• Documentum Administrator
• DocApp Installer
• Documentum WebCache
To help you gain the knowledge you need to effectively customize WebPublisher,
Documentum recommends that you take the following training courses through
Documentum’s Education Services.
• Technical Fundamentals for Documentum 4i Admin/Developer Version
Designed for Web developers, system administrators, and project managers who
want to become familiar with the various Documentum 4i products and their
capabilities.
• Developing Web Applications Using RightSite
Designed for application developers who are creating Web applications using
Documentum 4i technology.
TM
Customizing Documentum WebPublisher ix
Preface
• WebPublisher
Designed for WebPublisher administrators and Web developers who need to install
and configure the WebPublisher application.
• System Administration for Documentum 4i
Designed for the Documentum system administrator and project architect.
• Managing Site Delivery Services — WebCache
Designed for deployment managers, Web site administrators and system
administrators who need to deploy content and or applications from Documentum
eContent servers to multiple Web sites using Documentum.
For more information and Documentum’s suggested curriculum path for WebPublisher
refer to Documentum’s Web site and search for Web Content Management (WCM)
Edition classes.
Organization
This manual contains six chapters and one appendix. The table below lists the
information that you can expect to find in each.
Chapter Contents
Chapter 1, Functional Overview and Architecture Discusses customization methodology and

architecture including delivery cabinets,
folder mapping and system configuration.
Chapter 2, Customization Overview Discusses the WebPublisher hierarchy, the

dispatcher, and the history mechanism.
Provides conceptual information for creating
a custom DocApp.
Chapter 3, Customizing WebPublisher’s Default Discusses modifying WebPublisher’s

Settings default settings.
Chapter 4, Customizing the Properties Page Discusses creating new attributes and
modifying existing attributes.
Chapter 5, Modifying a List Item Discusses creating new list items and
actions.
Chapter 6, Customizing Search Pages Discusses how to customize an existing

search page, and create a new search option.
Chapter 7, Customizing Content Pages Discusses creating a new import page, and
add new content page.
TM
x Customizing Documentum WebPublisher
Preface
Chapter Contents
Chapter 8, Creating a Custom Feature Provides step-by-step instructions to create

WebPublisher specific workflows and
lifecycles.
Chapter 9, Creating Process Workflows and Lifecycles Provides step-by-step instructions to create
WebPublisher specific workflows and
lifecycles.
Chapter 10, Creating a Web Site Provides in depth analysis of a sample Web
site creation using a custom DocApp, the
Rules Editor and WebPublisher Editor.
Appendix A Provides you with information about

common RightSite and WebPublisher
functions which may cause you trouble.
Conventions
This manual uses the following conventions:
Convention Description
> Represents a pop-up or pull-down menu.
<>angle brackets Represents a variable name for which you must provide a value,
or a defined term.
typewriter Represents code samples, user input, and computer output.
bold Represents a button in on the WebPublisher page.
Note: Attributes and Properties are used interchangeably throughout this guide.
Attributes when discussing the attributes.xml file, and Properties when referring to the
Web page. Both terms represent the same elements.
Related Documentation
The following lists other Documentum documentation you should be familiar with
before attempting to customize WebPublisher.
• Using WebPublisher Pro explains how to configure WebPublisher and to design and
administer Web sites.
• Using WebPublisher explains how to use and manage the WebPublisher
content-authoring interface, used for creating and publishing Web pages.
• Docbasic Reference Manual helps application developers create Docbasic procedures.
TM
Customizing Documentum WebPublisher xi
Preface
• Documentum RightSite Reference Manual provides Documentum RightSite Web

developers with information on how RightSite works.
• Developing DocApps describes the concepts and general strategies for packaging some
customizations into a DocApp and deploying the DocApp to a Docbase.
• Administering Documentum Media Services describes the concept of transforming
media files from one format to another and generating thumbnail renditions to
view and manage through WebPublisher.
HTML and JavaScript References

Following is a list of books and Web sites that will provide you with HTML and
JavaScript information.
• JavaScript Bible (by Danny Goodman, ISBN 0-7645-3188-3)
• NCD HTML Design Guide (Visual Quickstart Guide by Elizabeth Castro, ISBN
0-201-68862-X, http://www.ncdesign.org/html/index.htm)
• JavaScript for the World Wide Web (Visual Quickstart Guide by Ted Gesing and Jeremy
Schneider, ISBN 0-201-68814-X)
TM
xii Customizing Documentum WebPublisher
Chapter 1
Functional Overview and Architecture
This section contains an overview of WebPublisher, lists the pre-requisite knowledge of Documentum
products that all WebPublisher customizers should have, and describes how different software and
hardware components interact to support WebPublisher.
What is WebPublisher?
WebPublisher is a Web browser-based software application used to create, manage
and construct Web pages according to company-designed templates. WebPublisher
uses numerous Documentum software products to integrate with both the eContent
Server and the Web. Following is a description of how WebPublisher uses Documentum
products.
WebPublisher uses:
• eContent Server to provide content management services, content file stores,
database tables, indexes, and metadata in a secure repository called a Docbase.
In addition to its storage and retrieval services, eContent Server provides object
management services (including version control, rendition management, and
security and access control), workflow management services, lifecycle services, and
viewing and printing services.
• RightSite to provide the HTTP server integration between WebPublisher and the
eContent Server.
• WebCache to export Web pages and associated metadata from a Docbase to a
WebCache repository. The WebCache repository can contain a staging Web site or a
production Web site and can be integrated with your production Web (HTTP) server.
• AutoRender Pro to generate HTML renditions of content files for display in a Web
browser.
• Content Personalization Services (CPS) to automatically provide suggested property
data for WebPublisher-created content objects.
• Media Services to enable processing and management of rich media content.
TM
Customizing Documentum WebPublisher 1–1
• Documentum Administrator for administering the eContent Server. Using

Documentum Administrator you can create users and groups, set environmental
variables, define alias sets, and define Access Control Lists (ACLs).
• Developer Studio to build custom WebPublisher applications which can be packaged
and deployed to production Docbases.
• ftpIntegrator to import an existing Web site into a WebPublisher Docbase, or to
integrate with a variety of common Web development and authoring tools, including
Dreamweaver, WSFT Pro, and Homesite to open documents directly from the
Docbase.
• Documentum Engagement Services to run translation workflows. Use the
engagement server to email a document via a workflow to be translated by an
external translator.
Figure 1–1 provides you with a visual representation of the Documentum 4i products
and how they work together.
Figure 1–1. Documentum 4i System
Customizing WebPublisher is a complex task that should only be attempted if you have
the knowledge of Documentum products as recommended below.
To customize files in your WebPublisher Docbase, you use Documentum Developer
Studio to create a custom DocApp (Docbase Application). You can copy objects from
TM
1–2 Customizing Documentum WebPublisher
your WebPublisher Docbase into your custom DocApp and modify the object in your
custom DocApp or create new custom objects in your custom DocApp. Details for
customizing WebPublisher files as well as sample customizations for files on your Web
server and WebPublisher Docbase are provided in subsequent chapters. Following is a
list of topics that will be explored.
• XML files
WebPublisher consists of XML files stored on your Web (HTTP) server and in your
WebPublisher Docbase. You customize WebPublisher by customizing the files
in these two areas.
To customize files on your Web server, you copy the file (to be customized) to a
custom folder in the WebPublisher hierarchy on your Web server and modify the
copied file so that it contains your desired customization.
• workflows and lifecycles
Process workflows and how they can be customized for your business processes.
Document lifecycles and how they affect the state of documents as they move
through a process workflow
• templates and files
WebPublisher Editor templates and files can be customized to create a layout and
other non-content related elements used in your company’s Web page.
• existing Web site
WebPublisher enables you to bring your existing Web sites into WebPublisher and
manage them in a central location. The guidelines discussed in this document
should be followed for best results.
You should be familiar with the concepts of a Docbase, DQL (Document Query
Language), Docbasic, JavaScript, RightSite, DFC (Documentum Foundation Classes),
APIs, and the WebQL language, as well as HTML and XML. Many of these elements are
used to create needed customizations. All of them are used within WebPublisher itself.
WebPublisher Architecture
WebPublisher architecture is a structural arrangement of components installed on your
system. This section describes the installed components including Web (HTTP) server
components and Docbase components, and folders and delivery cabinets. You will
learn the importance of the directory structure and how to use this structure to affect
customizations.
TM
Installed Components
WebPublisher consists of components installed on the Web server and components
installed in the WebPublisher Docbase. The Web components are created during
WebPublisher installation by a standard Windows (InstallShield) installer. The Docbase
components are created during WebPublisher installation by the Documentum DocApp
Installer. The DocApp installer installs the default WebPublisher DocApp. There is
an optional WebPublisher sample Web site DocApp (Accelera DocApp) that you are
encouraged to install if you want guidance on modifying an existing Web site. The
sample Web site is described in further detail in Chapter 10, Creating a Web Site. For more
information about installing WebPublisher, refer to Installing WebPublisher.
Web Server Components

Web server components are any RightSite objects such as XML files, WebPublisher is
based on RightSite client technology. Please refer to the Documentum RightSite Reference
Manual for more information on RightSite technology.
WebPublisher-specific files stored on the Web server are stored in the wcm folder. The
following table lists the folders contained in wcm and summarizes the contents of each
folder. Following are the subfolders under \RightSite\applications\wcm.
Figure 1–2. WCM Folder Subfolders
Table 1–1. WebPublisher Folders on Web Server
Folder Description
app_jarfiles Jar files for WebPublisher Editor.
application WebPublisher DocApp archive files.
Customization files for WebPublisher. Features in this folder over-

ride default WebPublisher behavior. The folder hierarchy in this
custom
folder must parallel the folder hierarchy in the product folder in
order for a customization to be used.
Online Help files for the administrator and Web developer user,
help
and for the content author and content manager users.
product Folders and files that control default WebPublisher behavior.
TM
Folder Description
Scripts that are used by lifecycles and workflows in the WebPub-

server script
lisher DocApp.
temp Temporary system folder.
Docbase Components
WebPublisher contains two sets of Docbase components:
• Those created from installation of the WebPublisher default DocApp
• Those created from installation of the Accelera DocApp
Both of these DocApp installations create one or more sets of cabinets and folders in the
Docbase as well as creating a DocApp that can be viewed and edited in Documentum
Developer Studio. For more information about Documentum Developer Studio, please
refer to the Documentum Developer Studio Help.
Docbase Cabinets and Folders
The WebPublisher installation creates the following default cabinet and folders in the
WebPublisher Docbase.
Figure 1–3. WebPublisher Configuration Cabinet
Note: In the WebPublisher interface, the Favorites and User Preferences folders are not
displayed in the Docbase view.
WebPublisher-specific folders that can be accessed by an administrator or Web developer
are stored in the WebPublisher Configuration cabinet. The following table lists the folders
contained in WebPublisher Configuration and summarize the contents of each folder.
TM
Table 1–2. WebPublisher Docbase Folders
Folder Description
Common Contains objects that apply across all of WebPublisher.
FolderMap An XML file that specifies where newly created files

get put in the Docbase.
System Configuration Object consisting of properties that define a set of

configuration parameters for WebPublisher.
Content Templates Contains all content templates that can be selected

when creating a new content object. Also contains the
content category folder hierarchy used to organize
the content templates.
Favorites Contains the list of frequently accessed items

compiled by individual WebPublisher users.
Supporting Templates Contains template files used by the content templates.
Editor Presentations Contains presentation files used for files created with
the WebPublisher Editor.
Editor Rules Contains rules files used by the WebPublisher Editor.
External Application Presentations Contains presentation files used for files created in an
authoring tool other than the WebPublisher Editor.
Thumbnails Contains thumbnail files that provide a pictorial

representation of a template set as it would look when
published to the Web.
User Preferences Contains preference settings for individual

WebPublisher users.
Default DocApp Components
During installation, the WebPublisher DocApp, which includes predefined WebPublisher

components, is installed to the Documentum eContent Server. The predefined
components allow you to immediately begin creating Web sites in the WebPublisher
Docbase. Using WebPublisher Pro provides a description of the default WebPublisher
DocApp components.
Object Model
In WebPublisher, all the items you manipulate are objects. Every document is an object,
as are the cabinets and folders in which you store the documents. Even users are objects.
TM
All objects have associated characteristics, called properties and associated operations,
called methods. Properties are fields that are part of the object. The values in these
fields describe the object. Methods are operations that you can perform on an object.
Properties and methods are part of the object’s type description. All objects belong to a
type. Please refer to Documentum eContent Server Fundamentals for a full description of
objects and types.
This section contains a listing of all WebPublisher object types and properties and a
diagram showing the relationship between the object types. A short description is
provided for each object type followed by a tabular listing of the custom properties for
the designated type with a description of the property and the value of the property.
Following is a list of all WebPublisher dm_sysobject types.
• wcm_auto_naming
• wcm_channel
• wcm_channel_fld
• wcm_change_set
• wcm_config
• wcm_edition
• wcm_edition_fld
• wcm_favorites
• wcm_locale
• wcm_supporting_doc_folder
• wcm_user_pref
TM
Figure 1–4. WebPublisher Object Model
TM
dm_sysobject
The dm_sysobject type is the parent type of all objects in the WebPublisher system. The
dm_sysobject type has three important properties, represented by properties, that it
passes on to all its subtypes. These properties are:
• A sysobject accepts security permissions. Attributes defined for the sysobject allow
you to set permissions on the object.
• A sysobject, unless it is a cabinet, can belong to a folder.
• A sysobject can own one or more content objects.
Please refer to Documentum eContent Server Object Reference Manual for more detailed
information on objects and object types.
Table 1–3. dm_sysobject
Property Name Description Value
a_category Describes the categorization of the char (64) on Oracle,

object derived from the selected SQL Server, and
category folder Informix, but char
(32) on Sybase.
a_effective_label Name of the delivery channel char (32) repeating

(cabinet.) It is tied to
a_effective_flag, a_effective_date,
and a_expiration_date by index
(i_position value)
a_effective_flag Indicates whether a pending char (8) repeating

expiration notice was sent to the
document’s owner for the specific
channel
a_effective_date Date the object should become date repeating

effective for the channel
a_expiration_date Date the object should be expired date repeating

for the channel
a_publish_formats List of formats that should be char (8) repeating

exported through the cache server
for an object in addition to the
standard set of formats defined in
the cache server config
TM
wcm_auto_naming
wcm_auto_naming is used for automatic object name generation. wcm_auto_naming is

a subtype of dm_sysobject enabling WebPublisher to leverage the checkin and checkout
feature provided by dm_sysobject. These objects are stored in the /WebPublisher
Configuration/Auto Naming folder. Each object has the same name as the template
using it, for example object_name will have the value of the template name. This object
type is new to WebPublisher 4.3.
Table 1–4. wcm_auto_naming
template_id Chronicle ID for the template using ID

this auto number.
last_number Current counter of auto-numbering. integer

Default is 0
wcm_channel
A channel is defined in WebPublisher as a delivery cabinet and the top level of a structure
that mirrors a web site. This object is a subtype of dm_cabinet.
Table 1–5. wcm_channel
wip_cache Holds the name of the common char (80)

WIP cache for this selected channel
object.
staging_cache Holds the name of the common char (80)

"Staging" cache for this selected
channel object.
asynch_publish True if publishing to WebCache boolean

should happen asynchronously
for staging or active state, False
otherwise. Default is False
default_group Name of group associated with this char (64)

web site.
TM
site_main_page Channel’s entry point page name char(64)

with (relative) path. This is mainly
used by in-context editing.
enable_ice Enable In-Context Editing. Default boolean

is False. It can be turned on via the
properties page of the cabinet.
wcm_channel_fld
The channel folder object is the folder created by default underneath a delivery cabinet.
This object is a subtype of dm_folder. It has no custom properties.
wcm_change_set
The wcm_change_set object represents a Change Set in WebPublisher. It is a folder and

the objects within the change set will be linked to the folder. This object is a subtype
of dm_folder.
Table 1–6. wcm_change_set
translation_ids IDs of the translation files. These ID repeating

are normally copies of one or more
files to be translated. For example:
if the next task is a translation
task (need French translation), the
current task will create a translation
by making a copy of original file.
The language_code of the new file
is set to French. The ID of this
new file is stored in this property.
This property is used in automatic
tasks and in engagement server
integration.
post_translation_ids IDs of the translated files. After ID repeating

one or more files are translated and
checked in, their IDs are stored in
this property. They are used in post
checked in process
TM
priority Priority of the change set. User char (32)

entered. Values include: High,
Medium, Low.
lifecycle_states List of lifecycle states of the objects char (32) repeating

managed by the change set. Objects
within a change set will all have
the same lifecycle structure for
example, same state names and
number of states. This is filled out
when the first object is added to
the change set. The current status
value will be stored in a_status.
auto_ind Indicates how the change set was integer

created. Values include:
• 0, was created manually.
• 1, was created automatically by

WebPublisher.
• 2, was created temporarily by

WebPublisher.
wcm_config
The wcm_config object tracks the configuration data that is applicable for the application
as a whole. This object is a subtype of dm_sysobject.
Table 1–7. wcm_config
review_notif Number of calendar days before integer

an object’s expiration date that a
notification of pending expiration
should be sent to the object’s owner
TM
wip_symbol User-defined name for the char (32)

development state of an object.
Defined to be an area where specific
object/pages are viewed to ensure
they display properly on the Web
without too much concern for
the interaction with other objects.
Default to WIP.
staging_symbol User-defined name for the staging char (32)

state of an object. Defined to be an
area where specific objects/pages
are viewed to ensure they correctly
interact with other objects on the
Web. Default to Staging
approved_symbol User-defined name for the char (32)

approved state of an object. Does
not indicate that object will move
to production cache. Default to
Approved
active_symbol User-defined name for the active char (32)

state of an object. Production area
of the web. Default to Active.
expired_symbol User-defined name for when char (32)

an object is expired. Default to
expired.
dctm_admin_location URL to launch Documentum char (255)

Administrator.
site_protection Site protection and ACL setting integer

preferences.
• 0, show ACLs (site protection is
off.). This is the default value.
• 1, use user defined ACLs (site

protection is off).
• 2, use site-specific ACLs to

protect the sites (site protection
is on).
global_management True if global content management boolean

feature is turned on and False is off.
Default is False.
TM
default_locale Default locale for this docbase. char (5)

Default is en_US.
lifecycle_states List of lifecycle states this Docbase char (32) repeating

uses. Earlier on the repeating list
represents the earlier state.
engagement_server_host_addr Host address where engagement char (64)

server is running/installed.
multisite_effectivity • False, only allow a single boolean

effective date and a single
expiration date to be associated
with an object
• True, multiple effective dates

can be set on objects.
wcm_service_url RightSite service URL char (128)
new_obj_cnt Number of new objects to integer

prefabricate. This is for object bag
feature. Should be greater than 0.
Default is 5.
valid_web_formats List of format types that are char (32) repeating

considered web safe and do not need
to be translated to HTML
default_channel Name of the delivery cabinet that char (64)

is used if user’s default delivery
cabinet is not set
doc_lifecycle Name of the lifecycle that should char (64)

be the default for content objects
default_page Name of page that should be char (32)

displayed as starting page for
business user interface. Values will
include In box, Create Page, Edit
Page, View Alerts.
expiration_increment Number of days after the effective integer

date that should be the default for
the expiration date. Example, if the
value is 15 and the effective date is
1/1/00, then the expiration_date
would be 1/16/00. If this value is
0 or not present, then no default
expiration date should be set.
TM
default_workflow Name of the dm_workflow that char (80)

should be used for object updates
initiated by business users by
default if one is not defined.
thumbnail_v_size Vertical size of template thumbnail integer

preview in number of pixels
thumbnail_h_size Horizontal size of template integer

thumbnail preview in number of
pixels
edition_cache Object name of dm_webcache_ char (80)

config object that will be used as
the cache config object for editions
default_acl Name of WebPublisher Default char (64)

ACL
format_ext_list List of DOS extensions and its char (32) repeating

Documentum format name
cps_host_addr IP address for Content char (64)

Personalization Services (CPS)
host. If defined, then will indicate
both the address of the CPS process
as that CPS services are available to
WebPublisher.
cps_node_name Name of a default CPS node to char (128)

use when indexing WebPublisher
objects
cps_formats List of formats that can be indexed char (32) repeating

by CPS. Values will include
all text-based formats, such as
MS-Office formats.
text_formats List of formats that are text char (32) repeating

based and can be differenced by a
differencing tool. This list will also
be used by the WebPublisher Editor
when importing objects from the
text selector widget
graphic_formats List of graphic formats. Will be char (32) repeating

used by the WebPublisher Editor
when importing objects from the
graphic selector widget.
TM
wd_version_ind Indicator whether Web developers integer

are prompted for version increment
to be next minor version or same
version. Values include:
• 0, not prompted, will always go
to next minor version number
(default)
• 1, prompted
display_comment_ind Indicator whether to display integer

comment box when checking in
(affects all users). Values include:
• 0, display comment box (default)
• 1, do no display comment box
comments_req_ind Indicator if comments are required integer

(only valid if comment box
is displayed for example,
display_comment_ind=0). Values
include:
• 0, comments not required
(default)
• 1, comments required
available_events List of events that the administrator char (32) repeating

makes available for users to register
on WebPublisher objects.
start_page Name of the start page for content char (32)

authors and content managers.
Values include: Create Web Page,
Edit Web Page, Work On Tasks,
View Alerts.
allow_author_import Indicator whether content authors boolean

and managers will be able to import
from their desktops. Defaults to
False.
TM
delay_publish_active Indicator whether the system will boolean

delay automatic export of an object
to the appropriate Web cache(s)
when promoted to Active. If True,
then automatically publish. If False,
then do not automatically publish.
Defaults to False.
simple_search_mode Include full text search in simple boolean

search if this is True. Default is
False.
log_level Log level of server scripts not run integer

by server jobs Default: 0 = trace
OFF
enable_web_based_editor Use Web based HTML editor. integer

• 0, never (default)
• 1, optional
• 2, required
web_based_editable_formats All the formats available to perform char (32) repeating

web based editing Default is empty.
keep_local_copy Do not remove local file upon check boolean

in or cancel check out if set to TRUE
Default: FALSE
confirm_overwrite During check out, if local copy of boolean

same file exists, ask use to confirm
overwriting the local file Default:
FALSE
set_creator If true, Add content will call a boolean

server method to set the creation
date and creator when the new
object is coming out from the object
bag. Default is false
wcm_edition
wcm_edition is a cabinet which stores snapshots of a Web delivery cabinet. wcm_edition

contains a set of edition folder objects (wcm_edition_fld) that map to delivery folders
within a cabinet. The edition cabinets will be stored as hidden object (a_is_hidden =
TRUE) so that they do not adversely affect non-WebPublisher UI’s that might be looking
TM
at a WebPublisher Docbase since there may be hundreds of edition cabinets created over
a period of time. wcm_edition is a subtype of dm_cabinet.
Table 1–8. wcm_edition
a_channel_id Object ID of the delivery cabinet. ID
target_host Host name that was entered when char (255)

the edition was exported through
the edition cache config object.
target_virtual_dir Web server’s name for the virtual char (255)

directory where the Web site is
located that was entered when the
edition was exported through the
edition cache config object.
target_root_dir Host root directory that was entered char (255)

when the edition was exported
through the edition cache config
object.
wcm_edition_fld
The wcm_edition_fld (edition folder) object represents a delivery folder object within
an edition. It contains links to specific versions of content objects. wcm_edition_fld is
a subtype of dm_folder.
Table 1–9. wcm_edition_fld

a_chnl_fld_id Object ID of the delivery cabinet ID
wcm_favorites
Every WebPublisher user will be assigned a favorites folder. It will be the default location
of objects created by the user that are not assigned to a location within a delivery cabinet
through the folder map. Users will also be able to add a link to any document to their
favorites folder. When the user interface displays location information for objects, user’s
favorites folders should not show up.
TM
wcm_locale
wcm_locale is a new object type for WebPublisher 4.3 and is used to define allowable
locales for the WebPublisher system. wcm_locale is a subtype of dm_sysobject.
Table 1–10. wcm_locale
language_name Name of the language for this char (32)

local and value come from the
configuration.xml file.
country_name Name of country for this local char (64)

and value come from the
configuration.xml file.
fallback_locale The fallback locale char (5)
encoding_name The language encoding used by the char (32)

WebPublisher editor. Optional
default_workflow Object ID of translation workflow ID

associated with this locale
wcm_supporting_doc_folder
This is the folder contains all supporting objects for a change set. Every change set folder
contains a wcm_supporting_doc_folder folder. Supporting objects (and these may be
new objects imported just for the change set or existing Docbase objects) are linked to
this folder. No properties are required for this object type.
wcm_user_pref
The user preference object stores information about the user that should be persistent
from session to session. This is used for user interface preferences such as layout and
colors and for system-required items like default checkout. This object is a subtype of
dm_sysobject.
TM
Table 1–11. wcm_user_pref
bounding_number User-defined number of items to integer

appear on a list item page, for
example, file list. Value of 0 means
no bounding. Every item will be
shown. The possible values are
limited to the set defined in UI
specification. Default is 20.
default_locale_filter The default locale the user wants to char (5)

see in the file listing and the value
is one of the locale codes. If null,
display all locales. Default is the
same as default_locale defined in
wcm_config.
show_cabinets Show non-delivery cabinets. boolean

Default is False.
last_selected_users The user OS name of the last 20 char (32) repeating

selected users in start workflow
page.
Link_checker_cmd_str Path to external link checker char(255)

program.
diff_cmd_str The Windows system command char (255)

required to launch a differencing
tool on the user’s machine. The
user types in this string.
diff_directory Full path to the directory location char (255)

on the user’s machine where the
two files to be differenced will be
downloaded.
intelligent_viewer Full system path to the application char (255)

that will view text-based files. For
example, c:\program files\textpad
4\textpad.exe%1.
checkout_dir Root location of checkout directory. char (255)
default_channel Default delivery cabinet. Should be char (80)

used when checking out a doc to
determine which path to set on the
local machine.
TM
display_pref Indicates whether the file list or char (32)

folder list should be listed first.
Values will include:’file’ or ’folder’.
wip_cache_config Name of the target config object char (80)

that represents a user’s WIP cache
server location. Will only be
defined for Web developers. If one
is not defined, will default to the
wip_cache_config object defined in
the wcm_channel.
web_based_editing True means enable web based boolean

editing. Default is false.
rules_editing If true, use the Rules Editor to boolean

edit the Editor rules file in “Editor
Rules” folder. If false, use external
editor Default is false
Relations
Relations are dm_relation type objects. A relation type object describes a relationship that
can exist between two objects in the Docbase, and can act as an indicator. WebPublisher
uses relations to relate documents and for global content purposes like turning fallback
rules off, and using dynamic content. Please refer to Documentum eContent Server Object
Reference Manual for more information on dm_relation type objects.
WebPublisher creates several dm_relation_type objects. They are:
• DM_TRANSLATION_OF
• wcm_category
• wcm_default_workflow
• wcm_doc_template
• wcm_dynamic_content
• wcm_layout_template
• wcm_my_template
• wcm_process_workflow
• wcm_publishing_template
• wcm_rules_template
• wcm_template_thumbnail
TM
DM_TRANSLATION_OF
WebPublisher uses DM_TRANSLATION_OF to manage global contents.
wcm_category
The organization of the wcm_category objects drives the organization of WebPublisher

categories. The subfolders within the category folder structure that contain templates are
selectable categories for documents. This object is a subtype of dm_folder.
Table 1–12. wcm_category

auto_formats Repeating attribute listing all char (32) repeating
the formats that should be
automatically generated whenever
an object using the associated
category folders is checked in
(for business users) or viewed
via the Web view function (for
Web developers) Values should
be restricted to valid formats that
can be generated by the server.
Currently, only two values, html
and pdf, are supported
a_category Existing property from char (64)

dm_sysobject: Normalized
category name that will be copied
to the current object
cps_node_name Name of a default CPS node to char (128)

use when indexing WebPublisher
objects.
wcm_default_workflow
This relation type tracks the relationship between a template and its default process
workflow.
When an object is created from the template and routed on a process workflow, the
system will check if the template has a wcm_default_workflow relation that points to a
valid process workflow. If so, it will use that process workflow and not prompt the user
for it. The type should be defined as follows:
TM
Table 1–13. wcm_default_workflow
relation_name The name of the relationship. wcm_default_

Names must be unique. The names workflow
of system_defined relationships
begin with dm_. Use this name
to find dm_relation objects of this
kind
integrity_kind Indicates how referential integrity 0

is enforced. Valid values are:
• 0, allow delete
• 1, restrict delete
• 2, cascade delete
direction_kind The direction of the relationship. 0

Valid values are:
• 0, from parent to child
• 1, from child to parent
• 2, bidirectional
parent_type Defines the object type of a valid dm_document

parent object in the relationship.
child_type The object type of valid child dm_process

objects in the relationship
wcm_doc_template
This relation keeps track of the template from which the document was created. This
relation is new to WebPublisher 4.3.
Table 1–14. wcm_doc_template
relation_name Use this name to find dm_relation wcm_doc_template

objects of this kind.
integrity_kind Allow delete. 0
TM
parent_type Valid object type of parent object in dm_document

the relation.
child_type Valid object type of child object in dm_document

the relation.
wcm_dynamic_content
This relation is used to indicate a file that has xDQL queries that need to be transformed.
Documentum marks the Child Label of this relation to CURRENT and uses chronicle
ID as its child ID.
Table 1–15. wcm_dynamic_content
relation_name Use this name to find dm_relation wcm_dynamic_

objects of this kind. content

the relation.

the relation.
wcm_layout_template
The wcm_layout_template relation type tracks the relationship between a data template
and a layout template.
Table 1–16. wcm_layout_template
relation_name Use this name to find dm_relation wcm_layout_

objects of this kind. template
direction_kind Combined with integrity_kind, 1

this restricts deletion of the layout
template object if it is in use
integrity_kind Restrict delete. 1
TM

the relation.

the relation.
wcm_my_template
The wcm_my_template relation type keeps track of a business user’s frequently used
templates and the category each of these templates belongs to. It will allow us to not
only know a favorite template, but also which category the template belonged to. This is
important because a template can be in multiple wcm_category folders.
Table 1–17. wcm_my_template
relation_name Use this name to find dm_relation wcm_my_template

objects of this kind.

the relation.

the relation.
wcm_process_workflow
The wcm_process_workflow relation points from an object to a process workflow object.
Table 1–18. wcm_process_workflow
relation_name Use this name to find dm_relation wcm_process_

objects of this kind. workflow

template object if it is in use.
integrity_kind Cascade delete. 2
TM

the relation.

the relation.
wcm_publishing_template
The wcm_publishing_template relation type tracks the relationship between a standard

template and a publishing template.
Table 1–19. wcm_publishing_template
relation_name Use this name to find dm_relation wcm_publishing_



the relation.

the relation.
wcm_rules_template
The wcm_rules_template relation type tracks the relationship between a data template
and an authoring rules template. It is used to indicate if the Editor rules file is checked
out by the Rules Editor.
Table 1–20. wcm_rules_template
relation_name Use this name to find dm_relation wcm_rules_

TM


the relation.

the relation.
wcm_template_thumbnail
The wcm_template_thumbnail relation is used for relating a thumbnail object to a

file template. The thumbnail displays next to the template in WebPublisher’s ADD
CONTENT page.
Table 1–21. wcm_template_thumbnail
relation_name Use this name to find dm_relation wcm_template_

objects of this kind. thumbnail


the relation.

the relation.
TM
TM
Chapter 2
Customization Overview
WebPublisher customization is accomplished by creating a custom DocApp and modifying

WebPublisher templates and RightSite server and Docbase files. A WebPublisher DocApp contains all
the Docbase components you need to properly run WebPublisher. WebPublisher templates provide
the layout and other non-content related elements such as JavaScript code you need to create a
Web page. RightSite server and Docbase files store all the elements that you need to customization
WebPublisher’s user interface.
This chapter tells you which WebPublisher components can be customized, and which components
should not be customized. Conceptual information for each customizable component is discussed in
this chapter and customization examples for each component are provided in subsequent chapters.
This chapter covers the following topics:
• Components to Customize
• Customization Process
Components to Customize
Components can be anything from DocApp attributes to WebPublisher templates and
files. Components are parts of the WebPublisher system that control WebPublisher
functionality and provide WebPublisher’s look and feel. You can modify the components
to reflect your company’s business processes and appearance.
DocApps
DocApp components include object types, attributes, alias sets, content templates,
lifecycles and workflows. The default WebPublisher DocApp should already be installed
to your Docbase before you begin your customizations.
A DocApp encapsulates Docbase-related objects and processes that are specific to a
business or department. You can build DocApps from scratch, or build DocApps from
WebPublisher’s default DocApp.
TM
To copy custom Docbase-related objects and processes easily from one Docbase to another
you must create a custom DocApp that encapsulates your customizations. Your custom
DocApp could include an object type, attributes, an alias set and permission set template,
a lifecycle, a workflow, and configuration templates all specific to your company’s needs.
You use Documentum Developer Studio (DDS) to create a custom DocApp, and you use
Documentum DocApp Installer to deploy the DocApp to various Docbases.
When you want to customize your WebPublisher installation, you should create a new
custom DocApp containing any customizations. Custom DocApps ensure that your
customizations will not be overwritten by future upgrades to the default WebPublisher
DocApp. You must install the WebPublisher default DocApp before you install your
custom DocApp for WebPublisher to work correctly.
Developing DocApps contains all the information you need to create and deploy a custom
DocApp. Refer to Chapter 9, Creating Process Workflows and Lifecycles for specific
workflow and lifecycle examples.
Object Types and Attributes
An object type is a template for objects (usually documents) that play a special role in a
DocApp. An object type inherits properties from its supertype (usually dm_document or
one of its subtypes). The additions or modifications you make to these properties define
the object type. You create new types to identify characteristics of specific documents as
well as to allow specific lifecycles and workflows to manage them.
Attributes are data items that accompany an object of a given type. Use the type and
attribute editors to define or modify object types.
You might want to create object types that are specific to your company. You can associate
any number of attributes with your object type. In DDS you must associate an object type
with a lifecycle in order to use your custom object type in WebPublisher. Refer to the
Documentum Developer Studio Help for more information about object types and attributes.
WebPublisher Users and Groups
A Docbase user or group with membership in at least one WebPublisher user group.
Each user group provides a different level of functionality. Administrators assign users
to their groups using Documentum Administrator. All users assigned to a group use the
WebPublisher User Default ACL.
WebPublisher provides four user groups:
• Content Authors create, edit and review Web pages using the authoring interface.
• Content Managers can do all of the above, and also manage workflows, using the
authoring interface.
TM
• Web Developers can do all of the above, and also design templates and Web sites,
and generate reports, using the WebPublisher Pro interface.
• Administrators can do all of the above, and also configure WebPublisher and archive
Web sites, using the WebPublisher Pro interface.
When you add users you must following the instructions provided in Using WebPublisher
Pro.
For more information about how to use Documentum Administrator, refer to
Documentum Administrator Online Help.
Alias Sets and Permission Set Templates
Aliases are the parameters of a document lifecycle. They enable you to assign symbolic
names to aspects of the document lifecycle that you expect to differ from one context to
the next. When WebPublisher attaches a document to a lifecycle, it must provide specific
values for all aliases. Alias sets facilitate this process. You create alias sets to encapsulate
aliases for groups and folders. You use these aliases to make your DocApp portable to
other Docbases. For example, you might design a lifecycle using symbolic user names
Reviewer1, Reviewer2, Reviewer3. In one context you can specify:
• Reviewer1 = Linda
• Reviewer2 = Ed
• Reviewer3 = Denise
In another context, you can assign different user names to these symbolic names. The
assignment of an actual user, group, permission set, or Docbase cabinet or folder to a
symbolic name is called an alias. The actual value is called the alias value. A collection
of aliases is called an alias set.
You create permission set templates (also called ACLs) that assign permissions to the
users and folders. By default, a user’s default permission set template is assigned to
any new documents that the user creates. A permission set template that is specified
for a folder regulates operations on objects within the folder, such as creating, moving,
deleting, and copying objects. If you are reusing a DocApp and deploying it to another
Docbase that services a different set of users in your company, permission set templates
are of great utility.
Process Workflows and Document Lifecycles
WebPublisher uses process workflows to automatically promote routed content to a

different lifecycle state when a workflow task recipient forwards routed content to the
next workflow recipient. All WebPublisher process workflows must begin with a Start
task and end with a Cleanup task. The Start task ensures that while a file is active in
TM
the process workflow, it is restricted from being sent to another workflow until it is
complete. The Cleanup task releases the restriction.
Administrators create process workflows in advance and make these workflows
available to users. Refer to Using WebPublisher Pro for more information about workflows
and Chapter 9, Creating Process Workflows and Lifecycles for an example custom workflow.
A document lifecycle encodes business rules for changes in the properties of an object as
it moves through the stages of its life (for example, review, publishing, and end-of-life).
All WebPublisher lifecycles have a minimum of four lifecycle states. Those states are
Start, WIP, Staging, and Approved. An administrator can create new lifecycles with
additional states between the WIP and Approved states, and can change the names of
these default states.
The Expired state is not part of the configured lifecycle object, but is based on property
values of the content object. Refer to Using WebPublisher Pro for more information about
lifecycles.
Testing your Custom DocApp
After you have created a custom DocApp and DocApp archive in DDS, install the
DocApp archive to your WebPublisher Docbase, create a template, and test your lifecycle
and workflow.
Once you install the DocApp archive to your WebPublisher Docbase, you must connect
to WebPublisher as an Administrator or Web developer and add the workflow. Refer to
Using WebPublisher Pro for step-by-step instructions to add a workflow.
Testing Your Lifecycle and Workflow
To test your lifecycle, connect to your Docbase from WebPublisher, create a new template
using a custom object type and lifecycle, add content to your custom template, and
promote the content through the lifecycle.
To test your workflow connect to your Docbase from WebPublisher, import a custom
content template, promote the content to the WIP state, and insert your content into
your custom workflow.
If you receive errors then you need to return to DDS to examine your lifecycle and
workflow.
Packaging and Deploying DocApps to Other Docbases
You can package a DocApp into an archive that you can deploy to other Docbases. If you
are reusing the DocApp and deploying it to another Docbase that services a different set
of users in your company, permission set templates are of great value. When you install
TM
the DocApp archive to a Docbase, you are prompted to provide values (user names,
groups, cabinets, or directories) for the aliases in your DocApp.
Existing Alias Sets
If an error message appears stating that an alias already exists, it means that you have
aliases defined in your Docbase with the same name as one that you are trying to install.
Use Documentum Administrator to delete the duplicate aliases and reinstall the DocApp.
WebPublisher Editor Templates

WebPublisher Editor templates are used to create XML and HTML content that authors
then edit using WebPublisher Editor, WebPublisher’s built-in editing application.
WebPublisher Editor templates must have an associated Editor presentation file, which
is an XSL stylesheet. You can associate an Editor presentation file to more than one
template, and you can associate an Editor rules file to more than one template. You can
associate more than one Editor presentation file to a single template.
The content template and Editor rules file work together to enable authors to enter
content in WebPublisher Editor. The content file, in to which authors enter information,
and Editor presentation file work together to display content on a Web page. The
thumbnail file enables a graphical representation of a template.
Web developers can create templates in any appropriate authoring application
(FrontPage, Notepad) and import them in to a Docbase (or DocApp if you want to
deploy the templates to multiple Docbases).
When the DocApp is installed to the Docbase, templates are also installed.
To insert templates and files into a custom DocApp:
1. Start Documentum Developer Studio by choosing Start>Program

Files>Documentum>Developer Studio.
You are prompted to connect to a Docbase.
2. Change your Docbase to the Docbase in which the custom DocApp is installed.
3. Type your username and password, and domain (if required), and then click Connect.
You must have Superuser privileges to edit the DocApp.
You are prompted to create a new DocApp, open the custom DocApp from the
Docbase or local file system.
4. Click Open Existing DocApp from Docbase.
You are prompted to choose an existing DocApp from the Docbase.
5. Select the custom DocApp from the Open Application window, and click Open.
6. Choose Insert>Object From Docbase>Cabinet.
TM
7. Click Select and navigate to the WebPublisher Configuration cabinet.

This is the cabinet that contains the WebPublisher Editor templates and files.
8. Click Insert, and then Next.
9. Select the permission set alias to apply to this cabinet, and click Finish.
The WebPublisher Configuration cabinet is inserted into the custom DocApp under
the Data Objects folder. Refer to the Documentum Developer Studio Help for more
information on alias sets.
You should now insert two default WebPublisher object types. You need these object
types because Developer Studio will not archive objects that are based on a custom
type unless the type definition is included in the DocApp. If you do not have the
type in the DocApp, then the delivery cabinet, folders within the delivery cabinet,
system configuration, and category folders will not get archived. This is true for any
custom object types you create.
10. Choose Insert>Object From Docbase>Object Type.
11. Select the object type to insert, and click Insert.
The four default WebPublisher object types are:
• wcm_category
• wcm_channel
• wcm_channel_fld
• wcm_config
12. Create a DocApp archive, or update your existing DocApp with the new cabinet
and object types.
Refer to Packaging and Deploying DocApps to Other Docbases to create a DocApp
archive and deploy it to a Docbase.
Web Server Files and Docbase Files

WebPublisher files include XML files stored on your Web (HTTP) server and in your
WebPublisher Docbase. To customize files on your Web server, you copy the file (to
be customized) to a custom folder in the WebPublisher hierarchy on your Web server
and modify the copied file so that it contains your desired customization. Subsequent
chapters in this guide discuss XML file customizations for such components as the
PROPERTIES page, SEARCH page, and Action list.
Files controlling default WebPublisher behavior reside in the
\RightSite\applications\wcm\product directory. Files used to customize the default
WebPublisher behavior reside in the \RightSite\applications\wcm\custom\default
directory and should mirror the folder hierarchy under the product directory. RightSite
uses any customizations that exist in the custom folder instead of standard files in the
product folder. Refer to Chapter 1, Functional Overview and Architecture for more
information on file hierarchy.
TM
Existing Web Sites

manage them in a central location. This guide will discuss the Acelerra Web site and
describe in detail how to create a custom Web site using WebPublisher templates.
Browser Settings
To correctly display your WebPublisher customizations in Web browsers you must
configure your Web browser with specific settings.
WebPublisher supports multiple browsers through either multiple presentation files
or templates, and generates multiple renditions from single content objects. These
renditions can be HTML-based renditions viewed through a standard HTML browser, or
they can be HTML files viewed on WebTV or for WML (Wireless Markup Language)
renditions viewed through a WAP browser (for eventual viewing on a wireless device
such as a cell phone or PDA). Web developers define the applications used to view
alternate Web renditions by selecting the correct format in their Web browser and typing
the path to the viewing application.
Components to Customize
Components can be anything from DocApp attributes to WebPublisher templates and
files. Components are parts of the WebPublisher system that control WebPublisher
functionality and provide WebPublisher’s look and feel. You can modify the components
to reflect your company’s business processes and appearance.
DocApps
DocApp components include object types, attributes, alias sets, content templates,
lifecycles and workflows. The default WebPublisher DocApp should already be installed
to your Docbase before you begin your customizations.
business or department. You can build DocApps from scratch, or build DocApps from
WebPublisher’s default DocApp.
To copy custom Docbase-related objects and processes easily from one Docbase to another
you must create a custom DocApp that encapsulates your customizations. Your custom
DocApp could include an object type, attributes, an alias set and permission set template,
a lifecycle, a workflow, and configuration templates all specific to your company’s needs.
TM
You use Documentum Developer Studio (DDS) to create a custom DocApp, and you use
Documentum DocApp Installer to deploy the DocApp to various Docbases.
When you want to customize your WebPublisher installation, you should create a new
custom DocApp containing any customizations. Custom DocApps ensure that your
customizations will not be overwritten by future upgrades to the default WebPublisher
DocApp. You must install the WebPublisher default DocApp before you install your
custom DocApp for WebPublisher to work correctly.
Developing DocApps contains all the information you need to create and deploy a custom
DocApp. Refer to Chapter 9, Creating Process Workflows and Lifecycles for specific
workflow and lifecycle examples.
Object Types and Attributes
An object type is a template for objects (usually documents) that play a special role in a
DocApp. An object type inherits properties from its supertype (usually dm_document or
one of its subtypes). The additions or modifications you make to these properties define
the object type. You create new types to identify characteristics of specific documents as
well as to allow specific lifecycles and workflows to manage them.
Attributes are data items that accompany an object of a given type. Use the type and
attribute editors to define or modify object types.
You might want to create object types that are specific to your company. You can associate
any number of attributes with your object type. In DDS you must associate an object type
with a lifecycle in order to use your custom object type in WebPublisher. Refer to the
Documentum Developer Studio Help for more information about object types and attributes.
WebPublisher Users and Groups
A Docbase user or group with membership in at least one WebPublisher user group.
Each user group provides a different level of functionality. Administrators assign users
to their groups using Documentum Administrator. All users assigned to a group use the
WebPublisher User Default ACL.
WebPublisher provides four user groups:
• Content Authors create, edit and review Web pages using the authoring interface.
• Content Managers can do all of the above, and also manage workflows, using the
• Web Developers can do all of the above, and also design templates and Web sites,
and generate reports, using the WebPublisher Pro interface.
• Administrators can do all of the above, and also configure WebPublisher and archive
Web sites, using the WebPublisher Pro interface.
TM
When you add users you must following the instructions provided in Using WebPublisher
Pro.
For more information about how to use Documentum Administrator, refer to
Documentum Administrator Online Help.
Alias Sets and Permission Set Templates
Aliases are the parameters of a document lifecycle. They enable you to assign symbolic
names to aspects of the document lifecycle that you expect to differ from one context to
the next. When WebPublisher attaches a document to a lifecycle, it must provide specific
values for all aliases. Alias sets facilitate this process. You create alias sets to encapsulate
aliases for groups and folders. You use these aliases to make your DocApp portable to
other Docbases. For example, you might design a lifecycle using symbolic user names
Reviewer1, Reviewer2, Reviewer3. In one context you can specify:
• Reviewer1 = Linda
• Reviewer2 = Ed
• Reviewer3 = Denise
In another context, you can assign different user names to these symbolic names. The
assignment of an actual user, group, permission set, or Docbase cabinet or folder to a
symbolic name is called an alias. The actual value is called the alias value. A collection
of aliases is called an alias set.
You create permission set templates (also called ACLs) that assign permissions to the
users and folders. By default, a user’s default permission set template is assigned to
any new documents that the user creates. A permission set template that is specified
for a folder regulates operations on objects within the folder, such as creating, moving,
deleting, and copying objects. If you are reusing a DocApp and deploying it to another
Docbase that services a different set of users in your company, permission set templates
are of great utility.
Process Workflows and Document Lifecycles
WebPublisher uses process workflows to automatically promote routed content to a

different lifecycle state when a workflow task recipient forwards routed content to the
next workflow recipient. All WebPublisher process workflows must begin with a Start
task and end with a Cleanup task. The Start task ensures that while a file is active in
the process workflow, it is restricted from being sent to another workflow until it is
complete. The Cleanup task releases the restriction.
Administrators create process workflows in advance and make these workflows
available to users. Refer to Using WebPublisher Pro for more information about workflows
and Chapter 9, Creating Process Workflows and Lifecycles for an example custom workflow.
TM
A document lifecycle encodes business rules for changes in the properties of an object as
it moves through the stages of its life (for example, review, publishing, and end-of-life).
All WebPublisher lifecycles have a minimum of four lifecycle states. Those states are
Start, WIP, Staging, and Approved. An administrator can create new lifecycles with
additional states between the WIP and Approved states, and can change the names of
these default states.
The Expired state is not part of the configured lifecycle object, but is based on property
values of the content object. Refer to Using WebPublisher Pro for more information about
lifecycles.
Testing your Custom DocApp
After you have created a custom DocApp and DocApp archive in DDS, install the
DocApp archive to your WebPublisher Docbase, create a template, and test your lifecycle
and workflow.
Once you install the DocApp archive to your WebPublisher Docbase, you must connect
to WebPublisher as an Administrator or Web developer and add the workflow. Refer to
Using WebPublisher Pro for step-by-step instructions to add a workflow.
Testing Your Lifecycle and Workflow
To test your lifecycle, connect to your Docbase from WebPublisher, create a new template
using a custom object type and lifecycle, add content to your custom template, and
promote the content through the lifecycle.
To test your workflow connect to your Docbase from WebPublisher, import a custom
content template, promote the content to the WIP state, and insert your content into
your custom workflow.
If you receive errors then you need to return to DDS to examine your lifecycle and
workflow.
You can package a DocApp into an archive that you can deploy to other Docbases. If you
are reusing the DocApp and deploying it to another Docbase that services a different set
of users in your company, permission set templates are of great value. When you install
the DocApp archive to a Docbase, you are prompted to provide values (user names,
groups, cabinets, or directories) for the aliases in your DocApp.
TM
Existing Alias Sets
WebPublisher Editor Templates

WebPublisher Editor templates are used to create XML and HTML content that authors
then edit using WebPublisher Editor, WebPublisher’s built-in editing application.
WebPublisher Editor templates must have an associated Editor presentation file, which
is an XSL stylesheet. You can associate an Editor presentation file to more than one
template, and you can associate an Editor rules file to more than one template. You can
associate more than one Editor presentation file to a single template.
thumbnail file enables a graphical representation of a template. Refer to Using
WebPublisher Pro for more information about using WebPublisher the templates and files,
and Chapter 10, Creating a Web Site for an example Web page.
Web developers create templates in any appropriate authoring application (FrontPage,
Notepad) and import them in to a Docbase (or DocApp if you want to deploy the
templates to multiple Docbases).
To insert your templates and files into a custom DocApp:
1. Start Documentum Developer Studio by choosing Start>Program

Files>Documentum>Developer Studio.
You are prompted to connect to a Docbase.
Change your Docbase to the Docbase in which the custom DocApp is installed.
2. Type your username and password, and domain (if required), and then click Connect.
You must have Superuser privileges to edit the DocApp.
You are prompted to create a new DocApp, open the custom DocApp from the
Docbase or local file system.
3. Click Open Existing DocApp from Docbase.
You are prompted to choose an existing DocApp from the Docbase.
4. Select the custom DocApp from the Open Application window, and click Open.
5. Choose Insert>Object From Docbase>Cabinet.
6. Click Select and navigate to the WebPublisher Configuration cabinet.
TM
This is the cabinet that contains the WebPublisher Editor templates and files.
7. Click Insert, and then Next.
8. Select the permission set alias to apply to this cabinet, and click Finish.
The WebPublisher Configuration cabinet is inserted into the custom DocApp under
the Data Objects folder. Refer to the Documentum Developer Studio Help for more
information on alias sets.
You should now insert two default WebPublisher object types. You need these object
types because Developer Studio will not archive objects that are based on a custom
type unless the type definition is included in the DocApp. If you do not have the
type in the DocApp, then the delivery cabinet, folders within the delivery cabinet,
system configuration, and category folders will not get archived. This is true for any
custom object types you create.
9. Choose Insert>Object From Docbase>Object Type.
10. Select the object type to insert, and click Insert.
The four default WebPublisher object types are:
• wcm_category
• wcm_channel
• wcm_channel_fld
• wcm_config
11. Create a DocApp archive, or update your existing DocApp with the new cabinet
and object types.
Refer to Packaging and Deploying DocApps to Other Docbases to create a DocApp
archive and deploy it to a Docbase.
Web Server Files and Docbase Files

WebPublisher files include XML files stored on your Web (HTTP) server and in your
WebPublisher Docbase. To customize files on your Web server, you copy the file (to
be customized) to a custom folder in the WebPublisher hierarchy on your Web server
and modify the copied file so that it contains your desired customization. Subsequent
chapters in this guide discuss XML file customizations for such components as the
PROPERTIES page, SEARCH page, and Action list.
Files controlling default WebPublisher behavior reside in the
\RightSite\applications\wcm\product directory. Files used to customize the default
WebPublisher behavior reside in the \RightSite\applications\wcm\custom\default
directory and should mirror the folder hierarchy under the product directory. RightSite
uses any customizations that exist in the custom folder instead of standard files in the
product folder. Refer to Chapter 1, Functional Overview and Architecture for more
information on file hierarchy.
TM
Existing Web Sites

manage them in a central location. This guide will discuss the Acelerra Web site and
describe in detail how to create a custom Web site using WebPublisher templates.
Browser Settings
To correctly display your WebPublisher customizations in Web browsers you must
configure your Web browser with specific settings.
WebPublisher supports multiple browsers through either multiple presentation files
or templates, and generates multiple renditions from single content objects. These
renditions can be HTML-based renditions viewed through a standard HTML browser, or
they can be HTML files viewed on WebTV or for WML (Wireless Markup Language)
renditions viewed through a WAP browser (for eventual viewing on a wireless device
such as a cell phone or PDA). Web developers define the applications used to view
alternate Web renditions by selecting the correct format in their Web browser and typing
the path to the viewing application.
Customization Process
Customization Guidelines
This section discusses some guidelines for a customization strategy and methodology.
Before you begin a customization project, you should understand how the WebPublisher
directory structure is arranged and the basic functionality of the WebPublisher Web
server components.
You customize WebPublisher functionality on the Web server. You create a folder
structure under the custom directory on your file system and modify files in the custom
directory. The custom folder structure and file location must parallel the folder structure
and file location from the product folder or the customizations will not be picked up
by the dispatcher.
Note: Do not customize files in the product directory, but instead copy the hierarchy of
folders you want to work on into the custom directory, and customize them there.
If you are adding or modifying any images you must copy the entire images directory to
the custom directory structure.
TM
Warning If you make customizations in the product directory, they will be overwritten
when you upgrade.
The customizations you create can apply to all Docbases or specific Docbases. If you
want your customization to apply to all Docbases, copy the appropriate subfolders
into the \custom\default folder that parallels the product directory structure for that
feature. If you want a customization to apply only to a specific Docbase, you must create
a folder at the same level as the default folder, name it with the name of the Docbase to
which you want the customization to apply, and copy the appropriate subfolders into the
\custom\<Docbase> folder that parallels the product directory structure for that feature.
For example, if you have a Docbase called Corporate_Development and you want to
customize the cabinet view for all users who connect to that Docbase, you would create
the following directories to make sure your customization only applies to that particular
Docbase.
To create a custom folder:
1. Create a folder under the \wcm\custom directory named Corporate_Development.

2. Under \wcm\custom\Corporate_Development, create the hierarchy needed for the
feature you want to customize.
Files that you customize are stored locally on your Web server not in the Docbase.
Customized files apply either at the RightSite installation level (meaning that the
customization applies to all Docbases, groups, and users), or at the Docbase level
(meaning that the customization applies to all groups and users connected to a specific
Docbase), or to both. You can additionally customize features based on the user level,
for example content author, content manager, or Web developer using an .ebs file, or
user inclusion in a Docbase group.
Creating Customizations for Subtypes
You may want to create a subtype to customize for your specific application of
WebPublisher. If you have created a subtype to use with WebPublisher you must store
the subtype in the proper location on the Web server.
A subtype is a child of an object type and can inherit the feature of its supertype. For
example, if SOP is a subtype of dm_document and the ACTIONS page for both types has
the same features then you do not need to create an SOP ACTIONS page directory. The
dispatcher automatically picks up all the needed components from the dm_document
directory.
On the other hand, if an SOP’s ACTIONS page needs to vary from its supertype’s
then you must create an actions\sop folder under your custom\default folder and
copy or create those components that are different from the supertype. For example, if
export is not available for this type, then only the actions.xml file needs to be copied to
the actions\sop folder and modified by taking out the export_object feature; all other
components of this feature are automatically picked up from the supertype directories.
TM
Any component file that needs to be shared among all the subtypes resides in the
feature’s base directory. For example, because all title blocks share the same start.htm
file this file is placed in the wcm\product\titles folder.
Customizing Features
Following are some examples on customizing WebPublisher features. The examples tell
you which files you need to copy and modify.
Key Features: Viewing or Updating Attributes
Using WebPublisher, you can view or change the attributes of objects. The forms that
make up these features are located in wcm\product\views\attributes. There is a
subfolder for each object type: dm_cabinet, dm_folder, dm_document, dm_sysobject.
For example, when you view the attributes of a document, you see the form
wcm\product\views\attributes\start.htm in the main frame.
The start.htm page displays a title block from wcm\product\titles\start.htm
at the top, the PROPERTIES page for the object, and a standard footer from
wcm\product\footers\default.htm at the bottom.
If you change any attributes and then click Save Changes a standard success page is
displayed briefly to indicate that your changes have successfully been applied to the
object . You are then returned to the originating screen, for example, the contents view of
the folder, which contains the document.
Key Features: Dictionary
In order to separate literal strings displayed in a page from the HTML layout and
logic of a feature, WebPublisher provides a facility for feature pages to access strings
from a dictionary.htm file. If the strings are specific to a feature they are placed in
the feature’s base directory for example, cancel checkout. If they need to be accessed
from multiple features in the system, they are placed in the global dictionary in
wcm\product\dictionary.htm. The dictionary items are RightSite variables that are
declared and accessed using DMW_DECLARE in a dictionary.htm file.
The dictionary.htm file is also useful for software localization. Because the dictionary.htm
file contains numerous strings that need to be translated, the translator only needs to
access this one file instead of several files.
Key Features: Using Confirmation, Success, and Failure Pages
WebPublisher provides many centralized services that are accessed throughout the
product. Success, failure, and confirmation pages constitute one such service. This
TM
service only requires the feature to set specific RightSite variables and then include the
confirmation, success, or failure page using DMW_INCLUDE or DMW_DECLARE
methods. Alternatively, you can specify DMW_APP_SUCCESS for DMW_INPUTFORM
and DMW_APP_FAILURE for DMW_ON_ERROR in a form hidden input field when
calling a RightSite method. You can also call a script that sets the variables using
dwSetVar().
Customizing Features: Using XML
WebPublisher uses information in XML files to configure various WebPublisher features.

XML files are ASCII files, so you can edit them using a text editor or an off-the-shelf XML
editor. An XML file looks very similar to an HTML page except WebPublisher defines
the tags that are used. In WebPublisher, XML files define data to be used, not how to
display and format the output.
The code fragment below is extracted from WebPublisher’s views\attributes\dm_
document\attributes.xml file, which defines a PROPERTIES page that is further divided
into a section named editablegroups and a section named viewonlygroups. Each of these
sections can contain groups of attributes, described by the name of the object’s attribute,
such as object_name. You can log in to WebPublisher, as a content author or content
manager, and take a look at the dm_document PROPERTIES page to see how the screen
displays the exact configuration listed below.
<editablegroups>
<group>
<attributelist>
<attribute>
<name>object_name</name>
<label>MSG_ATTR_LABEL_OBJECT_NAME</label>
</attribute>
<attribute>
<name>title</name>
<label>MSG_ATTR_LABEL_TITLE</label>
</attribute>
<attribute>
<name>subject</name>
</attribute>
<attribute show_all_values="true" display_control="select">
<name>keywords</name>
</attribute>
<attribute show_all_values="true">
<name>authors</name>
</attribute>
<attribute>
<name>a_effective_date</name>
<label>MSG_ATTR_LABEL_EFFECTIVE_DATE</label>
<validate_attr_script>donot_show_in_change_set</validate_attr_script>
TM
</attribute>
<attribute>
<name>a_expiration_date</name>
<label>MSG_ATTR_LABEL_EXPIRATION_DATE</label>
</attribute>
<attribute>
<name>a_category</name>
</attribute>
<name>a_publish_formats</name>
<label>MSG_ATTR_LABEL_PUBLISH_FORMATS</label>
<info_string>MSG_ATTR_INFO_LABEL_PUBLISH_FORMATS</info_string>
</attribute>
<attribute display_control="textarea" default_textarea_rows=
"3"textarea_wrap="true">
<name>log_entry</name>
<label>MSG_ATTRIBUTES_COMMENTS</label>
</attribute>
</attributelist>
</group>
</editablegroups>
As you can see, each element must have a start and an end tag. Each element may
contain element attributes, not to be confused with Docbase object type attributes as well
as other elements, in the form of:
<element element_attribute="some_value"
<element >
:
</element >
</element >
For example:
<attributelist>
</attribute>
</attributelist>
In this example, attributelist is an element, attribute is an attribute under attributelist,

and show_all_values is an element attribute.
Changing the atttibutes.xml configuration file causes the PROPERTIES page to reflect the
new setting. For example if you remove the elements that specify the subject attribute
and reload your PROPERTIES page, you will notice that the subject attribute is no longer
displayed. Similarly, if you replace subject with keywords and reload the page you will
see the keywords attribute value displayed instead of subject.
TM
Customizing the History Mechanism
If you are developing a custom view or operation you should have some familiarity with
the history mechanism. This mechanism is used to identify the view you can return to
after an operation completes. The display data is retrieved from the Docbase every
time the data is requested.
The success page interacts with the history mechanism to automatically return you to the
appropriate view. Here is an example of a success page’s interaction with the history
mechanism. An operation may require you to perform several steps. Each of those steps
display in a different frame set. If the operation completes successfully you want to be
returned to a logical view such as the beginning of the procedure. The success operation
enables this return to happen by destroying the middle steps of an operation so the
history mechanism cannot read the pages in between the success page and the start
procedure page. The failure page works in a similar way destroying middle pages to
return you to the start procedure page to redo the procedure.
An operation can change the state of an object by:
• modifying a property value
• saving a new version of a document
• creating a new object by importing a file
• deleting an object by deleting a version of a document.
In these cases we need to set specific RightSite session variables before DMW_INCLUDE
calls the success page.
If you use the success page without setting these RightSite session variables, the
view of the last cabinet or folder is automatically refreshed from Docbase data.
RightSite session variables are set in the dictionary.htm file for each specific operation.
For example, a success session variable for a check in operation would be set in
wcm\product\operations\checkin\dictionary.htm and look as follows:
<DMW_DECLARE NAME="SUCCESS_SHOW_OBJECT_ICON" SCOPE=
"SESSION" VALUE="true">
If an operation deletes an object, it should set two RightSite session variables:

• SUCCESS_OPER_PERFORM should be set to delete.
• SUCCESS_OPER_OLD_ID should be set to the ID of the object that was deleted.
If an operation creates a new object that needs to be displayed, it should set two RightSite
session variables:
• SUCCESS_OPER_PERFORM should be set to new.
• SUCCESS_OPER_NEW _ID should be set to the ID of the object that was created.
If an operation does not alter the state of an object and does not create or delete an object,
only one RightSite session variable needs to be set:
• SUCCESS_OPER_PERFORM should be set to unchanged.
TM
In the save operation a new object is created, which should be displayed in place of the
old object. In this case three RightSite session variables should be set:
• SUCCESS_OPER_PERFORM should be set to replace.
• SUCCESS_OPER_OLD_ID should be set to the ID of the old object.
• DMW_NEW_OBJECTID is set to the ID of the newly saved object. This variable is
actually set by RightSite when you invoke the checkin method.
For a view to use the information set up by the operation, history_utils.ebs defines three
public functions:
• writeContainerRequestToBrowser:
called from start.htm located in wcm\product\titles. This function adds a URL
for the current view to the history list so you can return to it when an operation
successfully completes.
<DMW_EXEC
EXECTYPE="Docbasic"
FILE="<DMW_SUBST NAME ="DMW_APP_SCRIPTS_DIR">history_utils.ebs"
ARGUMENT="-ewriteContainerRequestToBrowser"
ARGUMENT="-p"
>
• writeFolderAncestorIDsToBrowser:
called from start.htm of every view located in wcm\product\views\contents, such
as dm_folder. This function stores information about the two most recent content
views you have visited, so if a folder is deleted as part of an operation we can return
to that folder’s parent folder.
<DMW_EXEC
EXECTYPE="Docbasic"
ARGUMENT="-ewriteFolderAncestorIDsToBrowser"
>
• writeContentsCheckToBrowser:
called from start.htm of every content view located in wcm\product\views\contents,
such as dm_folder. This function refreshes the content view if the content of the
container has changed in any way. It makes this determination based on information
passed to it by the last operation performed.
<DMW_EXEC
EXECTYPE="Docbasic"
ARGUMENT="-ewriteContentsCheckToBrowser"
Most of the time you do not need to modify the start.htm file for a content view. If you
want to modify start.htm, copy an existing start.htm file and make changes to it. This
TM
way you do not need to decide where to enter calls for the functions mentioned above
since the calls are already in the file you have copied.
Customizing the Dispatcher
When customizing WebPublisher you should never hard-code a URL for a feature or the
dispatcher. Use one of the central Docbasic routines, documented in scripts\readme.txt,
that constructs the desired URL based on parameters you pass to it. This ensures that if
the syntax of the product’s URL changes your code will continue to function correctly.
URLs the Dispatcher Can User
The dispatcher acquires information it needs from a URL which, like a RightSite method
URL with an implied formexec, calls for a preliminary file. For information about
RightSite method URLs, refer to RightSite Reference Manual.
This URL can also include arguments in name=value pairs for the dispatcher to use
when further processing the request, for example:
/RightSite.dll/
wcm?view=contents&type=dm_cabinet&id=0c00000abcd23456
These name=value pairs not only include information that the dispatcher needs, but can
include any other name=value pairs that the customized feature needs. The dispatcher
uses a DMW_INCLUDE statement to provide the form that starts the customized feature,
it can pass all the information in the URL to the first form. However, the dispatcher is
responsible only for getting you to the first HTML form template in the customization.
After that, any further information needed in the feature must be provided by the user,
set as a session variable, or passed from page to page. For information about variables,
refer to the RightSite Reference Manual.
The dispatcher looks for the arguments and their values as shown in the following table.
Several other RightSite and WebPublisher preliminary file environment variables that
the dispatcher may need are also supported.
Table 2–1. Dispatcher Arguments and Values
Argument Values
operation The name of the feature under the operations directory.
view The name of the feature and subfolder under the views directory.
TM
Argument Values
type The name of the subfolder under the feature subfolder defined by
either operation or view. If there is no value for operation or view
then this is ignored. If view\operation has a value, but type is
missing, id\DMW_OJBECTID is examined for its Documentum
object typename. The typename is then used as the value of type. If
the value of type does not match any subfolder, the type’s parent
typename is tried, and so on until a match is found. Then, if no
match is found, the dispatcher looks for a subfolder named default
under the feature and uses that. If this is missing as well, an error
message is issued indicating why the request could not be resolved.
entry (defaults to start.htm) The template form name that the dispatcher
calls with DMW_INCLUDE when the appropriate subfolder is
found.
error The template form name that the dispatcher calls with
DMW_INCLUDE when the eflag has been set to YES by the
vsi_error and ssi_error preamble. If this form is missing, the generic
error form is called using DMW_INCLUDE.
eflag This is set to YES when RightSite calls the error preamble (which
is the value of the optional DMW_ON_ERROR RightSite method
argument). If it is set to "YES", the dispatcher processes the request
as a feature error handler instead of the feature entry point.
help This value is optional. It points to the feature specific Help

template. If set, the dispatcher knows to process the request as a
feature Help request instead of the feature entry point.
trace This value is optional when it is set to YES. It instructs the

dispatcher and feature to dump debugging info into the return
stream as HTML comments. These comments are visible when the
end-user chooses View>Page Source in Netscape, or View>Source
in Internet Explorer on the returned, processed page.
id Equals the value of DMW_OBJECTID if not explicitly set. The value

of the Documentum object id for the object to which the request
pertains. Only set for operations and views on a particular object.
Several other RightSite and WebPublisher preliminary file environment variables that
the dispatcher may need are also supported.
Paths, URLs and Other Variables the Dispatcher Sets Up
Almost all environment variables that the dispatcher sets begin with DMW_APP.
The directory environment variables all end in "_DIR" and specify an operating system
file’s system directory path. These paths always end with a trailing path separator (a
slash). The direction that the slash goes (forward slash or backslash) depends on the
TM
operating system of the server that RightSite is installed on. The standard is usually "/"
for UNIX systems and "\" for Windows systems.
The path environment variables all end in "_PATH" and specify the URL namespace
path recognized by the Web server.
By definition, URL paths do not necessarily match the string of the corresponding file
system directory.
The following table lists the environment variables that you may encounter when
implementing your customizations:
Table 2–2. Environment Variables
Implementation Variable Name Description
DMW_APP_SCRIPTS_DIR Directory containing all global

Docbasic scripts used throughout
the product.
DMW_APP_ICONS_DIR Directory containing all

application-common graphic
files for DMW_INCLUDE
statements.
DMW_APP_ICONS_PATH URL path to all

files.
DMW_APP_DIALOG_HEADER_DIR Directory for the central

operation dialog header
fragment for DMW_INCLUDE
statements.
DMW_APP_TITLES_START_DIR Directory for the titles

area fragment files for
DMW_INCLUDE statements.
DMW_APP_FOOTERS_DIR Directory containing all

footer fragment files for
DMW_APP_OBJ_DISPLAY_TYPE Type of object currently being

processed. Set up so the feature
can easily access it instead of
having to get the value from the
URL.
DMW_APP_OBJ_NAME Name of object currently being

processed. Set up so the feature
can easily access it instead of
having to get the value from the
URL.
TM
Implementation Variable Name Description
DMW_APP_SUCCESS_DIALOG_DIR Directory that contains the

central success page for
DMW_APP_FAILURE_DIALOG_DIR Directory that contains the

central failure page for
DMW_APP_CONFIRMATION_DIALOG_DIR Directory that contains the

central confirmation page for
DMW_APP_STYLESHEET_DIR Directory that contains the

cascading stylesheet for
WebPublisher.
DMW_APP_STYLESHEET_PATH URL path to the cascading

stylesheet.
DMW_APP_STATUS_DIALOG_DIR Directory that contains

the central status page for
These environment variables can be accessed in an HTML template using DMW_SUBST,

and from Docbasic using dwGetVar().
Additionally, several Docbasic global variables are set up so you can access them from
Docbasic routines without having to retrieve them using dwGetVar():
Table 2–3. Docbasic Global Variables
Docbasic Global Variable Name Description
GDMW_APP_SCRIPTS_DIR Directory containing all global

the product.
DMW_APP_ICON_DIR Directory containing all

statements.
GDMW_APP_ICONS_PATH URL path to all application-

common graphic files.
GDMW_APP_FONT_FACE Font, set up as part of the

application theme, used in all
 HTML tags.
gCurrentWCMGroupName Group, to which the current user

belongs.
TM
gCONTENT_AUTHOR_GROUP Group, that designates a user as

content author. Set to content
author.
gCONTENT_MANAGER_GROUP Group, that designates a user as

content manager. Set to content
manager.
gWEB_DEVELOPER_GROUP Group, that designates a user

as a Web developer. Set to Web
developer.
gADMINISTRATOR_GROUP Group, that designates a user

as an administrator. Set to
administrator.
gWIP_SYMBOL The label, WIP, marks an object

as Work In Progress. The label
is defined in the WebPublisher’s
system configuration object.
gSTAGING_SYMBOL The label, STAGING, marks

an object as in the Staging
area. The label is defined in
the WebPublisher’s system
configuration object.
gAPPROVED_SYMBOL The label, APPROVED, marks

an object as Approved. The label
is defined in the WebPublisher’s
gACTIVE_SYMBOL The label, ACTIVE, marks an

object as Active. The label is
defined in the WebPublisher’s
ystem configuration object.
gEXPIRED_SYMBOL The label, EXPIRED, marks an

object as Expired. The label is
defined in the WebPublisher’s
DMW_APP_SCRIPTS_DIR Directory containing all global

the product.
DMW_APP_ICONS_DIR Directory containing all

statements
TM
DMW_APP_ICONS_PATH URL path to all application-

common graphic files.
DMW_APP_DIALOG_HEADER_DIR Directory for the central operation

dialog header fragment for
DMW_APP_TITLES_START_DIR Directory for the titles

area fragment files for
DMW_APP_FOOTERS_DIR Directory containing all

footer fragment files for
DMW_APP_OBJ_DISPLAY_TYPE Type of object currently being

processed; this is set up so the
feature can easily access it instead
of having to get the value from
the URL.
DMW_APP_OBJ_NAME Name of object currently being

processed; this is set up so the
feature can easily access it instead
of having to get the value from
the URL.
DMW_APP_SUCCESS_DIALOG_DIR Directory that contains the

central success page for
DMW_APP_FAILURE_DIALOG_DIR Directory that contains the central

failure page for DMW_INCLUDE
statements.
DMW_APP_CONFIRMATION_DIALOG_DIR Directory that contains the

central confirmation page for
DMW_APP_STYLESHEET_DIR Directory that contains the

cascading stylesheet for
WebPublisher.
DMW_APP_STYLESHEET_PATH URL path to the cascading

stylesheet.
DMW_APP_STATUS_DIALOG_DIR Directory that contains the central

status page for DMW_INCLUDE
statements.
These global variables can be accessed in an HTML template using DMW_SUBST.
TM
Using Variables Set Up by The Dispatcher
The following are examples of how to use some of the dispatcher-set variables:
Public gDMW_APP_SCRIPTS_DIR As String
:
:
ret = external(gDMW_APP_SCRIPTS_DIR & "utils.ebs")
Call getVersionLabels(id, theLabels)
<DMW_EXEC
EXECTYPE="Docbasic"
FILE="<DMW_SUBST NAME="DMW_APP_SCRIPTS_DIR">process_page.ebs"
ARGUMENT="-eexecuteFeatureScript"
ARGUMENT="-pexecute_query" >
<DMW_INCLUDE FILE="<DMW_SUBST
NAME="DMW_APP_DIALOG_HEADER_DIR">start.htm">
<DMW_INCLUDE FILE="<DMW_SUBST
NAME="DMW_APP_SUCCESS_DIALOG_DIR">start.htm">
" SIZE="-1">
<IMG SRC="<DMW_SUBST NAME="DMW_APP_ICONS_PATH">misc/
m_clear_1.gif" WIDTH=10 HEIGHT=1>
Examples of URL and DMW_INCLUDE Construction
You should always use one of the central Docbasic routines documented in the
scripts\readme.txt file that constructs the desired URL based on parameters you pass
to it.
/RightSite/
wcm_logged_in?view=attributes&id=090000028002dd3d&type=
dm_document&DMW_DOCBASE=engineering&DMW_ON_ERROR=
wcm_silent_login _failure&pid=0c00000280000143&gpid=
filing_cabinets">Properties
This example shows a URL for the Properties link in a dm_document list item.
<DMW_DECLARE NAME="DMW_APP_ARGS" SCOPE="SESSION"
VALUE="id=<DMW_SUBST NAME="id">&entry=checkin&type=
<DMW_SUBST NAME="type">&operation=<DMW_SUBST NAME=
"operation"> & DMW_ECHO=id,operation,type,entry">
<FORM ACTION="<DMW_SUBST NAME="DW_IMAGE_NAME">/uploadfile/

tester.dmu" METHOD="GET" NAME="UploadForm">
The previous example uses a URL variable called entry which tells the dispatcher which
form within the feature directory to use for this request. It defaults to start, but can be
TM
set to any template name that is valid within this feature’s subfolder. The entry variable
allows multi-sequence features to set the links from one page to the next within the
feature’s set of templates. The uploadfile method is a RightSite (and plug-in) method, so
the previous example does not call the dispatcher.
About Customizing Web Server Components

WebPublisher functionality on the Web server is designed as a RightSite client. Before
customizing WebPublisher RightSite client functionality, you should understand the
concepts and information presented in the Documentum RightSite Reference Manual.
This section provides a functional description of WebPublisher components that reside
on the Web server. You can use this information to modify, add, or remove objects in
WebPublisher. WebPublisher functionality on the Web server consists of the following
four functional elements:
• dispatcher: controls the overall operation of WebPublisher on the Web server. It calls
various features and forms to display a list or page, or perform an action.
• features: perform the WebPublisher functionality associated with an operation or
view in the WebPublisher user interface.
• forms: control the look and feel of information displayed in the WebPublisher user
interface. Forms contain the code that accesses information stored on the eContent
Server.
• history mechanism: returns users to a logical place in the WebPublisher user interface
upon completion of an operation such as saving a file.
The WebPublisher installation creates the product folder which contains the components
that control default WebPublisher functionality. Understanding the Product Folder
Hierarchy provides a description of the files contained in these folders.
TM
Figure 2–1. Product Folder Subdirectories
The WebPublisher installation also creates an empty custom\default folder.

You customize WebPublisher functionality by copying folders and files from the
product folder to a parallel structure under the custom folder. You then make your
customizations to the files in the custom folder. The WebPublisher dispatcher always
looks in the custom subfolders before looking in the product directory, so if you have
customizations in the right place, the dispatcher will see them and use them.
Understanding the Dispatcher
Users invoke the dispatcher when they click a link or a button in the WebPublisher user
interface. This action causes the dispatcher to find and include the appropriate start.htm
form for the feature invoked by the link.
The dispatcher looks at the parameters of the URL associated with the selected link or
button to determine what feature to invoke. The dispatcher matches URL parameters to
files in the Web server directory structure to determine the appropriate start.htm form to
use. The URL could look something like this:
http://eng064/rs-bin/RightSite.dll/wcm_logged_in?
view=get_content&id=09011c748000545&DMW_FORMAT=crtext&ShowCuVer=
TRUE&DMW_DOCBASE=EngineeringOne&DMW_ON_ERROR=wcm_s1_failure
or like this:
javascript:submitOperation(’/rs-bin/RightSite.dll/wcm_logged_in?view=
oper_frame&next_operation=export_object&DMW_DOCBASE_EngineeringOne&
DMW_ON_ERROR=wcm_s1_failure&rndn=345536’,’09’,’false’)
TM
The dispatcher looks in two places on the file system to find the appropriate start.htm
form, wcm\product\views and wcm\product\operations. All list start.htm forms are
stored in the views folder, and all action start.htm forms are stored in the operations
folder. The first URL directs the dispatcher to the wcm\product\views\get_content
folder and open the start.htm form. The second URL directs the dispatcher to the
wcm\product\operations\export_object folder and open the start.htm form of the object
which you are exporting. For example, if you select a file of object type dm_document,
the dispatcher navigates to the dm_document folder in the export_object folder and
opens the start.htm form for dm_document.
The dispatcher also looks at some hard-coded information to find the
URLs for such features as the success, failure, and confirmation pages. The
dispatcher looks in two places on the file system to find the proper success
and failure forms. To display the success or failure warning to the user
the dispatcher looks at wcm\product\failure\one_button_dialog.htm or
wcm\product\success\one_button_dialog.htm. The one_button_dialog.htm directs the
dispatcher to bu_one_button_dialog.htm or wd_one_button_dialog.htm, depending on
the logged-in user’s level. When you click Close on the success or failure warnings,
the dispatcher looks at wcm\product\views\oper_frame\remove.htm to remove the
warning page and return you to a logical place.
If the parameter entry= is present in the URL, the dispatcher picks up the .htm form
to which the parameter points. For example, if you want to cancel an export operation,
the dispatcher navigates to wcm\product\views\oper_frame and opens remove.htm
to display the cancel export operation page. The URL for the cancel export operation
looks like this:
http://eng064/rs-bin/RightSite.dll/wcm_logged_in?view=oper_frame&entry=
remove&url_id=remove&url_id=09011c7480004545&dialog_type=Failure&layout=
one_button_dialog.htm&DMW_DOCBASE= EngineeringOne&DMW_ON_ERROR=
wcm_s1_failure
If no
entry=
parameter exists then the dispatcher picks up the operation start.htm form.
The start.htm form can contain an entire feature, include other subforms, or set up
variables and other information.
Most of the dispatcher is contained in two files called wcm_dispatch.htm and
wcm_dispatch_script.ebs, which are called by a DMW_INCLUDE method in one of
several preliminary files that are used in every WebPublisher request. These preliminary
files set environment variables, and separate out pre- and post-log in requests and error
processing requests. The preliminary files and their purposes are:
• wcm.htm: WebPublisher non-error pre-log in requests.
• wcm_logged_in.htm: WebPublisher non-error post-log in requests
• wcm_failure.htm: WebPublisher error processing requests
TM
• wcm_not_logged_in_failure.htm: WebPublisher error processing requests before the

user is logged in
• wcm_not_logged_in_success.htm: WebPublisher success form for pre-log in requests
Determining Which Files To Use
The dispatcher determines which files to use based on a recursive search through the
custom and product folder hierarchies on the Web server. When a form is invoked, the
dispatcher looks for a series of directories and paths and adds them to a list of "base
directories", if they exist. If DW_APPS_ROOTDIR is the root directory into which
WebPublisher has been installed, the dispatcher looks, in the order described below, for
application-specific customizations in the \wcm\custom\application_name subfolder.
If it does not locate that directory, it looks for Docbase-specific customizations in the
\wcm\custom\current_Docbase subfolder. If it does not find any of these directories, an
error message is issued; if it does find one, the process continues.
Next, the dispatcher tries to find out which base directory is used for each of the
page fragments (footers, titles, list_items, etc.) and where the application-common
directories are found. This search is conducted in the same order as the steps above. The
custom\application_name subfolder is checked first, then the \custom\current_Docbase
directory, then the \custom\default subfolder, and finally the product directory.
Because the dispatcher does this searching for each component of a feature, you need
to place only the added or modified files in the custom directory. The dispatcher finds
the remainder of the feature’s components from the other locations. The one exception
to this behavior is the script directory. If you want to modify a file that resides in the
scripts directory then you must copy all files under wcm\default\product\scripts to
wcm\custom\default\scripts.
The final step is for the dispatcher to find the entry point of the requested feature. The
starting location for every feature is a file named start.htm. The only exception to this
rule is the starting location for list_items, which is start.ebs. To find the entry point
the dispatcher looks through the base directories. If the URL passed to the dispatcher
contains a type argument, the dispatcher looks for a subfolder below the feature
subfolder (using the same search order as the previous two searches) that has the same
name as the type.
• If a subfolder for that type is not found, the dispatcher searches the object hierarchy
until it finds the correct subfolder.
• If it does not find a matching subfolder, it looks in the feature’s subfolder.
• If the component it is looking for is still not found, then an error page is displayed.
• If the URL contains only a value for an id argument or DMW_OBJECTID, but
without a type specification, the dispatcher goes to the Docbase to get the type of the
object specified and then performs the search for a subfolder named for that type.
TM
Understanding WebPublisher Forms
WebPublisher forms are HTML files with code that, through the RightSite integration,
access information stored on the eContent Server. RightSite converts the returned data
from the eContent Server to pure HTML so that the WebPublisher form can be displayed
in the browser-based WebPublisher user interface.
WebPublisher forms are constructed using a combination of standard HTML, WebQL,
and Docbasic scripts. When a form is called using the formexec method, it is sent to
RightSite. RightSite checks it for WebQL tags and executes any it finds. The executed
WebQL tags are then replaced with the results of the processing. This process is
recursive. After the replacements are made, the process is repeated until no more WebQL
is present. The finished form, now containing only HTML, is returned to the browser.
For information about WebQL, refer to the Documentum RightSite Reference Manual.
Understanding WebPublisher Features
Documentum uses features to create a complete WebPublisher application. A feature

refers to the set of templates, configuration files, and scripts that make up the
WebPublisher application. WebPublisher utilizes two basic categories of features:
operations and views. The operations category refers to features that perform actions
like check in or apply_lifecycle. The views category controls how WebPublisher displays
information and includes features such as the attributes and view_content. The
WebPublisher folder hierarchy organizes features based on their category (operations and
views) and the object type to which they apply. For example, the PROPERTIES page for
dm_document is located in the wcm\product\views\attributes\dm_document folder.
WebPublisher dynamically constructs features from many components that reside in
separate files. These component files are comprised of:
• start.htm: the starting point of a feature. It contains HTML layout information as
well as calls to Docbasic functions that display pieces of a Web page.
• xml: configuration file for a feature, for example what attributes to display, who
should be able to access a feature or attribute, and which scripts to run.
• ebs: script files that contain the feature’s custom logic, for example to validate if
an item should be displayed.
• htm: other HTML files that contain HTML fragments, which are called using
DMW_INCLUDE by other HTML pages. They contain layout information with
possible DMW_EXEC calls to external.ebs files.
• dictionary.htm: acts as the resource file for all the strings used in that feature. The
general format of each resource identifier is MSG_unique_feature_name for example,
MSG_CHECKIN_ FILE_FORMAT.
TM
Understanding the History Mechanism
WebPublisher uses the history mechanism to ensure that when users complete an
operation (such as saving a file), they are returned to a logical place in WebPublisher.
For example, if a user is viewing the properties of an object and decides to delete
that object, it is important that the dispatcher knows which page to take the user to
after that object is successfully deleted. The history mechanism tells the dispatcher
which page to display, and is accessed using three Docbasic scripts located in
wcm\product\scripts\history_utils.ebs. The history mechanism determines a logical
return by tracking URLs that users have selected from the WebPublisher user interface.
When you click the Back button in your browser you are returned to a logical place
based on the URL selection.
Understanding the Product Folder Hierarchy
The wcm\product folder contains the HTML forms, graphic images, configuration files,
and Docbasic scripts that make up default WebPublisher functionality. Following is a
description of each subfolder in the product folder.
Table 2–4. Product Folder Subfolder Descriptions
Folder Description
actionlist Contains forms that display actions that can be performed in a

view. The form is included as part of the view. For example, the
actionlist form specific to wcm_channel_fld shows the actions as
URLs within the wcm_channel_fld content view.
app Contains global application-level files such as the About page and
global dictionary.
app_scripts Contains scripts that you can modify for your specific environment.
For example, the script wcm_calc_preview_url.ebs is a script that
constructs the URL to Web view content. You can modify this script
based on the structure of your Web site and the application server
that serves the Web site.
category_titles Contains forms that are displayed as part of a view for a given
category object.
confirmation Not used.
dialog_footer Not used.
dialog_header Not used.
failure Contains forms that display the failure window. All the features in
WebPublisher use the same failure window.
TM
Folder Description
footers Contains a form that is included on the bottom of every view page.
It indicates that there is no more data to be displayed and lets you
jump to the top of the page.
images Contains the images that are used throughout WebPublisher user
interface. For example, \images\formats contains the .gif images
for the icons that represent the format of documents in the Docbase.
list_items Contains forms that display the object when you display a
folder’s contents view. For example, when you are looking at a
folder’s contents, a document or a sysobject is displayed using the
corresponding list item definition.
obj_titles Contains forms that are displayed as part of a view for a given object
within the content author and content manager user interface.
operation Contains the forms that compose product features. For example,
the forms which compose the feature of creating a document are
located in \operations\create_document\dm_folder.
scripts Contains files that have utility type Docbasic functions that are
invoked from various forms. The readme.txt file in the scripts
directory describes all the other Docbasic methods or central public
that can invoke these utility type Docbasic functions.
status Contains forms that display the status window. All features in
WebPublisher use the same status window. Features that accept
multi-selection will display to the status window.
stylesheet Contains the cascading stylesheet (CSS) for WebPublisher. You can
modify the CSS to meet your company’s needs.
success Contains forms that display the success window. All the features in
WebPublisher use the same success window.
themes Not used.
TM
Folder Description
titles Contains forms that are displayed as part of a view for a given
object. For example, when you are viewing the attributes of a
document type such as dm_document, the title form specific to
dm_document appears at the top of the PROPERTIES page. A title
for an object shows the object name, object type and other types of
views or actions that are available for this object.
views Contains the forms which compose different views of objects. For
example, the forms which compose the view of what is contained
in a cabinet are located in \views\contents\ dm_cabinet. Views are
pages that have a title area to allow you to switch among pages that
display different information about the current object, for example
properties of that object and actions you can perform on that object.
Any function not explicitly documented in this file should not be
called directly.
TM
Chapter 3
Customizing WebPublisher’s Default
Settings
You can customizing WebPublisher’s default settings by copying and modifying the configuration.xml
file. In this chapter we discuss role selection, and filename lengths.
Enabling and Disabling Role Selection

You can enable or disable role selection during a user’s login to WebPublisher. If you
enable role selection, the Role field appears on the login page. The user selects a role or
selects “Default.” Selecting “Default” logs the user in with their highest role.
WebPublisher provides four roles, also called user groups:
• content author
• content manager
• Web developer
• administrator
Use the three methodology questions to see how to proceed.
• Where will the user see the result?
Every page in WebPublisher. But specifically the Login page.
• What needs to be modified to achieve the result in the feature?
The WebPublisher configuration.xml file.
• What action, if any, will the user take to initiate this feature?
The user may need to choose a role at login.
To enable or disable role selection:
1. On the machine where WebPublisher is installed, navigate to the following location:

Rightsite/application/wcm/product
TM
Customizing WebPublisher’s Default Settings
2. Using an editing application, open the configuration.xml file.

3. To enable role selection, set the value of <enable_role_selection> to true.
4. To disable role selection, set the value of <enable_role_selection> to false.
5. Save your changes and close the configuration.xml file.
You must log out and log back in to WebPublisher to pick up the latest
configuration.xml file changes.
Modifying Filename Lengths

The default length of WebPublisher filenames is 32 characters. You can increase or
decrease this default by making modifications in the configuration.xml file. If you
want to override this default for specific WebPublisher components you can make
modifications to the listitems.xml file of the specific component. For example, if you want
the filename length to be 32 for all filenames in WebPublisher except thumbnail filenames
then you need to add an attribute to the thumbnail_dm_document/listitems.xml file
Every page in WebPublisher.
The WebPublisher configuration.xml file and/or listitems.xml file.
No specific action is required by the user.
To modify the default filename length:

Rightsite/application/wcm/product
2. Using an editing application, open the configuration.xml file.
3. Within the <max_attr_display_length> element, set the <value> tag as follows:
<max_attr_display_length>34</max_attr_display_length>
4. Save your changes and close the configuration.xml file.
To set a default filename length for a specific component:

Rightsite/application/wcm/product/list_items
2. Using an editing application, open a specific XML file, for example
thumbnail_dm_document/listitems.xml.
TM
3. Add the following code:

<attribute show_default_label="false" attr_value_size="18">
The attr_value_size value will override any displayed max_attr_display_length
value you set in the configuration.xml file. The actual value that is stored in the
Docbase is not truncated, only the displayed attribute value for the UI is truncated.
4. Save your changes and close the listitems.xml file.
TM
TM
Chapter 4
Customizing the Properties Page
This chapter begins with the modification to the PROPERTIES page. The customization will show the
properties for a custom object type labeled standard operating procedure (SOP).
Note: Attributes and Properties are used interchangeably throughout this chapter. Attributes when
discussing the attributes.xml file, and Properties when referring to the Web page. Both terms
represent the same elements.
Before you can proceed with any customization you must have created your custom DocApp. The
DocApp should include:
• custom object type
• custom_number attribute
• affected_departments attribute
• approval_department
• alias set
• lifecycle
• workflow
• WebPublisher Configuration cabinet
You need also to package and deploy the custom DocApp to a Docbase, and create new content based
on a custom object type and lifecycle.
Refer to Developing DocApps for more information about creating a DocApp.
Note: To view your customizations you should always log out and log back in to WebPublisher
because of browser caching issues. Refer to Working Around Memory Caching Issues for more
information about caching.
Use the following three methodology questions to see how to proceed.
The SOP PROPERTIES page, which is displayed to the user.
A custom DocApp, or object type in DDS, and the WebPublisher dm_document attributes.xml file.
TM
The user selects the Properties link for an SOP-type document from a Folder FILE LIST page in
which it is listed.
Caution Never make changes to the original files in the product directory. Doing this will change the
WebPublisher defaults and you will not be able to return to restore the defaults unless you re-install
WebPublisher. It is always best to make changes in your custom directory.
The next things to decide are where on the page you want the SOP attributes to show up and who
should be able to view or edit them.
To open the WebPublisher Pro Properties page:
1. Connect to WebPublisher as an administrator or Web developer.

2. Open a document and click the Properties link.
This is the default PROPERTIES page that you want to modify.
TM
To open the WebPublisher Properties page:
1. Connect to WebPublisher as a content manager or content author.

2. Click the EDIT PAGE tab.
3. Click the page that contains the document whose properties you want to view.
This is the default PROPERTIES page.
4. Click Details beside the document.
5. Click Edit properties.
The properties page that you want to modify displays.
TM
The PROPERTIES page is made up of an editable portion and a Read-Only portion. In the editable
portion, there are a number of attributes that you will change in the following procedures.
To modify the PROPERTIES page.
• Copy the attributes.xml File
• Delete attributes
• Add attributes
• Add value assistance
• Add value selection
• Create scripts
• Display and hide attributes
• Adding or removing content
• Test customizations
Copying the attributes.xml File

To make any customizations, copy WebPublisher’s default file from the product directory
to the custom directory. When you modify the attributes.xml file, add only attributes that
you have previously defined for the SOP object type in DDS. To use attributes that do not
already belong to the SOP object type, you must use DDS to add attributes to the SOP
object type, then modify the attributes.xml file to display the attributes.
If you look in the product directory hierarchy, you see that under \views there is an
attributes directory with subdirectories for different object types, including one for
dm_document, which is the supertype of SOP; you need to recreate the \views\attributes
under the custom directory. Since you want a customized SOP properties page which
looks and behaves different than the parent type dm_document, you should create an
SOP folder under \custom\default\views\attributes.
To copy the attributes.xml file:
1. On the server where WebPublisher is installed, open Windows Explorer and navigate
to RightSite\applications\wcm\custom\default.
2. In the default folder, create a views\attributes\sop folder structure.
3. Navigate to RightSite\applications\wcm\product\views\attributes\dm_
document\attributes.xml.
4. Copy the attributes.xml from the product folder to the SOP folder that you created
in step two.
You should now see the following in your custom directory:
TM
Since you are changing the list of attributes displayed, the only file you need to modify
is the attributes.xml file.
There are other files in the \product\views\attributes folder that are used by all the
object types. If you needed to override their implementation, you would have to copy
those to the custom directory and modify them as well. For this exercise you do not
need any other files.
If you open the attributes.xml file you copied to custom\views\attributes\sop, you
can see that it is divided into two sections, editablegroups and viewonlygroups.
Furthermore, all the attributes in each section are displayed on the PROPERTIES page in
the exact order you see in the XML file.
The first portion of the file, editablegroup, looks as follows:
<editablegroups>
<group>
<attributelist>
<attribute>
</attribute>
<attribute>
<name>title</name>
</attribute>
<attribute>
</attribute>
</attribute>
</attribute>
<attribute>
<validate_attr_script>donot_show_in_change_set</validate_attr_script>
</attribute>
<attribute>
<label>MSG_ATTR_LABEL_EXPIRATION_DATE</label>
TM
</attribute>
<attribute>
<name>a_category</name>
</attribute>
<info_string>MSG_ATTR_INFO_LABEL_PUBLISH_FORMATS</info_string>
</attribute>
<attribute display_control="textarea" default_textarea_rows=
"3"textarea_wrap="true">
<name>log_entry</name>
<label>MSG_ATTRIBUTES_COMMENTS</label>
</attribute>
</attributelist>
</group>
</editablegroups>
Adding and Removing Object Attributes

You can now add or remove attributes from the SOP PROPERTIES page by modifying
the attributes.xml file.
Deleting Attributes
Since the title, subject, keywords, and authors attributes are not used for SOP documents
in your company, remove the lines for those attributes and save the attributes.xml file.
To delete attributes:
1. Using a text editor, navigate to

RightSite\applications\wcm\custom\default\views\attributes\sop and open
2. Select and delete the title, subject, keywords, and authors attributes by selecting
the associated code.
3. Press Delete.
The code sample below shows the attributes to remove.
<attribute>
<name>title</name>
</attribute>
<attribute>
TM
</attribute>
</attribute>
</attribute>
4. Choose File>Save.
5. Navigate to your browser page and refresh the contents of the right-hand frame that
displays the PROPERTIES page.
You should see that the title, subject, keywords, and authors attributes are no longer
displayed.
Adding Attributes
You now add sop_number, affected_departments, effective_date, and
approval_department attributes to the XML page where title, subject, keywords, and
authors attributes used to be.
To add attributes:

2. Add the following SOP custom attributes
• sop_number name and label
• affected_departments name and label
• approval_department name and label
by typing the following code:
<attribute>
<name>sop_number</name>
<label>SOP number:</label>
</attribute>
<name>affected_departments</name>
<label>Affected departments:</label>
</attribute>
<attribute>
<name>approval_department</name>
<label>Approval department:</label>
</attribute>
TM
4. Connect to WebPublisher as Web developer or administrator.
5. Select an SOP document and click the Properties link.
You should see the following Properties page.
TM
Suggesting Appropriate Attribute Values

Conditional value assistance also called conditional attribute selection enables users
to choose options from a dialog box instead of typing information into a field. When
you create or modify object type attributes in DDS you can add value assistance. For
example, you can allow users to select all values applicable to Affected Departments
since affected_departments is a repeating attribute.
Conditional value assistance only works on the Properties page. Conditional value
assistance does not work with Add Contents page because during create content no
object exists. Conditional value assistance requires that you save a value of a property on
the object and run that property value through the validator to get the conditional values
of other properties. Content Authors can create content without selecting the attributes
which are related to conditional value assistance. Content authors can also select the
properties of the document after creation and then they will have the conditional value
assistance working on the properties page.
Refer to Developing DocApps and Using Documentum WebPubliusher Pro for more
information on adding value assistance to object types.
Adding Value Assistance

Add value assistance to the affected_departments attribute in DDS, and add the
element attribute show_all_values= true to the XML element for this attribute in the
attributes.xml file.
To add value assistance:

2. Add the new XML element to the affected_departments attribute by typing in the
following code. The bolded section below contains the element to add.
You should see the following.
TM
6. Click Choose From to choose the appropriate affected department.

Note: The Choose From button next to the Affected Department attribute is the attribute
that was assigned Value Assistance when you created the attribute in DDS.
TM
Adding Value Selection

You can enable users to choose options from a choice list. Documentum currently
provides you with an example choice list to check an HTML or PDF check box to create
a rendition of a selected document. Following is an example of the code with some
modifications to show you how to customize this feature.
If you look in the product directory hierarchy, you see that under \views\attributes there
is a wcm_category folder that contains a get_rendition_choices.ebs script. You want to
copy this script to \custom\default\views\attributes\sop so you can customize the
script and the sop attribute.xml file for your SOP object type.
To copy the get_rendition_choices.ebs script:
to RightSite\applications\wcm\product\views\attributes\wcm_category
2. Copy the get_rendition_choices.ebs script from the product folder to the SOP folder
in \custom\default\views\attributes.
To add value selection:

2. Add a new attribute to populate the sop Properties page with choices enabling users
to select an HTML or PDF rendition of a document by typing in the following code
in the editable portion of the attributes.xml file.
<attribute show_all_values="true" display_control="checkbox">
<name>auto_formats</name>
<label>generate automatic rendition</label>
<info_string>MSG_ATTR_INFO_NULL</info_string>
<attr_value_choices_script>automatic_rendition_choices_sop
</attr_value_choices_script>
</attribute>
automatic_rendition_choices is the script that you must create and save in the same
custom folder as the attributes.xml file. This script returns a list of possible repeating
values for the attribute.
RightSite\applications\wcm\custom\default\views\attributes\sop and open the
get_rendition_choices.ebs script.
Public gWcmApplication As Object
Sub attrValueChoices(session As Object, obj_type As String, delim As String,

byref attr_list As String)
TM
Dim wcmConstants As Object
Set wcmConstants = gWcmApplication.getWcmConstantNS()
attr_list$ = "html" & "||" & dwGetVar("MSG_ATTR_VALUE_LABEL_HTML", "SESSION")

attr_list$ = attr_list$ & "~" & "pdf" & "||" & dwGetVar
("MSG_ATTR_VALUE_LABEL_PDF", "SESSION")
End Sub
5. You can modify the script to be specific to your company

6. Choose File>Save As automatic_rendition_choices_sop.ebs.
The automatic_rendition_choices_sop.ebs script populates the editable portion of the
Properties dialog box with HTML and PDF checkboxes.
Displaying Value Selection

You can display to users the value status. Documentum currently provides you with an
example display value. Following is an example of the code with some modifications to
show you how to customize this feature.
If you look in the product directory hierarchy, you see that under \views\attributes there
is a dm_document folder that contains a get_status.ebs. You want to copy this script to
\custom\default\views\attributes\sop so you can customize the script and the sop
attributes.xml file for your SOP object type.
To copy the get_status.ebs script:
to RightSite\applications\wcm\product\views\attributes\dm_document
2. Copy the get_status.ebs script and the attributes .xml from the product folder to the
SOP folder in RightSite\applications\wcm\custom\default\views\attributes.
To add value display:

2. Add a new attribute to populate the SOP Properties page with choices enabling the
display of value status by typing in the following code.
TM
<attr_value_script>get_status</attr_value_script>
The script get_status.ebs returns a single value for the attribute. There are actually
two values returning back: the first is the value for the display, the second is the
value to store in the attribute.
RightSite\applications\wcm\custom\default\views\attributes\sop and
open the get_status.ebs script.
Public gClientX As IDfClientX
Public gLocalClient As IDfClient
Public gSession As IDfSession
Public gDMW_APP_SCRIPTS_DIR As String
’ attr_value - value to display in UI

’ attr_sysvalue - value to store in the attribute
Sub attrValue(byref attr_value As String, byref attr_sysvalue As String)
Dim idObject As Object

Dim id As String
ret = external(gDMW_APP_SCRIPTS_DIR$ & "utils.ebs")
id$ = dwGetVar("id", "ALL")
Set idObject = gClientX.getId(id$)

Set theObject = gSession.getObject(idObject)
Dim isWebDoc As Boolean
isWebDoc = theObject.isWebDoc
if (isWebDoc) then
attr_sysvalue$ = theObject.getCurrentStateName
else
attr_sysvalue$ = theObject.getVersionStatus
end if
if attr_sysvalue$ = "" then

attr_sysvalue$ = dwGetVar("MSG_NO_STATUS_SYMBOL", "ALL")
end if
attr_value$ = attr_sysvalue$
End Sub
TM
5. You can modify the script to be specific to your company.

The get_status.ebs script populates the Read-Only portion of the Properties dialog
box with value status.
Creating Scripts
You can enforce an additional requirement that only the owner or the administrator
or Web developer can edit the affected_departments, effective_date, and
approval_department attributes. Content authors and content managers are restricted to
viewing this information.
To do this, put the list of attributes in both the editablegroups and viewonlygroups
sections of the attributes.xml file.
To assign all other users View Only status you must write two very small scripts and
let WebPublisher invoke them to determine if a particular SOP attribute should be
displayed or not. You must also then edit the attributes.xml file.
Since these scripts are specific to the SOP PROPERTIES page handling, we place them in
the \custom\views\attributes\sop folder. If the scripts are common to all subtypes of
dm_document, put them in an attributes\dm_document folder. If they are common to
all object types, put them in the attributes directory.
To create an edit script:
1. Open a text editor such as Notepad.

2. Type the following code:
option cStrings on
Sub validateAttr(byref isvalid as boolean)
Dim wcmUtil As Object
Dim wcmConstant As Object
Set wcmUtil = gWcmApplication.getWcmUtilNS()

UserGroup$ = wcmUtil.getUserGroupName()
Set wcmConstant = gWcmApplication.getWcmConstantNS()
If (UserGroup = wcmConstant.getCONTENT_AUTHOR_GROUP())
Or (UserGroup = wcmConstant.getCONTENT_MANAGER_GROUP()) Then
TM
isValid=false
Else
isValid=true
End If
End Sub
The Sub validateUser entry point checks to see if the current user is the owner of the
current SOP object; if the previous condition is true, true is returned, indicating that
the attribute element should be accessible by this user.
4. Navigate to
C:\RightSite\applications\wcm\custom\default\views\attributes\sop.
5. Name your script file validate_edit_sop_info.ebs.
To create a view script:

option cStrings on
Sub validateAttr(byref isvalid as boolean)
Dim wcmUtil As Object
Dim wcmConstant As Object
Set wcmUtil = gWcmApplication.getWcmUtilNS()

UserGroup$ = wcmUtil.getUserGroupName()
Set wcmConstant = gWcmApplication.getWcmConstantNS()
If (UserGroup = wcmConstant.getCONTENT_AUTHOR_GROUP())
Or (UserGroup = wcmConstant.getCONTENT_MANAGER_GROUP()) Then
isValid=true
Else
isValid=false
End If
End Sub
4. Navigate to c:\RightSite\applications\wcm\custom\default\views\attributes\sop.
5. Name your script file validate_view_sop_info.ebs.
Note: The object ID is retrieved by doing a dwGetVar(“id?) and the current user
is retrieved by accessing the RightSite variable DMW_DOCBASE_USER using a
dwGetVar().
Next, modify the attributes.xml file to complete the view and hide customization.
TM
Changing which Attributes to Display

Since content authors and content managers access this PROPERTIES page, make some
attributes Read-Only, and remove some attributes from view.
Make the following attributes Read-Only:
• object_name
• sop_number
• affected_departments
• approval_department,
• a_effective_date attributes
Hide the following attributes:
• r_version_label
• r_lock_date elements.
To hide attributes from content authors and managers:

To hide attributes you must add an application list code structure to the each of the
elements mentioned above, and add an edit script to the r_version_label and the
r_lock_date elements.
1. Using a text editor, navigate to your custom folder and open the attributes.xml file.
2. In the editablegroups section, add an application list to the following elements:
• a_content_type
• r_version_label
• a_full_text
• r_lock_date
3. Type the following code. The bolded section is an example of the application list
for the a_content_type element.
<group>
<attributelist>
<attribute>
<name>a_content_type</name>
<applicationlist>
<application rule="exclude">
<name>ContentAuthor</name>
</application>
</applicationlist>
</attribute>
<attribute>
<name>owner_name</name>
</attribute>
TM
<attribute>
<name>_permit</name>
</attribute>
</attributelist>
</group>
You must add this code to each of the four elements.
5. In the viewonlygroups section, add the edit script to the following elements:
• r_version_label
• r_lock_date
6. Type the following code. The bolded section below contains the attributes to add.
<name>r_version_label</name>
<validate_attr_script>validate_edit_sop_info</validate_attr_script>
</attribute>
<attribute>
<name>r_lock_date</name>
</attribute>
You can now add multiple application elements to this application list. Each application
must specify whether it is to include or exclude the user-level specified in the name
element.
To display attributes to administrators and Web developers:

To display attributes to the SOP document owner, or to hide attributes from other users
add a validate_user_script element to both the editablegroups and viewonlygroups
sections of the attributes.xml file.
2. In the editablegroups section, add the edit script to the following elements:
• object_name
• sop_number
• affected_documents
• approval_department
• a_effective_date
<attributelist>
<attribute>
TM
</attribute>
<attribute>
</attribute>
</attribute>
<attribute>
</attribute>
<attribute>
</attribute>
</attributelist>
The file name is entered without the .ebs extension.
To create Read-Only attributes for content authors and content managers:
2. Copy the object_name, sop_number, affected_departments, approval_department,
and a_effective_date attributes from the editablegroups section to the
viewonlygroups section.
3. Change the following line:
validate_edit_sop_info code line
to
validate_view_sop_info
<attributelist>
<attribute>
<validate_attr_script>validate_view_sop_info</validate_attr_script>
</attribute>
<attribute>
TM
</attribute>
</attribute>
<attribute>
</attribute>
<attribute>
</attribute>
</attributelist>
Altering the Content of Property Pages

You may want to add new attributes if you have created a custom object type that requires
a special attribute, and remove attributes that are not applicable to your custom type.
To add content to the Properties page:

C:\RightSite\applications\wcm\custom\default\operations\add_content\add_
content.xml.
2. If you want to add content for your SOP object type you must first change the base
type to be SOP.
3. For example, change the following code:
<base_type>dm_document</base_type>
to
<base_type>SOP</base_type>
The base type can be any object type as long as the object type is a subtype of
dm_document.
4. Type the following code to add a Subject of SOP attribute.
<attribute>
TM
<name>SOP_Subject</name>
<label>Subject of SOP</label>
</attribute>
5. To remove the effective date select the following element and press the Delete key.
<attribute>
</attribute>
Each document must have an effective date. If you remove the effective date from the
PROPERTIES page WebPublisher will derive the document’s effective date from the
template the document was based on. If the template does not have an effective date,
then WebPublisher will derive the effective date from the document creation date.
6. To remove the expiration date select the following element and press the Delete key.
<attribute>
</attribute>
Each document must have an expiration date. If you remove the expiration date
from the PROPERTIES page WebPublisher will use the default expiration date of 15
days. The default expiration date can be changed in the system configuration file
by the system administrator. The system configuration file is located on the System
Configuration page in WebPublisher/Properties
Testing Customizations
Test your customizations to ensure that you have correctly modified the attributes.xml
file, and correctly created the edit and view scripts.
To test the customizations:
1. Connect to WebPublisher as administrator.

2. Verify that you can see all the SOP custom attributes (File name, SOP number,
Affected departments, Approval department, Subject of SOP) in the editable section
of the PROPERTIES page.
The page should look as follows.
TM
3. Next, log in as a content manager or content author.

4. Verify that the object_name (File Name) and sop_number (SOP number) attributes
are in the Read-Only section and that the r_lock_date, and r_version_label are not
displayed.
The page should look as follows.
TM
TM
Chapter 5
Modifying a List Item
In this chapter you will create a new list item for the SOP document type, and you will modify a
list item for thumbnails.
A list item is an attribute such as a subject, author, or SOP number displayed under your specified
document type or thumbnail in the FILE LIST page. WebPublisher uses the list_item.xml file to
specify the attribute or data to be displayed and the content.xml file to specify the DQL.
Before you can proceed with any customization you must have created your custom DocApp. The
DocApp should include
You need also to package and deploy the custom DocApp to a Docbase, and create new content based
on an custom object type and lifecycle.
Refer to Developing DocApps for more information about creating a DocApp.
WebPublisher uses the contents.xml file to specify the DQL and list_item.xml to specify the attribute
or other data to display. If you add new dm_sysobject/dm_document attributes to the list_item.xml
file we recommend that you add these same attributes to the contents.xml file. If you add custom
attributes that are subtypes of dm_document WebPublisher performs a query for these attribute IDs.
Creating a New List Item

In this example, the document is of type SOP. This customization displays an SOP
number under the SOP document type. The default FILE LIST page that you want to
modify should look similar to the following figure.
TM
Figure 5–1. Default Document View
Use the following three methodology questions to help you proceed.

In the SOP object’s list item displayed in a cabinet’s or folder’s FILE LIST page. In
this customization the SOP list item displays the SOP number.
The WebPublisher dm_document list_items.xml file.
The user clicks the name of a cabinet or folder to see the SOP object’s list item. Since
displaying the list items of all dm_sysobject derived objects is the normal behavior of
cabinets and folders, you do not need to make any other customizations.
To display the SOP number attribute, customize the list_items.xml file for the list item
feature. You must copy the list_items.xml from product\list_items\dm_document to
custom\default\list_items\sop.
Copying the list_items.xml File

The list_item.xml file contains the folders and files that you need to custom to modify
an existing list item, or create a new list item. If you look in the product directory
hierarchy, you see that under \list_items there are many different folders, each with a
different list_item.xml file, including one for dm_document, which is the supertype of
SOP. To create a customized SOP list item which looks different than the parent type
dm_document, you should create an SOP folder under \custom\default\list_items.
To copy the list_item.xml file:
1. On your server where WebPublisher is installed, use Windows Explorer to navigate

2. In the default folder create a list_items\sop folder structure.
TM
3. Navigate to RightSite\applications\wcm\product\list_items\dm_document\list_
items.xml
4. Copy the list_items.xml file from the product folder to the sop folder that you
created in step two.
To change the list item for sop document types, the only file you need to edit is the
dm_document\list_items.xml file.
Note: There are other XML files for different views, including cabinets, folders, content
authors, content managers, and Web developers. The bu_dm_document folder enables
you to change the list item for content authors and Managers, and the dm_document
folder enables you to change the list item for Web developers. For this exercise you do
not need to edit any other files.
If you open the list_item.xml file you copied to custom\default\list_items\sop, you can
see that it has one section: attributelist.
Some of the XML files are divided into two sections: attributelist and featurelist. The
attributelist section specifies which attributes should be displayed for an object of this
type and the featurelist specifies which FILE LIST and ACTIONS should be available.
In this example we display object_name and title attributes. The following is the content
of the dm_document list_items.xml file:
<listitem>
<attributelist>
<attribute show_default_label="false">
</attribute>
<name>title</name>
</attribute>
</attributelist>
</listitem>
Adding List Item Attributes

To add the sop_number attribute to the XML page, fill in the SOP number on the
PROPERTIES page of the SOP document you are working with before you try to display
the SOP number in a view.
TM
To add an SOP number:
1. Using a text editor, navigate to your custom folder and open the list_items.xml file.
</attribute>
You should see the following SOP number under the sop object in the FILE LIST page:
To add an SOP number label:
2. Select the false label, and modify it to say true.
This change displays the SOP Number label. The bolded section below is the
attribute to change.
<attribute show_default_label="true">
</attribute>
You should see the following SOP number label under the sop object in the FILE
LIST page.
TM
Note: To display all the values for a repeating attribute in the attributes.xml file, set the
element attribute show_all_values to true. For example:
<info_string>MSG_ATTR_INFO_PUBLISH_FORMATS</info_string>
</attribute>
By default, WebPublisher does not retrieve any custom attributes as part of a Cabinet or
Folder query. To display a custom attribute, WebPublisher performs a fetch of the object.
Modifying a Thumbnail List Item

When you select thumbnail from the Show drop-down list on the FILE LIST page
a specific thumbnail for each file displays if the media server is enabled. If media
server is not enabled then a default thumbnail displays. You can modify the thumbnail
information to display different information, or just a different label for the existing
information.
Use the following three methodology questions to help you proceed.
Beside the thumbnail displayed in a cabinet’s or folder’s FILE LIST page.
The thumbnail_dm_document list_items.xml file.
The user clicks the name of a cabinet or folder to a list of files, then selects thumbnails
from the Show drop-down list on the FILE LIST page.
TM
Copying the list_items.xml File

The list_items.xml file contains the folders and files that you need to custom to modify
an existing list item, or create a new list item. If you look in the product directory
hierarchy, you see that under \list_items there are many different folders, each with a
different list_item.xml file, including one for thumbnail_dm_document. To create a
customized thumbnail list item, you should create a thumbnail_dm_document folder
under \custom\default\list_items.
To copy the list_item.xml file:

2. In the default folder create a list_items\thumbnail_dm_document folder structure.
3. Navigate to RightSite\applications\wcm\product\list_items\thumbnail_dm_
documentt\list_items.xml
4. Copy the list_items.xml file from the product folder to the thumbnail_dm_document
folder that you created in step two.
Modifying List Item Attributes

To change the thumbnail attributes in the XML file you need to open the list_items.xml
file in the \custom\default\list_items\thumbnail_dm_document folder. In this example
we will remove the file size attribute and add the owner attribute.
To modify the attributes:
2. Remove the following file size code by selecting the entire attribute and clicking
Delete.
<attribute>
<name>r_content_size</name>
</attribute>
3. Add the following owner name code:

<attribute>
<name>owner_name</name>
</attribute>
6. Navigate to the thumbnails on the FILE LIST page.
TM
You should now see the name of the file owner on the right-hand side of the
thumbnail.
You can modify the list_items.xml file to hide or display any thumbnail information.
Any words that overlap the character limit for thumbnail information will be wrapped.
You cannot modify the character length.
TM
TM
Chapter 6
Customizing Search Pages
This chapter explains how to customize the existing default ADVANCED SEARCH page, the existing
default SIMPLE SEARCH page, and how to create a new simple search option. Each of these tasks are
completed by modifying the search_facility.xml file, or the wd_header.htm file and bu_header.htm file.
Customizing the Advanced Search Page

You can add, remove and modify existing search attributes and operators you change the
functionality and look of the ADVANCED SEARCH page.
You need only to modify an XML file.
The ADVANCED SEARCH page.
The WebPublisher untyped search_facility.xml file.
The user clicks more options to open the ADVANCED SEARCH page.
This is the default ADVANCED SEARCH page that you want to modify.
TM
Figure 6–1. Default Advanced Search Page
To modify the default ADVANCED SEARCH page, copy the search_facility.xml from
product\views\search_facility\untyped.
Copying the search_facility.xml File

If you look in the product directory hierarchy, you see that under \views\search_facility
there are two different search_facility.xml files, one under the untyped folder and one
under the simple folder. Recreate the \views\untyped folder under the custom folder
to replace the default ADVANCED SEARCH page with a customized ADVANCED
SEARCH page.
To copy the search_facility.xml file:

to the RightSite\applications\wcm\custom\default folder.
2. In the default folder, create a views\search_facility\untyped folder structure.
3. Navigate to RightSite\applications\wcm\product\search_facility\untyped\search_
facility.xml
4. Copy the search_facility.xml file from the product folder to the untyped folder that
you created in step two.
TM
After copying the file you should see the following in your custom directory:
Since you are changing the default advanced search, the only file you need is the
untyped\search_facility.xml file.
The search_facility.xml File

The search_facility.xml file you copied to custom\default\views\search_
facility\untyped has six sections:
• defaultObjectType, which specifies the default selection for object type.
• logicOperatorList, which specifies a list of available logical operators, such as AND
and OR.
• selectAttributeList, which defines the query Select clause.
• whereAttributeList, which defines the query’s Where clause.
• where_clause_script, which specifies a script to process\build the search query
Where clause.
• fullTextAttribute, which adds a full text search control.
You can also add a few more sections for further configuration of the ADVANCED
SEARCH page, which is explained in Adding a Custom Object Type, and Creating a
New Search Option.
Starting the Customization

This example accomplishes the following customizations:
• Changes the default object type selection from dm_document to SOP.
There are three different object type selections
— buroot: enables you to display specific types and their subtypes to content
authors or content manager
— wdroot: enables you to display specific types and subtypes to Web developers
The buroot and wdroot types display under the Search For drop-down list on
the ADVANCED SEARCH page.
TM
— default: enables you to choose an object type that is first displayed in the Search
For field on the SEARCH page. You want to change the default object type.
• Changes the default logical operator to AND and hides the control from the user.
• Simplifies the user interface by allowing searches only on the object_name property,
set the default relational operator to CONTAINS, and hide the control from the user.
• Displays the match case control enabling users to specify whether the search should
be case-sensitive or case-insensitive.
To change the default object type selection:
1. Using a text editor, navigate to your custom folder and open the search_facility.xml
file.
2. In the defaultObjectType section, select the dm_document type.
3. Change the dm_document name to SOP.
The bolded text below is the name to change.
<burootObjectType>
<name>dm_document</name>
</burootObjectType>
<wdrootObjectType>
<name>dm_sysobject</name>
</wdrootObjectType>
<defaultObjectType>
<name>sop</name>
</defaultObjectType>
To change the default logical operator:
1. In a text editor, navigate to your custom folder, and open the search_facility.xml file.
2. Remove the following bolded clause that specifies the OR operator in the
logicOperatorList section.
<logicOperatorlist>
<operator>
<name>all</name>
</operator>
<operator default_selection="true">
<name>any</name>
</operator>
</logicOperatorlist>
3. Add the following clause:

default_selection="true"
to the element that specifies the AND operator.
TM
The bolded operator below is the operator to add.

<logicOperatorlist>
<name>all</name>
</operator>
<operator>
<name>any</name>
</operator>
</logicOperatorlist>
To allow searching only on the object_name property:
1. Using a text editor, navigate to your custom folder and open the search_facility.xml
file.
2. From the whereAttributelist section, delete everything except the object_name block.
The object name block looks as follows:
<attribute display_control="text">
<label>MSG_SF_LABEL_OBJECT_NAME</label>
<relationalOperatorlist>
<operator>
<name>is</name>
</operator>
<name>contains</name>
</operator>
<operator>
<name>starts_with</name>
</operator>
</relationalOperatorlist>
</attribute>
3. Delete the IS and STARTS_WITH operators from the relationalOperatorList in the

object_name property block.
The operators to remove are bolded below:
<label>MSG_SF_LABEL_OBJECT_NAME</label>
<operator>
<name>is</name>
</operator>
TM
</operator>
<operator>
</operator>
</attribute>
4. To hide the default CONTAINS operator

a. Remove default_selection=true.
b. Add is_hidden=”true” in the operator element.
The bolded operator below is the operator to add:
<operator>
<name>is</name>
</operator>
<operator is_hidden="true">
</operator>
<operator>
</operator>
This completes the required customization steps.

To accomplish step 4, we add a matchCaseAttribute section to the existing the
search_facility.xml file. The default_value element specifies the initial setting:
• true means case-sensitive
• false means case-insensitive
<matchCaseAttribute>
<name>MSG_SEARCH_FACILITY_MATCH_CASE</name>
<default_value>false</default_value>
</matchCaseAttribute>
Adding a Custom Object

For this customization example, you create a custom search for SOP objects named
sop_search. You create new folders and files and make minimum changes to the files,
including the search_facility.xml file as seen in the previous example.
TM
The customization affects the custom search content view page, as well as the
sop_search criteria page.
— You must create a new search criteria page for the sop_search page so that the
search is centered around the SOP object type and its custom attributes.
— You must add the sop_search link to the custom search content view page, where
the sop_search can be accessed.
The user clicks Search on the upper frame to get to the search criteria page for
the default type. Clicking the custom search link on the upper right-hand corner
displays the modified custom search content view with a SOP search link in it. Click
the SOP search to view the search criteria.
Before you begin these customizations copy the search_facility.xml file from the product
folder to your custom folder. Refer to Copying the search_facility.xml File for more
information.
The original whereAttributelist in the search_facility.xml file looks like this:
<whereAttributelist>
<attribute>
<operator>
<name>is_any_of</name>
</operator>
<operator>
<name>is_all_of</name>
</operator>
</attribute>
</whereAttributelist>
To modify search attributes for SOP:
1. Using a text editor, navigate to your custom\default\views\search_facility\untyped

folder, and open the search_facility.xml file.
2. Modify the whereAttributelist section by deleting all the existing attributes blocks,
and adding the SOP specific attributes.
3. Add the r_object_type property block.
The r_object_type attribute is a single-valued string attribute. Use IS as the default
relational operator.
<name>r_object_type</name>
TM
<operator>
<name>is</name>
</operator>
</operator>
<operator>
</operator>
</attribute>
4. Add the affected_departments attribute block.

The affected_departments attribute is a repeating attribute with value assistance.
Use special relational operators (IS_ ANY_ OF/IS_ALL_OF) to handle this attribute.
<attribute>
<operator>
<name>is_any_of</name>
</operator>
<operator>
<name>is_all_of</name>
</operator>
</attribute>
5. Add the approval_department and the sop_number attribute block to the

whereAttributelist section.
The approval_department and the sop_number attributes are single-valued string
attributes. Use IS as the default relational operator and hide it from the display
using IS_HIDDEN=”TRUE”.
<attribute>
<name>is</name>
</operator>
</attribute>
<attribute>
<name>is</name>
</operator>
TM
</attribute>
6. Add the effective_date property block to the whereAttributelist section.

The effective_date attribute is a time attribute. Use special relational operators for
time related attributes, which include ON, ON_OR_BEFORE, and ON_OR_AFTER.
In this case, we will use ON as the default, and hide it from the display using
IS_HIDDEN=TRUE. The date_attr_range clause is used only for the time property to
specify whether you would like to display operators in two separate rows (like in
the default search) or a single row (as in this example).
<attribute date_attr_range="false">
<name>effective_date</name>
<name>on</name>
</operator>
</attribute>
7. Delete the fullTextAttribute section to restrict full-text searches in this example.

The following code is the section to delete.
<fullTextAttribute>
<name>MSG_SEARCH_FACILITY_TEXT</name>
</fullTextAttribute>
The modified ADVANCED SEARCH page should look as follows:
Customizing the Simple Search Page

You can add, remove and modify existing search attributes and operators you change
the functionality and look of the SIMPLE SEARCH page.
You need only to modify an XML file.
TM

The SIMPLE SEARCH page.
The WebPublisher search_facility.xml file.
The user clicks the GO link to run the simple search.
This is the default SIMPLE SEARCH page that you want to modify.
Figure 6–2. Default Search Link
To modify the default SIMPLE SEARCH page, copy the search_facility.xml from
product\views\search_facility\simple.
Copying the search_facility.xml File

If you look in the product directory hierarchy, you see that under \views\search_facility
there are two different search_facility.xml files, one under the untyped folder and one
under the simple folder. Recreate the \views\simple folder under the custom folder to
replace the default SIMPLE SEARCH page with a customized SIMPLE SEARCH page.
To copy the search_facility.xml file:

2. In the default folder, create a views\search_facility\simple folder structure.
3. Navigate to RightSite\applications\wcm\product\search_facility\simple\search_
facility.xml
4. Copy the search_facility.xml file from the product folder to the custom folder that
Since you are changing the default simple search, the only file you need is the
simple\search_facility.xml file.
TM
The search_facility.xml File

The search_facility.xml file you copied to custom\default\views\search_facility\simple
has two sections:
• selectAttributeList, which defines the query Select clause.
• simpleWhereAttributeList, which defines the query’s Where clause.
The where_clause_script, which specifies a script to process\build the search query
Where clause is located in the display_results.ebs file.
Starting the Customization

This example accomplishes the following customizations:
• Changes a default attribute from title to mytitle.
• Adds the ability to perform a keyword search in a simple search.
To change a default attribute:
1. Using a text editor, navigate to your custom folder and open the simple
search_facility.xml file.
2. In the selectAttributelist section, select the title type.
3. Change the title to mytitle.
The text below is the code to change.
<attribute>
<name>mytitle</name>
</attribute>
To add keyword search capability:
1. In a text editor, navigate to your custom folder, and open the simple
search_facility.xml file.
2. In the selectAttributelist section, add the following attribute:
<attribute>
</attribute>
TM
Creating a New Search Option

This section explains how to create a new searching option in WebPublisher by adding
a new search link.
The WebPublisher search header.
The WebPublisher wd_header.htm file for the WebPublisher Pro interface and
bu_header.htm file for the WebPublisher interface.
The user clicks the GO link to run the simple search.
This is the default search link that you want to modify.
Figure 6–3. Default Search Link
To modify the default search link, copy the wd_header.htm file and the bu_header.htm
file from product\app to custom\default\app.
Note: If you want to modify the simple search queries, other than attributes and
types, you must know Documentum Docbasic, and you must make changes to the
display_results.ebs file. We do not go into detail about this customization in this guide.
Copying Files
If you look in the product directory hierarchy, you see that under \app there is the
wd_header file and bu_header file. The wd_header.htm file controls the WebPublisher
Pro search facility for Web developers and administrators, and the bu_header.htm file
controls the WebPublisher search facility for content managers and content authors.
To copy the search header files:

2. In the default folder, create an app folder.
3. Navigate to RightSite\applications\wcm\product\app.
TM
4. Copy all the files from the product folder to the app folder that you created in step
two.
After copying the files you should have 48 files in your custom\default\app
folder two of which should be the search header files bu_header.htm file, and
wd_header.htm file.
The Search Header Files

If you open the wd_header.htm file or the bu_header.htm file you copied to
custom\default\app, you can see that they are divided into web macros. To create a
custom simple search link you need to add a custom web macro to the wd_header.htm
file and bu_header.htm file. The web macro sets the arguments for your search. An
example of an existing WebPublisher Web macro is as follows.
<DMW_EXEC
File="<DMW_SUBST NAME=""DMW_APP_SCRIPTS_DIR">templates.ebs"
EXECTYPE="Docbasic"
ARGUMENT="-egetFeatureLinkWOEntryAsVar"
ARGUMENT="-p"
ARGUMENT="-psimple"
ARGUMENT="-psearch_facility"
ARGUMENT="-p"
ARGUMENT="-psimpleSearchLink"
>
Your custom Web macro must include the WebPublisher method to generate a link to
your custom search type folder, you must change the search argument from simple to
custom, and you must set the variable name which determines where WebPublisher will
look for the custom search link when users click GO in the user interface.
Following is an example of a custom Web macro.

<DMW_EXEC
FILE="<DMW_SUBST NAME=""DMW_APP_SCRIPTS_DIR">templates.ebs"
EXECTYPE="Docbasic"
ARGUMENT="-egetFeatureLinkWOEntryAsVar"
ARGUMENT="-p"
ARGUMENT="-pmytype" 
ARGUMENT="-psearch_facility"
ARGUMENT="-p"
ARGUMENT="-pmytypeLink" 
>
FORM NAME="SEARCH" TARGET="display" ACTION=="<DMW_SUBST NAME="=mytypeLink">"
METHOD="POST" <TD VALIGN="TOP" BGCOLOR="#FFFFFF">
TM
<TABLE border="0" CELLSPACE="0" CELLPADDING="3">

<TR>
<TD>
<INPUT TYPE="text" NAME="KEYWORD" SIZE="18" </TD>
<INPUT TYPE=HIDDEN NAME="isNewSearch" VALUE="">
<TD. <INPUT TYPE="SUBMIT" VALUE="mySearch"> </TD>
</TR>
</TABLE> </TD> </FORM>

Now that you have set up the link for your custom search you need to create your
custom search folder. The custom search folder contains the search_faciltiy.xml file that
provides WebPublisher with search arguments.
To create a custom search type folder:

2. In the default folder, create a views\search_facility\<custom search type>folder
structure.
3. Navigate to RightSite\applications\wcm\product\search_facility\simple.
4. Copy the search_facility.xml file from the product folder to the custom search type
folder that you created in step two.
To modify the search_facility.xml file refer to The Search Facility XML File.
TM
Chapter 7
Customizing Content Pages
This chapter explains how to customize content pages. Content pages enable WebPublisher users to
create content for Web pages. Content is the text, graphics, scripts and other output that you create
for Web pages. When you create content in WebPublisher, you are creating the information that is
combined with a WebPublisher page type to produce a Web page.
For WebPublisher Pro you will customize the IMPORT page. For WebPublisher you will customize
the CREATE PAGE tab.
This chapter discusses the following topics:
• Customizing the Import Page
• Customizing the Create Page Tab
Customizing the Import Page

This section explains how to customize the existing default IMPORT page in
WebPublisher by adding, removing, and modifying existing search attributes.
The IMPORT page for administrators and Web developers.
The WebPublisher untyped import_object.xml file.
The user clicks IMPORT to open the IMPORT page.
You now need to decide what on the page you want to modify.
To open the Import page:
1. Connect to WebPublisher Pro as an administrator or Web developer.

2. Navigate to a folder and click the IMPORT link.
TM
This is the default IMPORT page that you want to modify.
Figure 7–1. Default Import Page
The IMPORT page is made up of an editable section and a Read-Only section. The
editable section can be modified through the import_object.xml file to display changes
for administrators and Web developers.
TM
Copying the XML Files

To make any customizations copy WebPublisher’s default import_object.xml file from
the product directory to the custom directory. When you modify the XML file, add
only attributes that you have previously defined for the SOP object type in DDS. To use
attributes that do not already belong to the SOP object type, you must use DDS to add
attributes to the SOP object type, then modify the XML file to display the attributes.
If you look in the product directory hierarchy, you see that under \operations there is an
import_object directory; you need to recreate the \operations\import_object under the
custom directory to create a customized IMPORT page.
to the custom directory.
To copy the XML files:
2. In the default folder, create an operations folder\import_object structure.
3. Navigate to RightSite\applications\wcm\product\operations\import_object.
4. Copy the import_object.xml file from the product folder to the custom folder that
5. You should now see the following in your custom directory:
If you open the import_object.xml file you copied to custom\default\operations\import_

object, you can see that it has an attribute list section. The attributes in each section are
displayed on the IMPORT page in the exact order you see in the XML file and each
attribute can be customized.
The attribute list looks as follows:
<import_object>
<attributelist>
<attribute>
</attribute>
<attribute>
</attribute>
</attributelist>
</import_object>
You can add or delete attributes, and change the full-text index flag.
TM
Adding or Removing Content
To add or remove content from the Import page:

C:\RightSite\applications\wcm\custom\default\operations\import_
object\import_object.xml.
type to be SOP.
to
The base type can be any custom object type as long as the object type is a subtype of
dm_document and has been installed with your custom DocApp.
4. Type the following code to add a Subject attribute to the IMPORT page.
<attribute>
<name>Subject</name>
<label>Subject</label>
</attribute>
<attribute>
</attribute>
Each document must have an effective date. If you remove the effective date from
the IMPORT page WebPublisher will derive the document’s effective date from the
<attribute>
</attribute>
from the IMPORT page WebPublisher will use the default expiration date of 15
Configuration page in WebPublisher/Properties.
TM
Changing the Full-Text Index Flag
You can set the full-text index flag to true or false in the add_content.xml file. If this flag
is set to true then the full-text index option is set on the document. The eContent server
will periodically run a process that full-text indexes the flagged document. If this flag is
set to false then the full-text index option is not set on the document.
To change the full-text index flag:

C:\RightSite\applications\wcm\custom\default\operations\import_
object\import_object.xml.
2. If you want to change the full-text index flag to false change the following code:
<enable_full_text_index>true</enable_full_text_index>
to
<enable_full_text_index>false</enable_full_text_index>
By default, WebPublisher sets the full-text index flag to true.
Test your customizations to ensure that you have correctly modified the XML files.
To test the customizations
1. Connect to WebPublisher as administrator.

2. Verify that you can see the custom attribute Subject on the IMPORT page.
Customizing the Create Page Tab

This section explains how to customize the existing default CREATE PAGE tab in
WebPublisher by adding, removing, and modifying existing attributes.
• Where will content authors and content managers see the result?
The CREATE PAGE tab.
The WebPublisher add_content.xml file.
TM
The user clicks the CREATE PAGE tab and navigates to a template from which
to create new content.
You now need to decide which content fields on the tab you want to modify.
To open the Create Page tab:
1. Connect to WebPublisher as a content author or content manager.

2. On the Create Page tab, click the template category.
3. Click the template you want to use for your new content.
Your content fields display.
The CREATE PAGE tab is made up of an editable section and a Read-Only section. The
editable section can be modified through the add_content.xml file to display changes for
content authors and content managers. The Read-Only section cannot be modified.
Copying the XML File

To make any customizations copy WebPublisher’s default add_content.xml file from
the product directory to the custom directory. When you modify the XML file, add
only attributes that you have previously defined for the SOP object type in DDS. To use
attributes that do not already belong to the SOP object type, you must use DDS to add
attributes to the SOP object type, then modify the XML file to display the attributes.
If you look in the product directory hierarchy, you see that under \operations there is
an add_content directory; you need to recreate the \operations\add_content under the
custom directory to create a customized CREATE PAGE tab.
to the custom directory.
To copy the XML file:
2. In the default folder, create an operations\add_content structure.
3. Navigate to RightSite\applications\wcm\product\operations\add_content.
4. Copy the add_content.xml file from the product folder to the custom folder that
5. You should now see the following in your custom directory:
If you open the add_content.xml file you copied to custom\default\operations\add_

content, you can see that it has an attribute list section. The attributes in each section are
TM
displayed on the CREATE PAGE tab as content fields in the exact order you see in the
XML file and each attribute can be customized.
The attribute list looks as follows:
<add_content>
<attributelist>
<attribute>
</attribute>
<attribute>
</attribute>
</attributelist>
<add_content>
You can add or delete attributes, and add a full-text index flag.
Adding or Removing Content
To add or remove content:

content.xml.
type to be SOP.
to
The base type can be any custom object type as long as the object type is a subtype of
dm_document and has been installed with your custom DocApp.
4. Type the following code to add a Subject attribute to the CREATE PAGE tab.
<attribute>
<name>Subject</name>
<label>Subject</label>
</attribute>
TM
<attribute>
</attribute>
Each document must have an effective date. If you remove the effective date from the
CREATE PAGE tab WebPublisher will derive the document’s effective date from the
<attribute>
</attribute>
from the CREATE PAGE tab WebPublisher will use the default expiration date of 15
Configuration page in WebPublisher/Properties.
Changing the Full-Text Index Flag
You can set the full-text index flag to true or false in the add_content.xml file. If this flag
is set to true then the full-text index option is set on the document. The eContent server
will periodically run a process that full-text indexes the flagged document. If this flag is
set to false then the full-text index option is not set on the document.
To change the full-text index flag:

content.xml.
2. If you want to change the full-text index flag to false change the following code:
<enable_full_text_index>true</enable_full_text_index>
to
<enable_full_text_index>false</enable_full_text_index>
By default, WebPublisher sets the full-text index flag to true.
Test your customizations to ensure that you have correctly modified the XML files.
TM
To test the customizations:
1. Connect to WebPublisher as a content author or content manager.

2. Verify that you can see the custom attribute Subject on the CREATE PAGE tab.
TM
TM
Chapter 8
Creating a Custom Feature
This chapter explains how you can create new features either by using an existing feature as a starting
template, or by writing your own using the information in other sections of this guide.
To create a new feature:
1. Create a new subdirectory under the class of feature (views or operations) directory.
• If you want the feature to apply to a particular Docbase only, create this
subdirectory in the \custom\Docbase_name folder.
• If you want this feature to apply across all Docbases, create it in the
\custom\default folder.
2. Within your new feature’s subdirectory, create all the templates, configuration files,
scripts, and icons that are unique to the new feature and simply allow the rest of the
components be inherited from the parent object types’ directories.
3. You must also add the jumping-in point for your feature to either the ACTIONS
page, the title page fragment for the object type, or a list item to which it applies.
Customizing the Action List

An action list is a list of operations that users can perform on selected documents. The
action list displays on the right hand side of the WebPublisher window.
In this section you will add a new action, remove an existing action, and filter the actions
in alphabetical order.
Actions you can perform are listed in two places:
• The top of the tab displays actions that apply to the container you are viewing, such
as the folder you are displaying. The top of the tab also might display the SHOW
field, which lets you choose what information to display.
• The right of the tab displays actions you can perform on the listed items. You select
TM
the checkboxes of the items on which you want to perform an action, and then you
click the action. To select all items, check all. If an action has two arrows, you can
select multiple items before clicking the action. If an action has one arrow, you can
select only one item before clicking the action
The default channel action list on the FILE LIST page within a cabinet should look
similar to the following figure.
Figure 8–1. Default Channel Action List
As before, ask yourself.

In the action list there will be a new action labeled Send Attachment.
The WebPublisher actionlist.xml file, and a custom folder under
custom\default\operations.
TM
The user must navigate to the page whose action list was modified. In the following
examples, the channel action list is modified.
To modify the channel action list, customize the actionlist.xml file for
your Send Attachment action. You must copy the actionlist.xml file from
product\actionlist\wcm_channel_fld to custom\default\actionlist\wcm_channel_fld,
and you must create a folder for your custom action under custom\default\operations.
Copying the actionlist.xml File

If you look in the product directory hierarchy, you see that under \actionlist there are
many different folders, each with a different actionlist.xml file. To create a customized
action such as Send Attachment you need to copy the actionlist.xml from your product
directory to your custom directory.
To copy the actionlist.xml file:

2. In the default folder create an actionlist\wcm_channel folder structure.
3. Navigate to RightSite\applications\wcm\product\actionlist\wcm_channel_
fld\actionlist.xml.
4. Copy the actionlist.xml file from the product folder to the wcm_channel_fld folder
that you created in step two.
Creating a New Action Folder

If you look in the product directory hierarchy, you see that under \actionlist there are
many different folders. To create a customized action such as Send Attachment you
should create a new SendAttachment action folder under \custom\default\operations.
To create a SendAttachment folder:

2. In the default folder create an operations\SendAttachment folder structure.
TM
Adding a New Feature

If you open the actionlist.xml file you copied to custom\default\actionlist\wcm_
channel_fld, you can see that it is divided into groups of feature lists. Each group is
displayed in the WebPublisher action list under File, Edit, Publish, and Show.
In this example we show the default checkout action.
<feature process_type="dm_document" multiselect=
"true" include_pid="true" currentVerOnly="true"/>
<name>multi_checkout</name>
<label>MSG_ACTIONLIST_CHECKOUT</label>
<arguments>no_editor=true</arguments>
</feature>
Each feature list contains features or operations that can be performed on selected
documents. Following is an explanation of the feature elements.
• process type: an object type that is a subtype of dm_sysobject for example, a
dm_document object type or a custom object type. Only documents of this process
type can access this feature. If you have created a custom object type for a custom
feature you would enter the custom object type here.
• currentVerOnly: This element can be set to true or false. True enables users to perform
operations on only the current version of a selected document. False, or deleting this
attribute, enables users to perform operations on any version of a selected document.
• name: The name of the operations\<new action> folder. For example,
operations\SendAttachment.
• Label: The name displayed in the user interface. This name is usually taken from the
data dictionary. If no name is available in the data dictionary then WebPublisher
will use whatever name is in the <label> </label>attribute. For example, Send
Attachment.
• arguments: Some features contain arguments that provide WebPublisher with
directions for an operation. For example, the multi checkout feature contains the
argument no_editor=true. This argument tells WebPublisher not to launch an editor
when multiple documents are selected and checked out. If you want to create a
custom argument you must first code the argument for the feature to which you are
attaching the argument. By default WebPublisher looks in the start.htm file for
arguments. You can change this starting file to any file you wish by adding the
following code to the actionlist.xml file for your custom action.
entry="<new_filename>"
• include_pid: Some features contain an include parent Id (pid) element. This element
tells WebPublisher to include the parent ID of the current folder. The URL provides
WebPublisher with information on the operation as well as the location of the
document to which the operation is being performed.
TM
• multiselect: This feature determines if users can perform an action on multiple

documents. For example, the multi checkout feature contains the element
multiselect=true enabling users to checkout multiple documents at one time. You
can set this element to be true or false.
The following actions do not support multiselect: any actions under the Show group,
the Web view action, and the synchronize action.
• filter: You can filter actions depending on WebPublisher preferences. For example,
if you have chosen to disable the globalization setting you will want to hide the
translation action in the action list. To hide or display an action you must set a
filter to true or false. If you set the filter to true you must tell WebPublisher what
to validate. You use a class path in the actionlist.xml file to point to a Java class file
that does the validation.
Following is an example of a Java class file created to test whether the translation filter
is set to true or false. If the filter is set to true WebPublisher validates against the Java
class file for and enabled or disabled value to determine the display of the globalization
setting. The WebPublisher default is set to disabled. If the filter is set to true then the
globalization setting is enabled.
You can use your own logic in the Java file to validate the filter. The only stipulation
is that you need to the implement IActionListFilter interface and you must return
IActionListFilter.ENABLED or IActionListFilter.DISABLED.
package com.documentum.webclient.views;
import com.documentum.wcm.xml.*;
import com.documentum.webclient.*;
import com.documentum.wcm.*;
public class TranslationFilter

implements IActionListFilter
{
/**
* Show the categories folder with title and links
*
* @param args Ignore
*/
public int filter(XMLElem theFeature) {
try
{
boolean isGlobalizationOn;
isGlobalizationOn = Application.getUtils()
isGlobalManagementOn();
if (isGlobalizationOn)
return IActionListFilter.ENABLED;
else
return IActionListFilter.DISABLED;
TM
}
catch(Exception e)
{
return -1;
}
} // filter()
} // TranslationFilter Class
To further modify the action list you can delete any feature, or rearrange features so they
are presented to the user in a different order on the WebPublisher user interface.
To add a new action:
1. Using a text editor, navigate to your custom\default\actionlist\wcm_channel_fld

folder and open the actionlist.xml file.
2. Scroll to the Edit feature group.
<actionlist>
<filter_classpath>com.documentum.webclient.views.TranslationFilter
</filter_classpath>
<feature multiselect="true" process_type="sop" include_pid="true"
currentVerOnly="true">
<name>send_attachment</name>
<label>SEND ATTACHMENT</label>
</feature>
</actionlist>
5. Connect to WebPublisher.
You should see the following action Send Attachment in the action list under the
Edit group.
TM
TM
TM
Chapter 9
Creating Process Workflows and
Lifecycles
Many companies have policies that govern how specific types of documents work their way through
their useful lives, and beyond. Such policies typically specify the stages that a document passes
through and the activities that occur at each stage. Documentum separates these aspects of document
policy into two concepts: lifecycles, which define the stages of a document’s life, and workflows,
which define sequences of actions that users must perform on the document. Document lifecycles
(DLC) and workflows complement one another. A DLC specifies the states a document occupies
during its life. The DLC does not define what activities happen to a document while it resides in a
state, who is responsible for those activities, or when the document should move to another state. A
workflow defines a connected set of activities, including who performs the activities and when.
WebPublisher uses process workflows to ensure that Web pages adhere to your organization’s
review and management requirements before they are published on a production Web site. Process
workflows manage Web page content from its creation in a Docbase to its publication on an external
Web site. A process workflow consists of a standard Documentum 4i workflow integrated with
a Documentum 4i lifecycle. You can use the same workflow for all content or create many different
workflows for different kinds of content or different authoring groups.
Administrators can use default process workflows as a basis for creating new process workflows
with different reviewers, steps, and actions, depending on your organization’s requirements.
Administrators can modify task performers using groups or alias sets, modify approval and rejection
paths, and customize workflow source files to provide their own alias suggestion values for every
alias.
Using a process workflow, you can set WebPublisher to promote content objects automatically to
the next state in their lifecycle when a particular task owner submits the change set. The lifecycle
controls the publishing and end-of-life processing for the objects in the change set. The creator of a
workflow or lifecycle needs to have the WebPublisher Default ACL assigned to them. This ACL
enables users to participate in the workflow or lifecycle. Please refer to Using WebPublisher Pro for
more information on change sets.
A document lifecycle (DLC) encodes business rules for changes in the properties of an object
as it moves through the stages of its life (for example, review, publishing, and end-of-life). All
WebPublisher lifecycles have a minimum of four lifecycle states: Start, WIP, Staging, and Approved.
An administrator can create new lifecycles with additional states between the WIP and Approved
states, and can change the names of these default states.
TM
Creating Process Workflows and Lifecycles
WebPublisher assigns the Work In Progress (WIP) state to all newly created or newly versioned
content. WebPublisher automatically launches a process workflow when a user submits a WIP file
and the file has a default workflow. WebPublisher then automatically creates a change set for the file.
Once the process workflow begins, the change set appears as a task for the next performer. Performers
can view or edit the files and supporting files in the change set and they can add files or delete files
from the change set. When a performer forwards the task, WebPublisher automatically promotes the
change set (if configured to do so) to the next state in the lifecycle. The change set then appears as
a task for the next performer in the workflow.
Administrators can configure WebPublisher so that any reviewer can reject a workflow task, which
means they do not approve of the content. A rejection of a task could return WebPublisher to the
previous task and demote the change set from its current state back to the previous state. The actions
of a reject task are determined by the workflow template designed by the workflow designer.
If a workflow task is rejected, and the workflow template rejection path points back to a group, all
users of that group will receive the rejection notice, not just the user that originally acquired the
task in the group.
Creating Simple Process Workflows

Administrators use Documentum Workflow Manager to create workflow templates
which specify a series of tasks to be performed by specific participants in a specific
order. You can access Workflow Manager through Developer Studio. Workflow Manager
provides a graphical environment in which you can design or modify workflow
templates. Workflow templates behave like other objects in the Docbase. You can check
them out, modify them, and check them in as new versions.
To start creation of a workflow template:
1. Open Workflow Manager.

2. Log in to Workflow Manager as a WebPublisher administrator.
A WebPublisher administrator should have super user permissions.
TM
3. Choose File>Save As and select a WebPublisher default workflow. For example,

French Translation Workflow.
This opens a default WebPublisher workflow on which to base your custom
workflow.
4. Choose File>Save As and save the workflow with a name that represents the
workflow.
All workflows must be saved in the System\Applications folder. You can create a
new folder for example, Spanish Translation Workflows or save your workflows to
the WebPublisher folder.
5. Click OK.
6. Select COPY and click OK.
This choice copies activities from the default template to the new template. Copying
enables you to modify activities without affecting the default template.
Please refer to the Using Workflow Manager online Help for more information on creating
workflows.
In the following example, a content author creates content and submits it to a reviewer
at which time WebPublisher creates a change set containing the content file. When the
reviewer finishes the task, the reviewer submits it to the content author. The content
author looks at the task and notes from the reviewer, and submits the change set to the
Web developer, and the lifecycle of the change set (and the files in the change set) changes
from WIP to Staging. If the Web developer submits the task, WebPublisher promotes the
change set to Approved and the workflow ends. If the Web developer rejects the task,
WebPublisher demotes the change set to WIP and returns it to the content author.
TM
Creating Translation Workflows

Translation workflows are simple process workflows with special tasks used to translate
a document. Using Documentum Engagement Services users and groups inside or
outside your organization can contribute content through WebPublisher translation
workflows as email attachments. When this content arrives, Engagement Services will
launch a workflow that routes the content through all appropriate stages, including
approval and publication
Please refer to Installing and Using Documentum Engagement Services for more detailed
engagement server information.
Below is a diagram of a simple process workflow with a translation task.
Figure 9–1. Simple Process Workflow with Translation Task
Following is a description of the tasks and their correct settings that appear in the
Figure 71.
Initialize: This is the workflow starting task. You must set the performer to be a Docbase
owner, and the automatic WebPublisher method to be wcmInitializeProcessWorkflow. At
this time WebPublisher creates a change set to include all the documents to be translated.
The documents display in WebPublisher with a change set and workflow icon.
TM
Translate: This is the document translation task. The Description must be set to one
of the three descriptions.
• trans_internal: <comment to next performer><(locale)>
• trans_external: <comment to next performer><(locale)>
• trans_launch_wf: <comment to next performer><(locale)>
The three translation tasks will have different information in this dialog box. Please
refer to the following examples for more information. The locale is especially important
because internally WebPublisher does not allow the original language files in the change
set to be translated. WebPublisher makes a copy of the original files and enables only the
copies to be translated. For example, if two English documents need to be translated
the trans_internal change set will contain four documents after translation, two English
original documents and two translated documents. All users will see four documents
except the translator who will only see two documents. With this information,
WebPublisher determines which translation activity to run, and which documents to
display to the performer for translation.
Promote To Staging: This is an automatic promote task. Once the translation task is
complete the documents are automatically promoted for review. You must set the
performer to be a Docbase owner, and you must set the automatic WebPublisher method
to be wcmPromoteToStaging. This method automatically promotes all the files in the
change set from WIP to Staging in the lifecycle unless this is a trans_launch_wf. If this is
a launch task only the files in the trans_launch_wf change set are promoted.
TM
Reviewer: This is the reviewer of the translated document task. The reviewer can only
view the documents, they cannot add or edit documents. If the reviewer is not satisfied
with the translation they can reject the documents, sending them back to the translation
task. If the reviewer is satisfied with the translation they can finish their task.
Promote To Approved: This is an automatic promote task. Once the review task is
complete the documents are automatically promoted to approved. You must set the
performer to be a Docbase owner, and you must set the automatic WebPublisher method
to be wcmPromoteToApproved. This method promotes the translated documents
from Staging to Approved in the lifecycle, and enables users to see the document as an
approved file.
TM
Clean Up: This is an automatic clean up task. Once the approved task is complete
WebPublisher does cleanup of the workflow. You must set the performer to be
a Docbase owner, and you must set the automatic WebPublisher method to be
wcmTerminateProcessWorkflow. This method removes the translated files from the
change set, deletes the change set, and displays the documents to users as an approved
document removing the change set and workflow icon.
TM
trans_internal task
A trans_internal task integrates with a process workflow created for the specific use of
moving documents through a translation process. This task assumes that for a given
locale defined in the task description, documents will be translated by an in-house
translator.
In the following example, a content author creates English documents that need to
be translated into one other language and published to a Web site. Following is a
description of all the task and its correct settings.
Translate: This is the document translation task. The Description must be set to
trans_internal: <comment to next performer><(locale)>. For example, trans_internal:
Translate to French (fr_FR). trans_internal tells WebPublisher that the documents will be
translated by an in-house translator. (fr_FR) tells WebPublisher that the documents in
the change set are going to be translated into French. The locale is especially important
because internally WebPublisher does not allow the original language files in the change
set to be translated. WebPublisher makes a copy of the original files and enables only the
copies to be translated. For example, if two English documents need to be translated
the trans_internal change set will contain four documents after translation, two English
original documents and two translated documents. WebPublisher will only display
two documents to the French translator not four documents. With this information,
WebPublisher determines which translation activity to run, and which documents to
display to the performer for translation.
TM
trans_external task
A trans_external task integrates with a process workflow created for the specific use of
moving documents through a translation process. This type of workflow assumes all
translations will be completed by an outside translator.
The trans_external task indicates that documents will be sent outside the company
to be translated. The process workflow calls Documentum Engagement Services
to start an email process through which documents can be emailed to the outside
translator. To begin this process you need to change the workflow performer method
in the Translate task and associate the task with the automatic performer method
wcmSendTranslationViaSmtp.
TM
Translate: This is the document translation task. The Description must be set to
trans_external: <comment to next performer><(locale)>. For example, trans_external:
Translate to German (de_De). trans_external tells WebPublisher that the documents will
be translated by an outside translator so an email process needs to be launched. (de_De)
tells WebPublisher which documents in the change set are going to be translated into
German. The locale is especially important because internally WebPublisher does not
allow the original language files in the change set to be translated. WebPublisher makes
a copy of the original files and enables only the copies to be translated. For example, if
two English documents need to be translated the trans_external change set will contain
four documents after translation, two English original documents and two German
documents. With this information, WebPublisher determines which translation activity
to run, and which documents to display to the performer for translation.
TM
The workflow template properties can link to a default alias set. If there is no alias
set linked, WebPublisher takes a global alias set defined for the application named
TranslatorEmailAddress. The TranslatorEmailAddress alias set provides translator email
addresses for each language code. The email addresses tell WebPublisher where to send
the documents for translation given the different language codes Following is a table of
some language code and email address examples.
Table 9–1. Language Codes and Email Addresses
Language Code Email Addresses
Fr_CA cafrench@translationsource.com
Fr_FR translations@francais.com
de_DE translations@greatgerman.com
Receive Translation: This task follows an external translation task and is a manual task
with a defined trigger. You can give the trigger any applicable name. This task appears
in a performer’s inbox when the translations are received from an external source
through email, and after the engagement server and a server method finish processing
the received files.
trans_launch_wf task
A trans_launch_wf task is a translation task that can either be a trans_internal task or a

trans_external task. To begin this task you need to associate the task with the automatic
performer method wcmSendTranslationWorkflow.
TM
Translate: This is the document translation task. The Description must be set
to trans_launch_wf: <comment to next performer><(locale)>. For example,
trans_launch_wf: Launch Translation Workflow (fr_FR). trans_launch_wf tells
WebPublisher that a translation task needs to be launched to translate the documents
by another workflow. (fr_FR) tells WebPublisher which translation task to launch. With
this information, WebPublisher determines which translation activity to run, and which
documents to display to the translator.
TM
Troubleshooting Translation Workflows

If you have created a translation workflow that does not get executed properly you
can check to see if:
• your Engagement Services is properly installed and running
• you have properly configured WebPublisher for Engagement Services
• you have properly configured translation workflows
Engagement Services
If you have properly installed Engagement Services the machine on which Engagement
Services is installed and running should have the file esclient.jar in the classpath where
eContent server is running.
If you have properly configured Engagement Services you can send and recieive email.
Test the following three scenarios to pinpoint the issue as eContent server related or
WebPublisher related.
• test esupload.htm to make sure it works
• send email to Engagement Services and make sure it works
TM
Your email format should be test.<docbasename>@eshost.companyname.com. For

example, test.webpublisher@eng999@documentum.com
• test Engagement Services sample ESSendReceiveJava
Please refer to Installing and Using Documentum Engagement Services for detailed
engagement server information.
WebPublisher Configuration
The WebPublisher default DocApp automatically configures WebPublisher to work with
Engagement Services. If you have created a custom DocApp you might not have created
the correct components to interact with Engagement Services. If you run into translation
workflow problems you can check WebPublsiher’s configuration to ensure that the
DocApp was created and installed correctly.
• check if the Engagement Services host address is entered in the WebPublisher System
configuration
The host address should not contain port numbers. For example,
eng999.documentum.com NOT eng999.documentum.com:9999
• check to ensure the TranslatorEmailAddress alias set was installed with the DocApp
You must have valid email entries defined in the translator email alias sets for your
translation locales. You can define these email entries in Documentum Administrator
or Documentum Developer Studio.
Translation Workflow Configuration

The translation workflow is configured by Documentum and installed with the default
DocApp. If you have created a custom translation workflow the proper configurations
may not be set. Check the translation workflow for the following configurations.
• check to ensure the automated method wcmSendTranslationViaSmtp is defined in
the Translate task which sends the documents to be translated.
• check to ensure a manual task with a defined trigger Ready or a custom trigger is
defined in the Reviewer task or Receive task which receives the translation for review.
• check to ensure a default alias set, Translator Email Address, is defined in
the WebPublisher default DocApp. The Translator Email Address alias set is
automatically installed by the default DocApp but you should check to ensure it was
installed correctly, or has not been removed.
The alias set must exist in the DocApp with valid email entries for your translation
locales.
• check to ensure that one record exists for each alias set used by the translation
workflow.
TM
For further troubleshooting information you can view the Server Logs which
records Engagement Services integration activities. You can view the server
logs under Menu>Logs in Documentum Administrator, or you can navigate to
c:\documentation\dba\log.
Custom Dynamic Performer Values

As an administrator you can create a workflow that requires the workfow initiator or
designer to select a dynamic performer value for an alias. In this example we will only
show you how to include dynamic performer value information for the workflow
initiator. By default, WebPublisher displays all groups and all users as alias suggestion
values. You can create your own alias suggestion values to display for any existing
alias—custom or default.
This section explains how to modify a workflow task by creating custom dynamic
performer values.
The start workflow task and during creation of a workflow.
The start_workflow.xml file.
The user starts a workflow which has been designed to use dynamic performer
values.
Creating a Dynamic Perfomer Value

To create a customized dynamic performer value in the start workflow task you need
to create a start_workflow.xml file. The start_workflow file enables users to select a
dynamic performer value during the start of a workflow.
If you look in the product directory hierarchy, you see that there is no default
start_workflow.xml file. You need to create this file from scratch in your custom folder
structure.
To create a start_workflow.xml folder:

2. In the default folder create an operations\start_workflow folder structure.
TM
To create a new dynamic perfomer value:
1. Using a text editor, create a start_workflow.xml file in your

custom\default\operations\start_workflow folder.
2. Following is some example code to help you create your start_workflow.xml file:
<start_workflow>
<filter_classpath>com.documentum.webclient.FilterWFPerformers
</filter_classpath>
</start_workflow>
In this example, the attribute value, and filter_classpath provide the class path to
your class. The class provides the customized dynamic performer values.
3. Choose File>Save As to save your file as start_workflow.xml.
You now need to provide the class in the path defined in xml file. This class
implements IFilterWFPerformers interface, which is provided by WebPublisher.
The class contains getPerfomer, getDynamicUsersFromGroup, getDynamicUsers,
and getDynamicGroups and returns suggestion dynamic perfomer values in a
string array.
4. Following is some example code to help you create your class path file
package com.documentum.webclient;
import com.documentum.wcm.xml.*;
import com.documentum.wcm.*;
import com.documentum.fc.client.*;
import com.documentum.fc.common.*;
public class FilterWFPerformers implements IFilterWFPerformers

{
/**
* @param String wfTemplateId - user selected workflow template id
* @param String aliasName - alias name
* @param int aliasType - alias type (use static variable
defined in interface class
* public static final int UNKNOW_ALIAS = 0;
* public static final int USER_ONLY = 1;
* public static final int GROUP_ONLY = 2;
* public static final int USER_OR_GROUP = 3;
* public static final int CABINET_PATH = 4;
* public static final int FOLDER_PATH = 5;
* public static final int ACL_NAME = 6;
* @return string[] performerList performers’ name
- please look at sample below.
* If the performer is the default selection,
then the value is [default]name.
* public static final String DEFAULT_ALIAS = "[default]";
*/
TM
public String[] getPerformers(String wfTemplateId, String aliasName,

int aliasType)
{
String str[]= {"spring season", "summer season", "fall season",
"winter season"};
return str;
}
public String[] getDynamicUsersFromGroup(String wfTemplateId,

String activityName, String groupValue)
{
String str[]= {"tuser1", "tuser2", "tuser3", "tuser4"};
return str;
}
/**
* Give a list of users based on workflow template and activity name
* @param wfTemplateId workflow template ID
* @param activityName activity name which performer need to be assigned
* @return string[] users list
*/
public String[] getDynamicUsers(String wfTemplateId, String activityName)
{
String str[]= {"tuser1", "tuser2", "tuser3", "tuser4"};
return str;
}
/**
* Give a list of groups based on workflow template and activity name
* @param wfTemplateId workflow template ID
* @param activityName activity name which performer need to be assigned
* @return String[] group list
*/
public String[] getDynamicGroups(String wfTemplateId, String activityName)
{
String str[]= {"content author", "content manager",
"web developer", "administrator"};
return str;
}
} // class FilterWFPerformers
5. Choose File>Save As to save your file as FilterWFPerformers.java.

6. If you want to implement this feature for the submit task you can add this code
to the task_manager.xml file.
a. Copy the task_manager.xml file from wcm\product\views\task_manager to
custom\default\views\task_manager.
TM
b. Using a text editor, open the task_manager.xml file from

custom\default\views\task_manager.
c. Add the follollowing code.
<task_manager>
(existing task manager xml content)
<filter_classpath>com.documentum.webclient.FilterWFPerformers
</filter_classpath>
</task_manager>
d. Choose File>Save.
TM
Chapter 10
Creating a Web Site
This chapter examines the creation of a WebPublisher managed Web site and the installation of the
Accelera DocApp to numerous Docbases. The Accelera DocApp should already be installed to
your test WebPublisher Docbase. Please refer to Installing WebPublisher for instructions to install
the Accelera DocApp.
Creating a Web site brings all your WebPublisher customization knowledge together so you can
create and manage a Web site that is specific to your company’s business processes and look and feel.
You will learn how to design a Web page using customized WebPublisher Editor templates, and a
customized DocApp of components such as object types, lifecycles and permission sets. You will learn
how to install the DocApp, and create new content for the Web page using your customized XML
components such as the IMPORT page, and PROPERTIES page.
To help you understand how the Web page components work together Documentum has created a
sample Web site for Accelera Communications a fictional company. This sample Web site presents
information for different cellular phones and cellular phone services, and company press releases.
The Web site includes:
• product name
• product number
• product price
• product image selector
• product description
• product benefits
The sample Web site contains an XML and HTML example of the Editor rules file and content
template, and an XSL example of the Editor presentation file.
Note: You should have a base knowledge of XML, XSL, HTML, and Web page creation methodology.
WebPublisher Editor and Templates

WebPublisher provides an internal content editing application called WebPublisher
Editor. WebPublisher Editor is a content editing application in WebPublisher that you can
TM
Creating a Web Site
customize through WebPublisher Editor templates and files. The default WebPublisher
Editor consists of four different types of templates and files that work together.
• Editor rules file
• Editor presentation file
• thumbnail file (optional)
• content template
The files provide the layout and other non-content related elements (such as JavaScript
code) used in a Web page. Web developers create WebPublisher files in any appropriate
authoring application (Dreamweaver, FrontPage, Notepad). Web developers can also
manually import files that were not created in Dreamweaver into the Docbase (or
DocApp if you want to deploy the files to multiple Docbases). When the DocApp is
installed to the Docbase, the files are also installed.
Templates are the files upon which content files are based. When an author chooses a
template, WebPublisher makes a copy of the template and saves it as a new content file.
The content file inherits the template’s content and properties.
Supporting files include Editor rules files and thumbnail files, both of which define
behaviors within WebPublisher. In order to be used with a template, a supporting file
must be associated with the template.
You create templates and supporting files in external applications, and then import them
into WebPublisher’s Configuration cabinet.
thumbnail file enables a graphical representation of a template. Refer to Using
WebPublisher Pro for more information about using WebPublisher the templates and files,
and Chapter 10, Creating a Web Site for an example Web page.
Web developers create templates in any appropriate authoring application (FrontPage,
Notepad) and import them in to a Docbase (or DocApp if you want to deploy the
templates to multiple Docbases).
Once the files are installed, Web developers can check out files, work on files in the
editing application, and check in and version the files.
To create and test WebPublisher Editor templates:

Here is an overview of the steps you need to perform to publish content to the Web.
1. Create a Web page.
2. Create a content template.
3. Create an Editor rules file.
4. Create an Editor presentation file.
TM
Creating a Web Site
5. Create a thumbnail file.

6. Import the content template and supporting files into WebPublisher.
7. Validate the content template.
8. Associate the content template with the supporting files.
9. Add new content using the template.
10. Publish the content to a standard WIP.
11. Promote the content template, Editor rules file, Editor presentation file, and
thumbnail (if you have one).
Please refer to Using WebPublisher Pro for more information on creating and using
WebPublisher Editor templates.
Creating Editor Rules Files

An Editor rules file is an XML file that determines which elements or attributes in an
XML- or HTML-based content file can be edited in WebPublisher Editor. Each rule
names an element or attribute and determines which WebPublisher Editor field edits
the information. A rule also determines how the field behaves. You associate an Editor
rules file with a WebPublisher Editor template. The Editor rules file is then automatically
associated with any content files created from that template.
This following topics explain the Rules File tags used to create WebPublisher Editor
fields. For related information, see the Rules File Wizard and Using WebPublisher Pro.
• <textline>, page 10–4
• <content>, page 10–6
• <choice>, page 10–15
• <graphic>, page 10–17
• <textselector>, page 10–29
• <checkbox>, page 10–41
• <tabledef> (Defining a Table), page 10–43
• <repeatdef> (Repeating a Field), page 10–45
• <xselector>, page 10–48
• <texttrigger>, page 10–63
TM
Creating a Web Site
Tagcontent Widgets in Non-XML WebPublisher Editor Templates
When creating tagcontent widgets for non-XML WebPublisher Editor templates (e.g.
HTML-based templates), place the following tag in the file where you want the data to
be stored:
<dctmEditor teComponentType="myelement">default data
</dctmEditor>
The rules file would read:
<tagcontent tag_name="myelement"></tagcontent>
While we recommend using the <dctmEditor> tag for all non-attribute WebPublisher
Editor tags within HTML-based templates, we strongly recommend using the
<dctmEditor> tag whenever the widget referred to in the rules file is a content widget.
Specifically, because of the possibility of improper nesting, do not add the
teComponentType attribute to any other type of tag the content widget itself produces
(especially tags like , , etc.).
Note: If you use a tagattribute widget, put teComponentType in the tag where you
want the attribute to be stored, as before:
<img border="0" teComponentType="myelement">
<tagattribute tag_name="myelement" selected_attr="src">
</tagattribute>
<textline>
The <textline> element creates a single-line text field. The <textline> element is nested in
the <tagcontent> or <tagattribute> element.
Figure 10–1. Textline field
TM
Creating a Web Site
Table 10–1. <textline> Attributes
Attribute Description Syntax Example
default Allows you to populate ’TODAY+/-[number default=’TODAY,MM/dd/

the text line with a of days],date format’ yyyy’
particular date when
the user opens the where default=’TODAY+15,dd-
file in WebPublisher MM-yyyy’
MM=month,
Editor. The date shows
default=’TODAY-365,MM-
up only if there is no dd=date of the month, dd-yy hh:mm’
data saved in the XML
file; if there is already yy=2-digit year,
something saved, that
data displays instead. yyyy=4-digit year,
If omitted. By default
hh=hours,
can show today’s
date or the date some
mm=minutes
number of days before
or after today’s date.
instruction Allows you to provide ’String’ instruction=’Be sure to

instructions on what type the name exactly as it
to do with this field; appears in the directory.’
displays below and in
a smaller font than the
label. The instructions
can be several lines
long. If omitted,
WebPublisher Editor
collapses the space
normally reserved for
instructions.
label Functions as a title ’String’ label=’Name’

for the field; displays
in bold. If omitted,
WebPublisher Editor
collapses the space
the label.
TM
Creating a Web Site
readonly If set to Yes, the author ’Y’ or ’N’ readonly=’Y’

is not able to enter any
data into this field. The
field is grayed out. If
omitted, WebPublisher
Editor defaults to ’N’.
required If set to Yes, the author ’Y’ or ’N’ required=’Y’

is not able to save until
this field has some
data entered. The
field is marked with
a red star. If omitted,
WebPublisher Editor
defaults to ’N’.
<content>
The <content> element creates a multi-line text box with an editing toolbar. The
<content> element is nested. If you are creating a rules file for a non-XML template, see
When Creating Non-XML Templates, page 10–14.
Figure 10–2. Content field
TM
Creating a Web Site
Table 10–2. <content> Attributes
align Determines whether the ’Y’ or ’N’ align=’Y’

alignment formatting buttons
are available. If available, the
HTML align attribute on the
paragraph tag is stored within
your XML, like this:
what the user

typed
If omitted, WebPublisher
bold Determines whether the bold ’Y’ or ’N’ bold=’Y’

formatting button is available.
If available, the HTML bold
tags are stored within your
XML, like this:
what the user typed
color Determines whether the font ’Y’ or ’N’ color=’Y’

color formatting button is
available. If available, the
HTML font tags are stored
within your XML, like this:
what the user
typed
Colors are stored as

hexadecimal triplets
(#FFFFFF), not as color
names (white). 48 colors
are available. If omitted,
WebPublisher Editor defaults
to ’N’.
TM
Creating a Web Site
copy Determines whether the ’Y’ or ’N’ copy=’Y’

copy button is available.
If available, the author is
able to perform normal
copy operations between
applications, using the
system clipboard. If omitted,
to ’Y’.
cut Determines whether the ’Y’ or ’N’ cut=’Y’

cut button is available. If
available, the author is able to
perform normal cut operations
between applications, using
the system clipboard. If
omitted, WebPublisher Editor
defaults to ’Y’.
fontSize Determines whether the font ’Y’ or ’N’ fontSize=’Y’ Be sure

size formatting buttons will to capitalize correctly.
be available. If available, the XML is case-sensitive.
HTML font tags are stored
within your XML, like this:
what the user

typed
The base font size is assumed

to be 3. Each click of the
increase button will increase
the value by 1; each click of the
decrease button will decrease
by 1. If omitted, WebPublisher
TM
Creating a Web Site
formats Filters the files visible in the ’dm_format’ formats=

tree when the user clicks the ’crtext,html,pdf’
hyperlink button, and then Specify as
clicks the "Browse Docbase" many as you
button. This allows you to would like,
show only certain formats, separated by
reducing the potential for commas. Be
error. This attribute is only sure that you
applicable if links=’Y’. If use the name
omitted, WebPublisher Editor of the format
defaults to the formats crtext as specified in
and html. Documentum
Administrator.
indent Determines whether the ’Y’ or ’N’ indent=’Y’

indent formatting buttons will
be available. If available, the
HTML blockquote tags are
stored within your XML, like
this:
<BLOCKQUOTE>what
the user typed</
BLOCKQUOTE>
instruction Allows you to provide ’String’ instruction=’Type in

instructions on what to do the body of the press
with this field; displays below release’
and in a smaller font than the
label. The instructions can be
several lines long. If omitted,
WebPublisher Editor collapses
the space normally reserved
for instructions.
italic Determines whether the italic ’Y’ or ’N’ italic=’Y’

formatting button is available.
If available, the HTML italic
tags are stored within your
XML, like this:
what the user typed
TM
Creating a Web Site
label Functions as a title for the ’String’ label=’Body of the press

field; displays in bold. If release’
collapses the space normally
reserved for the label.
lines The greater the number of ’#’ lines=’10’

lines you specify, the bigger
the area the author has in
which to type. If omitted,
to 5.
links Determines whether the ’Y’ or ’N’ indent=’Y’

author is able to add
hyperlinks. If available,
the HTML anchor tag will be
this:
<A href="what the user

typed">what the user
typed</A>
Note that currently

WebPublisher Editor will
error if the user types in
anything that makes the XML
no longer well-formed, such as
these symbols: ’ < If omitted,
to ’N’.
orderedLists Determines whether the ’Y’ or ’N’ orderedLists=’Y’ Be

numbered list formatting sure to capitalize
button is available. If correctly. XML is
available, the HTML ordered case-sensitive.
list tags are stored within your
XML, like this:
<OL><LI>what the user

typed</LI></OL>
TM
Creating a Web Site
paste Determines whether the ’Y’ or ’N’ paste=’Y’

paste button is available.
If available, the author is
able to perform normal
paste operations between
applications, using the
system clipboard. Note that
when pasting between some
applications such as Microsoft
Word, formatting and symbols
may be lost or altered. If
defaults to ’Y’.
readonly If set to Yes, the author is not ’Y’ or ’N’ readonly=’Y’

able to enter any data into
this field. The field is grayed
out. If omitted, WebPublisher
required If set to Yes, the author is not ’Y’ or ’N’ required=’Y’

able to save until this field has
some data entered. The field
is marked with a red star. If
spellcheck Determines whether the ’Y’ or ’N’ spellcheck=’Y’

spellcheck button is available.
This attribute must be set
to ’N’ if you are using the
Japanese or Korean languages.
Editor defaults to ’Y’.
TM
Creating a Web Site
enable_locale_ Filters the files visible in the ’Y’ or ’N’ enable_locale_fallback=

fallback tree when the user clicks the ’Y’.
hyperlink button, and then
clicks the "Browse Docbase"
button. This allows you to
show only the translation
that matches the content file’s
language (taking into account
fallback rules), reducing
the potential for error. This
option requires that the
WebPublisher Globalization
functionality be enabled.If
enable_locale_fallback=’N’,
all matching files will be
displayed, regardless of
language. If ’Y’, the Editor
will determine the language
of the content file being
edited, and when displaying
the query results will only
display the translation that
is being published to the
same language web site as
the content file (according to
fallback rules). For example,
suppose you have two
graphics: graphic1 has only
an English translation, and
graphic2 has both an English
and German translation.
Suppose the user is editing
a English content file. If
then three files will be
displayed in the tree: graphic1,
graphic2 [English], graphic2
[German]--and the user may
be unable to tell them apart.
TM
Creating a Web Site
enable_locale_ However, if enable_locale_ ’Y’ or ’N’ enable_locale_fallback=

fallback fallback=’Y’, then only ’Y’.
graphic1 and graphic2
[English] will display. Now
suppose the user edits a
German content file. If
enable_locale_fallback=’Y’,
then graphic1 and graphic2
[German] will display as
long as German falls back
to English. If German does
not fall back to English, then
only graphic2 [German] will
display.
If omitted, the Editor defaults

to enable_locale_fallback=’N’
symbols Determines whether the ’Y’ or ’N’ symbols=’Y’

author can add special
symbols. The special symbols
are stored in the XML file
using UTF-8 encoding. Be sure
if you add this functionality
that you process the symbols
correctly in your XSL file.
Otherwise, if your authors
have their browser set to
view ISO encoding, they are
not able to see the special
symbols when previewing
or see garbage. If omitted,
to ’N’.
unorderedLists Determines whether the ’Y’ or ’N’ unorderedLists=’Y’

bulleted list formatting button Be sure to capitalize
is available. If available, the correctly. XML is
HTML unordered list tags are case-sensitive.
this:
<UL><LI>what the user

typed</LI></UL>
TM
Creating a Web Site
The WebPublisher Editor contains a spell checker function which is currently using an
English dictionary. To incorporate dictionaries for your supported languages you must
purchase a dictionary license from Wintertree Software, Inc. for each supported language.
The dictionary license enables you to include the dictionaries with WebPublisher.
The Microsoft Interent Explorer editor contains five language dictionaries—English
(US), German, French, Italian and Spanish. The Netscape editor contains one language
dictionary—English (US). The default language dictionary in both cases is English
(US). If the language part of the locale of the file being edited in WebPublisher Editor
matches any of the bundled dictionaries, then that dictionary displays when spellcheck
is invoked. For example, if the file has a locale of fr_CA (French - Canadian). The fr
stands for language French, so the French dictionary file is used. If the file has a locale of
ja_JP (Japanese - Japan). There is no Japanese dictionary file, so the default dictionary file
of English (US) is used.
If you are using Microsoft Internet Explorer you can purchase a Wintertree Software
dictionary and add it to the app\wintertree\ssce folder. If you are using Netscape
you can purchase a Wintertree Software dictionary and modify your te.jar file to
contain the additional dictionaries. You can also modify your dictionary.htm file to
include additional dictionaries. Please refer to Localizing Documentum WebPublisher for
more information on language values and modifying the te.jar file, and Documentum
Technical Support for more information on modifying the dictionary.htm file.
When Creating Non-XML Templates
When creating content fields for non-XML templates (for example, for HTML templates),
place the following tag in the content file at the point where you want the content to
be stored:
<dctmEditor teComponentType="my_element">content to
be stored</dctmEditor>
The value you enter for my_element is read by the rules file as a tag name. The rules file
refers to my_element as follows:
<tagcontent tag_name="my_element">
While we recommends using the dctmEditor tag for all non-attribute WebPublisher
Editor tags within HTML-based templates, we strongly recommend using the dctmEditor
tag whenever the field referred to in the rules file is a content field. Specifically, because
of the possibility of improper nesting, do not add the teComponentType attribute to
any other type of tag the content field itself produces (especially tags like , ,
and .
If you use tagattribute, put teComponentType in the tag where you want the attribute to
be stored, as before:
<img border="0" teComponentType="my_attribute">

<tagattribute tag_name="my_attribute" selected_attr="src">
TM
Creating a Web Site
Any data from the content field that is stored in the XML will contain HTML paragraph
tags, like this:
what the user typed
Any additional formatting, such as bold or ordered lists, is stored as HTML tags within
the the tags. You must process these elements via your XSL file in order for the text
to display. If you do not, your authors might think WebPublisher is "broken".
<choice>
The <choice> element creates a selection list. You can use a query to populate the list.
The <choice> element is nested in the <tagcontent> or <tagattribute> element.
Figure 10–3. Choice field
Table 10–3. <choice> Attributes
instruction Functions as a title for the ’String’ instruction=’Select one

field; displays in bold. Allows of the users listed.’
you to provide instructions
on what to do with this
field; displays below and
in a smaller font than the
for instructions.
label Functions as a title for the ’String’ label=’Name’

field; displays in bold.
Editor collapses the space
normally reserved for the
label.
TM
Creating a Web Site
property Used with the ’query’ ’dm_attribute’ property=’a_category’

attribute. Specify any
Documentum attribute
that is valid for the object type
you are querying. If omitted,
WebPublisher Editor returns
the Documentum attribute
’object_name’ by default.
query Allows you to populate the Use the syntax query="dm_document

list using a query, rather than for DQL where folder(’/cabinet/
hard coding in the list. Specify (Documentum folder’)"
either this attribute or the Query
’values’ attribute. If both are Language), query=’dm_user’
specified, ’values’ is used and omitting
query="dm_user where
’query’ is ignored. everything
user_group_name=
before the
’administrator’" query=
FROM clause.
"custom_object_type
You can specify
where a_content_type
which property
like ’%ml’"
to return using
the ’property’ query="dm_
attribute. You dbo.product_table
can query any where prod_id =
type of object, 123454"
including
registered
tables.
readonly If set to Yes, the author is ’Y’ or ’N’ readonly=’Y’

not able to select any data in
this field. The field is grayed
out. If omitted, WebPublisher
TM
Creating a Web Site
required If set to Yes, the author is not ’Y’ or ’N’ required=’Y’

able to save until one of the
choices is selected. The field is
marked with a red star.
values Allows you to hard code in The values values="1,2,3,4,5"

a list of values from which should be
the author can select. Specify separated by values="Cinderella,
either this attribute or the commas (,). The Emperor’s New
’query’ attribute. If both are Clothes, Jack and the
specified, ’values’ is used and Beanstalk"
’query’ is ignored.
<graphic>
The <graphic> element displays either a list or a navigation tree that allows authors to
select graphics. You can specify a query to populate the list. WebPublisher displays a
scaled-down version of the graphic in the preview box, unless a thumbnail is available.
The <graphic> element is nested in the <tagcontent> or <tagattribute> element.
Figure 10–4. Graphic selector
TM
Creating a Web Site
Table 10–4. <graphic> Attributes
category determines what navigation ’root_category/ category=’Marketing/

path should be assigned to the subcategory’ Press Releases/Images’
imported file. The navigation
path is the series of categories
that the author clicks on to
find the file in the Edit Page
tab. These categories mirror
the folder structure below the
Content Templates folder in
the Configuration cabinet.
Normally, the navigation
path of a content file is the
same as the template from
which it was created; however
the imported graphic is not
created from a template and
therefore needs a navigation
path manually assigned.This
attribute is only applicable
if query_type=’query’ and
import=’Y’; it will be ignored
if query_type=’tree’. If
omitted, no navigational
path will be assigned, and
the imported file will not
be visible when the author
browses through the Edit Page
navigational structure
TM
Creating a Web Site

TM
Creating a Web Site

display.

formats Filters the files visible in ’dm_format’ formats=’jpeg,gif,my_

the tree to just the formats custom_gif’
you specify. This allows Specify as
you to show only graphic many as you
formats, reducing the would like,
potential for error. This separated by
attribute is only applicable if commas. Be
query_type=’tree’; it is ignored sure you use
if query_type=’query’. If the name of
omitted, WebPublisher Editor the format as
defaults to the formats gif and specified in
jpeg. Documentum
Administrator.
TM
Creating a Web Site
import Determines whether authors ’Y’ or ’N’ import=’N’

can import graphics from their
local systems. If import=’Y’,
you must set the attribute
’location’, which indicates
where the imported file is
stored. This location should
be included in the query
used to populate the list, or
else the next time the author
opens the file, the graphic
will not show up in the list.
You can also specify ’type’,
’lifecycle’, and ’category’
for the imported file. This
if query_type=’query’; it is
ignored if query_type=’tree’.
instruction Allows you to provide ’String’ instruction=’Select an

instructions on what to do image to be used as the
with this field; displays below header for the page.’
for instructions.
label Functions as a title for the ’String’ label=’Header image’

field; displays in bold. If
TM
Creating a Web Site
location If authors are allowed to ’/cabinet/ location=’/Website/

import graphics, determines folder’ gifs/marketing/
where in the Docbase the headers’
newly imported file should
be saved. Be sure that the
location you have specified is
included in the query used to
populate the list, or else the
next time the author opens the
file, the imported graphic will
not show up in the list. Also
be sure that the location exists
in the Docbase, or the Editor
will not open correctly.
This attribute is
only applicable if
query_type=’query’ and
import=’Y’; it is ignored if
query_type=’tree’. If omitted,
WebPublisher Editor silently
fails the import, since it has to
place to put the imported file.
TM
Creating a Web Site
lifecycle If authors are allowed to ’name of type=’WebPublisher

import graphics, determines lifecycle’ Default Lifecycle’
what lifecycle should be
assigned to the imported
file. Be sure that this lifecycle
is compatible with the
object type you assign
using the ’type’ attribute (or
dm_document, if you omit
the type attribute). This
import=’Y’; it is ignored
defaults to the default lifecycle
specified in your system
configuration. To check this,
in WebPublisher click the
Admin tab, and then follow
the "Edit global settings" in the
Application component; then
go to the Default Lifecycle
field.
TM
Creating a Web Site
output_format Determines whether the ’jpeg_lres’ or output_format=’jpeg_

published name of a secondary other custom lres’
rendition of the selected image Media Server
should be stored in the XML. format
This option requires that the
Media Server be enabled.
If output_format is specified,
then the Editor will look up
the publishing convention
for the specified format and
store that name in the XML.
For example, if the graphic
’graphic.gif’ is stored in a
folder called ’images’ in
the ’Website’ cabinet, and
output_property=’jpeg_lres’,
the following will be
stored in the XML:
/images/graphic_lres.jpg.
If omitted, the Editor stores
the name of the primary
rendition.
output_property Determines what aspect of the ’folderPath’ output_property=

selected graphic should be ’folderPath’
stored in the XML: its path or At this time, no
its ID (not yet implemented). other option Be sure to capitalize
has been correctly. XML is
If output_property= implemented. case-sensitive.
’folderPath’, the path to
the graphic will be stored in
the XML, minus the name of
the cabinet. You can specify
whether the path is absolute
or relative using the ’relative’
attribute. For example, if the
graphic ’graphic.jpg’ is stored
in a folder called ’images’
in the ’Website’ cabinet, the
following will be stored in
the XML if relative=’N’:
/images/graphic.jpg If
omitted, the Editor defaults to
’folderPath’
TM
Creating a Web Site
property Used with the ’query’ ’dm_attribute’ property=’title’

that is valid for the object
type you are querying. This
if query_type=’query’; it is
Editor returns the
query Generates a list of files from Use the syntax query="dm_document

which the author can select. for DQL where folder(’/cabinet/
(Documentum folder’) AND where
This attribute is Query a_content_type like
only applicable if Language), ’gif’"
query_type=’query’; it is omitting
ignored if query_type=’tree’. everything
If omitted, WebPublisher before the
Editor does not display any FROM clause.
files in the list. You can specify
which property
to return using
the ’property’
attribute. You
can query any
type of object,
including
registered
tables.
TM
Creating a Web Site
query_type Determines whether the ’query’ or ’tree’ query_type=’query’

graphics will be organized
in a list (populated by a
query) from which the
author can select, or as a tree
which the author can use
to navigate to the graphic
file. If query_type=’query’,
the following attributes will
not be applicable: ’roots’ and
’formats’. If query_type=’tree’,
not be applicable: ’rows’,
’query’, ’property’, and
’import’ (because ’import’ is
not applicable, these attributes
are not applicable either:
’location’, ’type’, ’lifecycle’,
and ’category’). If omitted,
to ’query’.

able select a graphic. The
field is grayed out. If omitted,
to ’N’.
TM
Creating a Web Site
relative Determines whether the path ’Y’ or ’N’ relative=’Y’

to the graphic should be
specified in absolute terms,
or relative to the content file
itself.
For example, suppose you

have the content file
/Cabinet/Press/2000/
release.xml
and while editing this file in

WebPublisher Editor the user
selects the graphic
/Cabinet/Images/
Corporate/image.gif
If relative=’No’, then this will

be stored in the XML:
/Images/Corporate/
image.gif.
If relative=’Yes’, then this will

../../Images/Corporate/
image.gif
This attribute is
only applicable if
output_property=’folderPath’.
TM
Creating a Web Site
roots Limits the portion of the ’/cabinet/ roots=’/Website/

Docbase that is visible to folder’ images,/Website/
the author in the tree. Only banner_gifs’
folders that are underneath the Specify as
cabinet or folder you specify many as you
as a root will be displayed. would like,
You can specify an unlimited separated by
number of roots. This commas.
attribute is only applicable if
query_type=’tree’; it will be
ignored if query_type=’query’.
Editor defaults the root to the
cabinet in which the content
file is located.
rows Allows you to control how ’#’ rows=’10’

many images are displayed
in the list without scrolling.
Anything below 8 will
be ignored, in order to
have enough room to
display the thumbnail. This
query_type=’query’; it will be
Editor defaults to ’5’.
type If authors are allowed to ’object_type’ type=’my_custom_

import graphics, determines type’
what object type should be Only specify
assigned to the imported dm_document
file. Be sure that this object or types
type is compatible with the descended
lifecycle you assign using from
the ’lifecycle’ attribute (or dm_document.
the lifecycle assigned by
default, if you omit the
lifecycle attribute). This
defaults to ’dm_document’.
TM
Creating a Web Site
<textselector>
The <textselector> element displays either a list or a navigation tree that allows authors
to select boilerplate text. You can specify a query to populate the list. The <textselector>
element is nested.
Figure 10–5. Text selector
TM
Creating a Web Site
Table 10–5. <textselector> Attributes
category If authors are allowed to ’root_category/ category=’Marketing/

import text fragments, subcategory’ Copyright/Stuff for
determines what navigation press releases’
path should be assigned to the
imported file. The navigation
path is the series of categories
that the author clicks on to
find the file in the EDIT PAGE
tab. These categories mirror
the folder structure below the
Content Templates folder in
the Configuration cabinet.
Normally, the navigation path
of a content file is the same
as the template from which
it was created; however the
imported text fragment is not
created from a template and
therefore needs a navigation
path manually assigned.
This attribute is
only applicable if
query_type=’query’ and
import=’Y’; it will be ignored if
query_type=’tree’. If omitted,
no navigational path will be
assigned, and the imported
file will not be visible when
the author browses through
the EDIT PAGE navigational
structure.
TM
Creating a Web Site

TM
Creating a Web Site

display.

formats Filters the files visible in ’dm_format’ formats=’crtext,jsp’

the tree to just the formats
you specify. This allows Specify as
you to show only text many as you
formats, reducing the would like,
potential for error. This separated by
attribute is only applicable if commas. Be
query_type=’tree’; it will be sure that you
ignored if query_type=’query’. use the name
If omitted, WebPublisher of the format
Editor defaults to the format as specified in
crtext. Documentum
Administrator.
TM
Creating a Web Site
import Determines whether authors ’Y’ or ’N’ import=’N’

can import text fragments
from their local systems.
If import=’Y’, you must
set the attribute ’location’,
which will indicate where
the imported file should be
stored. This location should
be included in the query used
to populate the list, or else the
next time the author opens
the file, the text fragment
will not show up in the list.
You can also specify ’type’,
’lifecycle’, and ’category’
for the imported file. This
instruction Allows you to provide ’String’ instruction=’Select a

instructions on what to do piece of boilerplate
with this field; displays below copyright text.’
several lines long.
instructions.
label Functions as a title for the ’String’ label=’Copyright’

field; displays in bold. If
TM
Creating a Web Site
location If authors are allowed to ’/cabinet/ location=’/Website/

import text fragments, folder’ includes/marketing’
determines where in the
Docbase the newly imported
file should be saved. Be sure
that the location you have
specified is included in the
query used to populate the list,
or else the next time the author
opens the file, the imported
text fragment will not show up
in the list. Also be sure that the
location exists in the Docbase,
or WebPublisher Editor will
not open correctly. This
will silently fail the import,
since it has to place to put the
imported file.
TM
Creating a Web Site
lifecycle If authors are allowed to ’name of type=’WebPublisher

import text fragments, lifecycle’ Default Lifecycle’
determines what lifecycle
should be assigned to the
imported file. Be sure that this
lifecycle is compatible with
the object type you assign
using the ’type’ attribute (or
dm_document, if you omit
the type attribute). This
defaults to the default lifecycle
specified in your system
configuration. To check this,
in WebPublisher click the
Admin tab, and then follow
the "Edit global settings" in the
Application component; then
go to the Default Lifecycle
field.
TM
Creating a Web Site
output_property Determines what aspect of the ’folderPath’, output_property=

selected text fragment should ’contents’, or ’folderPath’
be stored in the XML: its path, ’ID’
the actual contents of the file, Be sure to capitalize
or its ID. Releases before correctly. XML is
WebPublisher case-sensitive.
If output_property= 4.3 used
’folderPath’, the path to ’chronID’ or
the text fragment will be ’objectID’
stored in the XML, minus rather than
the name of the cabinet. You ’contents’.
can specify whether the path Both of these
is absolute or relative using attribute values
the ’relative’ attribute. For will still be
example, if the fragment honored for
’copyright.txt’ is stored in backwards
a folder called ’includes’ in compatibility.
the ’Website’ cabinet, the
following will be stored in
the XML if relative=’N’:
/includes/copyright.txt.
If output_property=’contents’,
the actual contents of the file
itself will be stored in the
XML. Note that this may cause
problems if the contents of
the file contain data that is
not well-formed XML, so be
sure to point to text fragments
that are safe. Please also note
ouput_property=’contents’
will only be honored if the
textselector element is within
a <tagcontent>, because it is
too problematic to put the
contents of a file within an
attribute.
If output_property=’ID’,
the Documentum ID of the
selected object will be stored in
the XML. ID is only supported
when query_type=query.
Editor defaults to ’folderPath’
in a <tagattribute> rule, and
defaults to ’contents’ in a
<tagcontent> rule.
TM
Creating a Web Site
preview_ Determines which attribute ’dm_attribute’ preview_property=’a_

property of the selected text fragment category’
is displayed in the right-hand
"preview" area, allowing
authors to verify that they
have selected the correct file.
Specify any non-repeating
Documentum attribute that
is valid for the object type
you are querying. This
attribute is only honored if
’show_content’ is set to ’N’.
This attribute is only honored

if ’show_content’ is set to ’N’.
to ’title’.
preview_rows Allows you to control the ’#’ preview_rows=’10’

height of the preview area.
The preview can be made to
show either the contents of the
file itself (show_content) or an
attribute of the selected file
(preview_property).
property Used with the ’query’ ’dm_attribute’ property=’title’

that is valid for the object
type you are querying. This
Editor will return the
TM
Creating a Web Site
query Generates a list of files from Use the syntax query="dm_document

which the author can select. for DQL where folder(’/cabinet/
(Documentum folder’) AND where
This attribute is Query a_content_type like
only applicable if Language), ’crtext’"
query_type=’query’; it will be omitting
ignored if query_type=’tree’. everything query="dm_
before the dbo.product_table
If omitted, WebPublisher where prod_id =
FROM clause.
Editor will not display any 123454"
You can specify
files in the list.
which property
to return using
the ’property’
attribute. You
can query any
type of object,
including
registered
tables.
query_type Determines whether the text ’query’ or ’tree’ query_type=’query’

fragments will be organized
in a list (populated by a
query) from which the
author can select, or as a
tree which the author can
use to navigate to the text
file. If query_type=’query’,
not be applicable: ’roots’ and
’formats’. If query_type=’tree’,
not be applicable: ’rows’,
’query’, ’property’, and
’import’ (because ’import’ is
not applicable, these attributes
are not applicable either:
’location’, ’type’, ’lifecycle’,
and ’category’).
Editor defaults to ’query’.
TM
Creating a Web Site

able select a text fragment.
The field is grayed out.
relative Determines whether the path ’Y’ or ’N’ relative=’Y’

to the text fragment should be
specified in absolute terms,
or relative to the content file
itself.
For example, suppose you

have the content file
/Cabinet/Press/2000/
release.xml
and while editing this file in

WebPublisher Editor the user
selects the graphic
/Cabinet/Includes/
Corporate/copyright.txt
If relative=’No’, then this will

/Includes/Corporate/
copyright.txt
If relative=’Yes’, then this will

../../Includes/Corporate/
copyright.txt
This attribute is
only applicable if
output_property=’folderPath’.
TM
Creating a Web Site
required If set to Yes, the author will not ’Y’ or ’N’ required=’Y’
be able to save until a text file
has been selected. The field is
marked with a red star.

to ’N’.
roots Limits the portion of the ’/cabinet/ roots=’/Website/

Docbase that is visible to folder’ boilerplate,/Intranet/
the author in the tree. Only includes’
folders that are underneath the Specify as
cabinet or folder you specify many as you
as a root will be displayed. would like,
You can specify an unlimited separated by
number of roots. This commas.
query_type=’tree’; it will be
ignored if query_type=’query’.
Editor defaults the root to the
cabinet in which the content
file is located.
rows Allows you to control ’#’ rows=’15’

how many text fragments
are displayed in the list
without scrolling. This
TM
Creating a Web Site
show_content Displays the contents of the ’Y’ or ’N’ show_content=’Y’

selected text fragment in the
right-hand "preview" area,
allowing authors to verify that
they have selected the correct
file. If set to ’Y’, then the
’preview_property’ attribute
will be ignored. If omitted,
to ’N’, which means that the
attribute of the selected file
will be displayed instead (if
preview_property is omitted,
it defaults to ’title’).
type If authors are allowed to ’object_type’ type=’my_custom_

import text fragments, type’
determines what object type Only specify
should be assigned to the dm_document
imported file. Be sure that or types
this object type is compatible descended
with the lifecycle you assign from
using the ’lifecycle’ attribute dm_document.
(or the lifecycle assigned
by default, if you omit the
lifecycle attribute). This
defaults to ’dm_document’.
<checkbox>
The <checkbox> element gives an author a choice. Clicking the checkbox chooses the
option it offers. The <checkbox> element is nested in the <tagcontent> or <tagattribute>
element.
Figure 10–6. Checkbox
TM
Creating a Web Site
Table 10–6. <checkbox> Attributes
checkbox_label The label for the checkbox ’String’ label=’Display the

itself. Displays to the right summary on the page’
of the checkbox. If omitted,
WebPublisher Editor will
display nothing.
checked The value that will be stored ’String’ checked=’user checked

in the XML if the checkbox box’
is checked. If omitted,
WebPublisher Editor will store
nothing.
instruction Allows you to provide ’String’ instruction=’Follow

instructions on what to do the instructions for the
with this field; displays below checkbox.’
several lines long.
instructions.
label Functions as a title for the ’String’ label=’Display

field; displays in bold. summary?’
normally reserved for the
label.

able to check or uncheck the
box. The field is grayed out. If
TM
Creating a Web Site
required Whenever the file is saved, ’Y’ or ’N’ required=’Y’

the strings specified in the
’checked’ and ’unchecked’
attributes will be stored
in the XML; in effect, it is
always required. If omitted,
to ’N’.
unchecked The value that will be stored ’String’ unchecked=’user did

in the XML if the checkbox not check box’
is not checked. If omitted,
WebPublisher Editor will store
nothing.
<tabledef> (Defining a Table)
The <tabledef> element defines a table with a fixed number of columns. The <tabledef>
element requires you to replicate the structure of an HTML table within your XML. Each
cells contains a WebPublisher Editor field, which means that after the table rule you enter
rules to associate each field with an element in the content file. The number of columns
is fixed, but authors can create, delete and move rows.
Figure 10–7. Table
TM
Creating a Web Site
Table 10–7. <tabledef> Attributes
caption The element that corresponds ’element_ caption=’faq_caption’

to the HTML <caption> name’
element. If no field is assigned
to this element, a textline
field is used. If omitted,
WebPublisher Editor tabledef
will not allow for the input of
a caption.
columns The number of columns in ’#’ columns=’2’

the table. Must correspond
to the number of <td>s you
have in each row. If omitted,
WebPublisher Editor will not
display the tabledef.
instruction Allows you to provide ’String’ instruction=’Please

instructions on what to do fill out each question
with this field; displays below and answer row; add
and in a smaller font than the as many rows as are
label. The instructions can be necessary for your
several lines long. If omitted, topic.’
for instructions.
label Functions as a title for the ’String’ label=’Frequently

field; displays in bold. If Asked Questions’
tag_name The element that corresponds ’element_ tag_name=’FAQ’

to the <table> element in an name’
HTML table. This element
must contain children which
correspond to the <tr> and
<td> structure of an HTML
table. If omitted, no fields will
display in a table.
TM
Creating a Web Site
td The element that corresponds ’element_ td=’faq_td’

to the HTML <td> element. name’
This element must contain
one child which is associated
with a field. If omitted,
to ’td’—that is, it looks for a
<td> element.
tr The element that corresponds ’element_ tr=’faq_tr’

to the HTML <tr> element. name’
This element must contain
children which correspond
to HTML <td> elements. If
defaults to ’tr’ -- that is, it
looks for a <tr> element.
<repeatdef> (Repeating a Field)
You can make a set of fields repeatable using the <repeatdef> element. After the
<repeatdef> rule, you define additional rules for each repeatable field. Authors
determine how many times the set of fields appears on the Web page. Repeatable fields
are used when it is up to the author to determine how often a certain type of information
appears. For example, on a page that lists Frequently Asked Questions, the number of
questions can vary.
When creating an Editor rules file for an HTML-based WebPublisher Editor template, do
not include the <repeatdef> element. WebPublisher will not recognize the <repeatdef>
element for an HTML-based content file.
Figure 10–8. Set of repeatable fields
TM
Creating a Web Site
Table 10–8. <repeatdef> Attributes
instruction Allows you to provide ’String’ instruction=’Please fill

instructions on what to do out each question and
with this field; displays below answer; add as many
and in a smaller font than the as necessary for your
label. The instructions can be topic.’
for instructions.
TM
Creating a Web Site
label Functions as a title for the ’String’ label=’Frequently

field; displays in bold. If Asked Questions’
tag_list Specifies the XML elements ’[XML tag_list=’FAQ’

to be repeated. The elements path]element_
in the list must be on the name’ tag_list=’/root/
same level of the XML tree, support/FAQ,/root/
and contiguous, i.e. in the Specify as support/reported_by’
following example: many elements
as you wish, as
<FAQ> long as they are
continguous
<question/> nodes and are
separated by
<answer/>
commas.
</FAQ>
<reported_by/>
<related_issue/>
correct: tag_list=
’FAQ,reported_by’
incorrect: tag_list=
’FAQ,answer’ (not on the
same level)
incorrect: tag_list=
’FAQ,related_issue’ (not
contiguous)
Any fields associated with the

elements in tag_list, as well as
any children of these elements,
will display as repeatable in
WebPublisher Editor. The
entire XML structure will be
repeated in the file as many
times as the user repeats.
If omitted, no fields will

display as repeating.
TM
Creating a Web Site
<xselector>
Currently, the <graphic> and <textselector> elements enable a user either to select from
the results of one pre-defined query or to navigate down a folder hierarchy from one
or more “root” folders. These elements also show the displayed graphic/text item plus
the list of available items. If the query returns many values, this can have performance
implications. The <xselector> element provides more extended functionality that is
useful when your users need the ability to sift through a large quantity of images or
other filetypes. To increase performance, when a content file is initially opened in
WebPublisher Editor, the xselector will only display the selected graphic/text item. The
user must click a button to open a file selection dialog box. In addition, the xselector
allows for the WebPublisher template developer to specify multiple queries from which
the user can select. The queries can either be full queries, which do not depend upon
values selected by the user, or the queries can include values from users. For example,
in the same xselector element, you could set up one query that would display all
images of a particular format, and another query that would display all images with a
particular language code. In the first query, the user could select different formats from
a criteria pulldown, so that the user could see all the jpeg images first, and then all of
the gif images. In the second query, the user could select different languages and then
run the query.
The <xselector> element also provides pagination. That is, it can display a maximum
number of query results at a time. This is useful when a query returns a large number
of items.
Note: Currently, the xselector does not support the selection of a file that is not within
the same delivery cabinet as the content file itself. If a file is selected that is not in the
same delivery cabinet, problems may occur such as: the next time the content file is
opened, the selected file may not appear to be selected, or the next time the content
file is opened, even if the file appears to be selected, the wrong data is stored in the
content file. Therefore, please be very careful to create filter queries that return files in
the same delivery cabinet.
TM
Creating a Web Site
Figure 10–9. xselector fields
Table 10–9. <xselector> Attributes
auto_exec_NAME_ Determines when ’Y’ or ’N’ auto_exec_NAME_

OF_FILTER the query will be OF_FILTER=’Y’
executed.
If auto_exec_NAME_
OF_FILTER=’Y’, the
query is executed
as soon as the user
selects the filter. If
’N’, the user must
press the Go button to
initiate the query.
If the corresponding
query_NAME_OF_
FILTER contains the
keyword {user.entry},
then this option will
be ignored, since the
query depends on
input from the user.
If omitted, the Editor

TM
Creating a Web Site
criteria_NAME_OF_ Generates a list of If the criteria are in criteria_NAME_OF_

FILTER criteria values from the form of a fixed list, FILTER=’en_US,fr_
which the user can the values should be FR,de_DE’
select. The selected separated by commas
value is inserted into (,). criteria_NAME_
the corresponding OF_FILTER="select
query at the required If the criteria are in object_name as
keyword {user.entry}. the form of a query, criterion_value, title
The criteria can either use standard DQL as criterion_name
be in the form of a syntax, with the ’as from wcm_locale
fixed list, or generated criterion_value’ and where folder(’/
via another query. ’as criterion_name’ in WebPublisher
the select clause. Configuration/
If you want to Locales’)"
generate the list
via a query, you criteria_NAME_OF_
must specify FILTER="select name
criteria_type_NAME_ as criterion_value
OF_FILTER=’query’. from dm_format
You must also use where name in (select
the special keywords a_content_type from
’as criterion_value’ dm_document) order
in the DQL query by description.
syntax. Optionally
you can also use the
special keywords ’as
criterion_name’. For
example, suppose
you specify the
following criteria:
’select object_name
as criterion_value,
title as criterion_name
from wcm_locale
where folder(’/
WebPublisher
Configuration/
Locales’)’. Then,
for each of the
locales returned,
the title value will
displayed in the
criteria pulldown
to the user, but the
object_name value
will be inserted
into the query at the
keyword {user.entry}.
So the user might
see ’English (US)’ in
the pulldown, but
’en_US’ would be
used in the query. TM
Creating a Web Site
criteria_type_NAME_ Allows you to ’Query’ criteria_type_NAME_

OF_FILTER specify whether the OF_FILTER=’query’
criteria values will
be generated via a
query. Used with
the attribute criteria_
NAME_OF_FILTER.

assumes the criteria
are in the form of a
fixed list.
If the corresponding
query_NAME_OF_
FILTER does not
contain the keyword
{user.entry}, then the
specified criteria
values will not
display.

does not display
any criteria in the
pulldown and the
query will not execute
properly if the
keyword {user.entry}
is present in the query.
description_NAME_ Allows you to provide ’String’ description_NAME_

OF_FILTER instructions on how OF_FILTER=’Select
to use the individual one of the formats and
filter; displays below click the Go button to
the filter pulldown. run the search.’

displays nothing.
TM
Creating a Web Site
drop_cabinet Determines whether ’Y’ or ’N’ drop_cabinet=’Y’

the path to the
selected file should
include the name of
the cabinet.
For example, suppose

that the user selects
the file /Cabinet/
Includes/Corporate/
copyright.txt If
drop_cabinet=’Y’,
then this will
be stored in the
XML: /Corporate/
copyright.txt If
drop_cabinet=’N’,
then this will
be stored in the
XML: /Cabinet/
Includes/Corporate/
copyright.txt.

defaults to ’Y’, since
it is rarely the case
that the cabinet
name is part of the
URL structure when
publishing via Web
Cache.
TM
Creating a Web Site
enable_locale_ Determines whether ’Y’ or ’N’ enable_locale_

fallback_NAME_ to further filter the fallback_NAME_
OF_FILTER list of selectable OF_FILTER=’Y’
files according to
language. This
option requires that
the WebPublisher
Globalization
functionality be
enabled.
If enable_locale_
fallback=’N’, all
matching files will be
displayed, regardless
of language. If ’Y’, the
Editor will determine
the language of
the content file
being edited, and
when displaying the
query results will
only display the
translation that is
being published to the
same language web
site as the content
file (according to
fallback rules). For
example, suppose you
have two graphics:
graphic1 has only an
English translation,
and graphic2 has
both an English and
German translation.
Suppose the user
is editing a English
content file. If enable_
locale_fallback=’N’,
then three files
will be displayed:
graphic1, graphic2
[English], graphic2
[German]--and the
user may be unable to
tell them apart.
TM
Creating a Web Site
enable_locale_ However, if enable_ ’Y’ or ’N’ enable_locale_

fallback_NAME_ locale_fallback=’Y’, fallback_NAME_
OF_FILTER then only graphic1 OF_FILTER=’Y’
and graphic2
[English] will display.
Now suppose the
user edits a German
content file. If enable_
locale_fallback=’Y’,
then graphic1 and
graphic2 [German]
will display as long
as German falls
back to English. If
German does not
fall back to English,
then only graphic2
[German] will
display.If omitted, the
WebPublisher Editor
defaults to enable_
locale_fallback=’N’.
filter_browser_title Allows you to provide ’String’ filter_browser_title=

instructions on the file ’Use the following
selection dialog box; filters to find the
displays below and in appropriate file. Press
a smaller font than the the Go button to
label. The instructions execute each search.’
long.
If omitted, the
WebPublisher Editor
displays nothing.
TM
Creating a Web Site
filters Allows you to specify The values should be filters=’F1,F2,F3’

one or more queries separated by commas
that the user can use to (,). label_F1=’’ label_
find the appropriate F2=’’ label_F3=’’
file. At least one filter query_F1=’’
is required. query_F2=’’ etc.
Each filter must

have a unique
name. This unique
name replaces the
NAME_OF_FILTER
string in the
following attributes:
label_NAME_OF_
FILTER, description_
NAME_OF_FILTER,
query_NAME_OF_
FILTER, property_
NAME_OF_FILTER,
autoexec_NAME_
OF_FILTER, criteria_
NAME_OF_FILTER,
criteria_type_NAME_
OF_FILTER, and
enable_locale_
fallback_NAME_
OF_FILTER. That
way, individual filters
can have their own
settings.
The filters will display

in the pulldown in
the order in which
they appear in the
comma-separated list.
If omitted, the user

will not see any
queries in the file
selection dialog box,
and thus will not be
able to select a file.
TM
Creating a Web Site
instruction Allows you to provide ’String’ instruction=’Select

instructions on what the Browse button
to do with this widget; to search for the
displays below and in appropriate file.’
a smaller font than the
label. The instructions
long.

will collapse the space
instructions.
label Functions as a title for ’String’ label=’Related file’

the widget; displays
in bold.

will collapse the space
the label.
label_NAME_OF_ The descriptive name ’String’ label_NAME_OF_

FILTER of the filter to be FILTER=’Images
displayed in the filter sorted by format’
pulldown.

uses the name of the
filter as specified in
the ’filters’ attribute.
TM
Creating a Web Site
output_format Determines whether ’jpeg_lres’ or other output_format=’jpeg_

the published name of custom Media Server lres’
a secondary rendition format
of the selected file
should be stored
in the XML. This
option requires that
the Media Server be
enabled.
If output_format
is specified, then
the Editor will look
up the publishing
convention for the
specified format
and store that name
in the XML. For
example, if the
graphic ’graphic.gif’
is stored in a folder
called ’images’ in the
’Website’ cabinet, and
output_property=
’jpeg_lres’, the
following will be
stored in the XML:
/images/graphic_
lres.jpg.
This option is
only available if
select_type=’graphic’.
It will be ignored if
select_type=’text’.

stores the name of the
primary rendition.
TM
Creating a Web Site
output_property Determines what ’folderPath’ output_property=

aspect of the selected ’folderPath’
file should be stored At this time, no
in the XML. other option has been Be sure to capitalize
implemented. correctly. XML is
If output_property= case-sensitive.
’folderPath’, the path
to the selected file
will be stored in the
XML. You can specify
whether the cabinet
name should be part
of the path using
the ’drop_cabinet’
attribute. You can
specify whether the
path is absolute or
relative using the
’relative’ attribute.
For example, if the
graphic ’graphic.jpg’
is stored in a folder
called ’images’ in
the ’Website’ cabinet,
the following will be
stored in the XML
if relative=’N’ and
if drop_cabinet=’Y’:
/images/graphic.jpg
If omitted, the
Editor defaults to
’folderPath’.
TM
Creating a Web Site
property Used to specify a ’dm_attribute’ property=’title’

default attribute
to be used with
individual ’query_
NAME_OF_FILTER’
attributes. This is
the attribute value
that will be shown
in the list control
box so that users can
identify files. It can
be overridden on
an individual query
basis by specifying
the appropriate
’property_NAME_
OF_FILTER’
attribute. Specify
any Documentum
attribute that is valid
for the object type you
are querying.
If omitted, the
Editor will return
the Documentum
attribute ’object_
name’ by default.
TM
Creating a Web Site
property_NAME_ Used with the ’dm_attribute’ property_NAME_

OF_FILTER corresponding OF_FILTER=’title’
’query_NAME_OF_
FILTER’ attribute.
This is the attribute
value that will
be shown in the
list control box
so that users can
identify files. Specify
any Documentum
attribute that is valid
for the object type you
are querying.
If omitted, the
attribute specified
in the ’property’
attribute will be
used (by default,
object_name).
TM
Creating a Web Site
query_NAME_OF_ Generates a list of Use the syntax for query_NAME_

FILTER files from which the DQL (Documentum OF_FILTER="dm_
author can select. Can Query Language), document where
be a static query, omitting everything folder(’/cabinet/
or dynamically before the FROM folder’) AND where
generated based clause. You can a_content_type like
on criteria values specify which ’crtext’”
specified by the user property to return
using the criteria_ using the ’property_ query_NAME_
NAME_OF_FILTER NAME_OF_FILTER’ OF_FILTER=
attribute. or ’property’ attribute. "dm_document
You can query where folder(’/
If omitted, the Editor any type of object, cabinet’,DESCEND)
will not display any including registered AND owner_name=
files in the list. tables. ’{object.owner_
name}’"
You can also use two
special keywords query_NAME_
in this query: OF_FILTER="dm_
{user.entry} - this is document where
the criterion value a_content_type=
specified by the ’{user.entry}’"
user to be inserted
query_NAME_
into the query
OF_FILTER=
{object.dm_attribute}
"dm_document
- this is the attribute
where folder(’/
value of the content
cabinet’,DESCEND)
file that is currently
AND any keywords
being edited, which is
like ’%{object.object_
then inserted into the
name}%’ AND
query
a_content_type=
’{user.entry}’"
readonly If set to Yes, the author ’Y’ or ’N’ readonly=’Y’

is not able select a text
fragment. The field is
grayed out.
If omitted,
WebPublisher Editor
TM
Creating a Web Site
relative Determines whether ’Y’ or ’N’ relative=’Y’

the path to the text
fragment should be
specified in absolute
terms, or relative to
the content file itself.
For example, suppose

you have the content
file
/Cabinet/Press/
2000/release.xml
and while editing this

file in WebPublisher
Editor the user selects
the graphic
/Cabinet/Includes/
Corporate/
copyright.txt
If relative=’No’, then
this will be stored in
the XML:
/Includes/
Corporate/
copyright.txt
If relative=’Yes’, then
this will be stored in
the XML:
../../Includes/
Corporate/
copyright.txt
This attribute is
only applicable if
output_property=
’folderPath’.
If omitted,
WebPublisher Editor
TM
Creating a Web Site
required If set to Yes, the author ’Y’ or ’N’ required=’Y’

will not be able to
save until a text file
has been selected. The
field is marked with a
red star.

rows Allows you to control ’#’ rows=’50’

how many files
are displayed per
"page" within the file
selection dialog box.

defaults to ’10’. Any
number below ’10’
will also be ignored.
select_type Determines what ’text’ or ’graphic’ select_type=’graphic’

kind of xselector is
created. If select_
type="graphic", then
a thumbnail of the
selected file will be
displayed. If the
user will be browsing
through any other
types of files, then use
select_type="text",
which just displays
the path of the
selected file.
If select_type=’text’,
the attribute
’output_format’ will
not be applicable.

defaults to ’text’.
<texttrigger>
The <texttrigger> element is a read-only element.
TM
Creating a Web Site
The <texttrigger> element uses the following:

• tag_name: A name and tag that determines where in the content file to store content
entered by the author in a field.
• attribute_name and attribute_value: These attributes force the texttrigger rule to
apply to the tag_name element that also provides the attr_name=attr_val
• label: The label to display in WebPublisher Editor.
XML Examples
The Editor rules file is an XML file or an HTML file with an XSL wrapper that defines
how the elements in the content template display in WebPublisher Editor. You can code
each piece of your WebPublisher Editor by modifying the Editor rules file using an
external editor or Documentum’s Rules Editor.
The following procedures explain the creation of an Editor rules file
(prod_detail_xml_rules.xml) using an external editor. Refer to Using WebPublisher Pro for
information about the Rules Editor. This Editor rules file is provided with the sample
Web site. Tags that are used in the prod_detail_xml_rules.xml file are tags that are most
common. A comprehensive list of the tags you can use in the Editor rules file appears in
the sections above.
To add start and end tags:

2. Type the following code.
The code of the Editor rules file must go between these start and end tags.
<rules>
</rules>
3. Choose File>Save As and save the document as prod_detail_xml_rules.xml in a

folder of your choosing.
To create a product name:

This section of the code enables you to create the name of the product.
1. Open the Editor rules file, prod_detail_xml_rules.xml in a text editor such as
Notepad.
2. Type the following code between the <rules> and </rules> tags.
<tagcontent tag_name=’TITLE’>
<textline
label=’Product Title’
instruction=’This must be typed exactly as it appears in the Product Title
attribute of this file.’
required=’N’
TM
Creating a Web Site
readonly=’N’
/>
</tagcontent>
Do not use the < or > symbols in your values attribute. The use of these symbols will
cause an error in your XML file.
This code should translate into the following widget in WebPublisher Editor.
To create a product number:

This section of the code enables you to create the number of the product.
Notepad.
2. Type the following code after the code for the product title.
<tagcontent tag_name="PRODUCTNUMBER">
<textline
label=’Product Number’
instruction=’This must be typed exactly as it appears in the Product Number
required=’N’
readonly=’N’
/>
</tagcontent>
To create a product price:

This section of the code enables you to create the price of the product.
Notepad.
2. Type the following code after the code for the product number.
<tagcontent tag_name=’PRICE’>
<textline
label=’Price’
instruction=’Enter the price in US dollars, like this: $###.##’
TM
Creating a Web Site
required=’N’
readonly=’N’
/>
</tagcontent>
To create a product image:

This section of the code enables you to add list of product images to the page.
1. Create a directory structure in a Docbase to store the image.
In this example, the image is stored in accelera.com/prod_detail/ph_images.
Notepad.
3. Type the following code after the code for product number.
<tagcontent tag_name=’GRAPHIC’>
<graphic
label=’Product image’
instruction="Select one of the available product images, or import your own.’
required=’N’
readonly=’N’
rows=’5’
query_type=’query’
query="dm_document where folder(’/accelera.com/prod_detail/ph_images’)"
property=’object_name’
output_property=’folderPath’
relative=’N’
import=’Y’
location=’/accelera.com/prod_detail/ph_images’
type=’dm_document’
/>
</tagcontent>
TM
Creating a Web Site
Note: Be sure to create a directory structure in a Docbase to store

your product images. In the example above, the images are stored in
/accelera.com/prod_detail/ph_images.
To create a text field for product description:

This section of the code enables you to create a window in which authors can enter
information about the product.
Notepad.
2. Type the following code after the code for product image.
<tagcontent tag_name=’DESCRIPTION’>
<content
label=’Description of the product’
instruction="Try not to duplicate information here and in the benefits.
Be sure to spell check!’
required=’N’
readonly=’N’
lines=’10
bold=’Y’
italic=’N’
color=’N’
spellcheck=’Y’
fontSize=’N’
indent=’Y’
orderedLists=’Y’
unorderedLists=’Y’
align=’N’
links=’N’
symbols=’Y’
/>
</tagcontent>
TM
Creating a Web Site
To create a product benefits section:

This section of the code enables you to create a series of product benefits.
Notepad.
2. Type the following code after the code for product description.
<tagcontent tag_name=’BENEFIT’>
<textline
label=’Benefit’
required=’N’
readonly=’N’
/>
</tagcontent>
<repeatdef
<tag_name="repeat"
label=’Benefits of the phone’
instruction=’Add each benefit individually. The recommended maximum
number is 10.’
tag_list=’BENEFIT’
</repeatdef>

Your final XML Editor rules file should look like the following.
<rules>
<tagcontent tag_name=’TITLE’>
<textline
label=’Product Title’
instruction=’This must be typed exactly as it appears in the Product Title
required=’N’
readonly=’N’
/>
</tagcontent>
<tagcontent tag_name="PRODUCTNUMBER">
<textline
label=’Product Number’
instruction=’This must be typed exactly as it appears in the Product Number
required=’N’
readonly=’N’
/>
</tagcontent>
<tagcontent tag_name=’PRICE’>
<textline
label=’Price’
instruction=’Enter the price in US dollars, like this: $###.##’
required=’N’
readonly=’N’
/>
</tagcontent>
<tagcontent tag_name=’GRAPHIC’>
TM
Creating a Web Site
<graphic
label=’Product image’
instruction="Select one of the available product images, or import your own.’
required=’N’
readonly=’N’
rows=’5’
query_type=’query’
query="dm_document where folder(’/accelera.com/prod_detail/ph_images’)"
property=’object_name’
output_property=’folderPath’
relative=’N’
import=’Y’
location=’/accelera.com/prod_detail/ph_images’
type=’dm_document’
/>
</tagcontent>
<tagcontent tag_name=’DESCRIPTION’>
<content
label=’Description of the product’
instruction="Try not to duplicate information here and in the benefits.
Be sure to spell check!’
required=’N’
readonly=’N’
lines=’10
bold=’Y’
italic=’N’
color=’N’
spellcheck=’Y’
fontSize=’N’
indent=’Y’
orderedLists=’Y’
unorderedLists=’Y’
align=’N’
links=’N’
symbols=’Y’
/>
</tagcontent>
<textline
label=’Benefit’
required=’N’
readonly=’N’
/>
</tagcontent>
TM
Creating a Web Site
<repeatdef
<tag_name="repeat"
instruction=’Add each benefit individually. The recommended maximum number is 10.’
</repeatdef>

</rules>
Once you have created the Editor rules file you must import it into WebPublisher.
The Content Template

The content template is an XML file or HTML file with XSL wrapper that contains the
elements in the content file. The elements and element attributes in the content template
point to descriptions in the Editor rules file. The content template also determines the
order in which elements display on the Web page. The order does not have to be the
same as in the Editor rules file.

The code of the content template must go between these start and end tags.
<?xml version="1.0" ?>
<PAGE>
<PRODUCT>
</PRODUCT>
TM
Creating a Web Site
</PAGE>
3. Choose File>Save As.

4. Save this document as prod_detail_external_app_###.xml.
To create a product title element:

This section of the code enables you to create a title for the product.
1. Open the content template, prod_detail_external_app_###.xml in a text editor such
as Notepad.
2. Type the following code between the PRODUCT tags.
<TITLE>
Name of the Phone
</TITLE>
To create a product number element:

This section of the code enables you to create a number for the product.
as Notepad.
2. Type the following code after the start tag.
<PRODUCTNUMBER>
Product Number for the phone
</PRODUCTNUMBER>
To create a product image element:

This section of the code enables you to create an image for the product.
as Notepad.
<GRAPHIC>
</GRAPHIC>
To create a product price element:

This section of the code enables you to create price for the product.
as Notepad.
<PRICE>
TM
Creating a Web Site
$199.00
</PRICE>
To create a product description element:

This section of the code enables you to create a description for the product.
as Notepad.
<DESCRIPTION>
Summary of the phone
</DESCRIPTION>
To create a product benefits element:

This section of the code enables you to create a list of benefits for the product.
as Notepad.
<DETAIL>
<BENEFIT>
A benefit of the phone
</BENEFIT>
<BENEFIT>
Another benefit
</BENEFIT>
<BENEFIT>
etc.
</BENEFIT>
</DETAIL>
To create a product type element:

This section of the code enables you state the type of product that your company is
offering.
as Notepad.
<PROD_TYPE>
phone
</PROD_TYPE>
TM
Creating a Web Site
The completed XML content template should look like the following
<?xml version="1.0" ?>
<PAGE>
<PRODUCT>
<TITLE>
Name of the Phone
</TITLE>
<PRODUCTNUMBER>
Product Number for the phone
</PRODUCTNUMBER>
<GRAPHIC>
</GRAPHIC>
<PRICE>
$199.00
</PRICE>
<DESCRIPTION>
Summary of the phone
</DESCRIPTION>
<DETAIL>
<BENEFIT>
A benefit of the phone
</BENEFIT>
<BENEFIT>
Another benefit
</BENEFIT>
<BENEFIT>
etc.
</BENEFIT>
</DETAIL>
<PROD_TYPE>
phone
</PROD_TYPE>
</PRODUCT>
</PAGE>
HTML Procedure
The HTML content template is more difficult than the XML content template. Below are
the guidelines to produce an HTML content template of the same information used in
the XML content template.
TM
Creating a Web Site

The code of the content template must go between these start and end tags.
<html>
</html>

4. Save this document as prod_detail_editor_###.html.
To create a product title element:

This section of the code enables you to create a title for the product.
1. Open the content template,prod_detail_editor_###.html in a text editor such as
Notepad.
2. Type the following code between the start and end tags.
<head>
<title>Accelera Communications Product List</title>
<link HREF="../style.css" TYPE="text/css" REL="stylesheet"/>
</head>
To create a product number, price, image, description, benefits and type element:
This section of the code enables you to create a number, price, image, description,
benefits list and type for the product.
as Notepad.
<TR>
<td width="88" valign="TOP"><img teComponentType="GRAPHIC"
src="" border="0" />
 

<WPEDITOR teComponentType="PRODUCTNUMBER">Product Number
for the phone</WPEDITOR>
 
<WPEDITOR teComponentType="PRICE">$199.00
</WPEDITOR>
 
<a href="#"><img src="../images/buy_btn.gif" border="0" height="13"
width="45"/></a>

TM
Creating a Web Site
</td>
<td valign="TOP" width="558">
<WPEDITOR teComponentType="TITLE">Name of the Phone
</WPEDITOR> 
<img src="../images/dots_300.gif" border="0" height="8" width=
"300"/> 
<WPEDITOR teComponentType="DESCRIPTION">
Summary of the phone
</WPEDITOR>
 
<WPEDITOR teComponentType="DETAIL">

<UL>
<LI>A benefit</LI>
<LI>Another benefit</LI>
<LI>etc.</LI>
</UL>

</WPEDITOR>
</td>
</TR>
The completed HTML content template should look like the following
<html>
<head>
<link HREF="../style.css" TYPE="text/css" REL="stylesheet"/>
</head>
<BODY LEFTMARGIN="0" TOPMARGIN="0" MARGINHEIGHT="0" MARGINWIDTH="0"

BGCOLOR="#FFFFFF">
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" HEIGHT="100%" WIDTH="100%" >


<TR>
<TD VALIGN="TOP" >

<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="20" WIDTH="99%">

<TR>
<td width="88" valign="TOP"><img teComponentType="GRAPHIC" src="
" border="0" />
 

TM
Creating a Web Site
<WPEDITOR teComponentType="PRODUCTNUMBER">Product Number

for the phone
</WPEDITOR>
 
<WPEDITOR teComponentType="PRICE">$199.00
</WPEDITOR>
 
<a href="#"><img src="../images/buy_btn.gif" border="0" height="13"
width="45"/></a>

</td>
<WPEDITOR teComponentType="TITLE">Name of the Phone
</WPEDITOR> 
<img src="../images/dots_300.gif" border="0" height="8" width="300"/> 
<WPEDITOR teComponentType="DESCRIPTION">
Summary of the phone
</WPEDITOR>
 
<WPEDITOR teComponentType="DETAIL">

<UL>
<LI>A benefit</LI>
<LI>Another benefit</LI>
<LI>etc.</LI>
</UL>

</WPEDITOR>
</td>
</TR>
</TABLE>
</TD>
</TR>
<TR>
<TD VALIGN="BOTTOM" >

</TD>
</TR>
</TABLE>
</BODY>
</html>
TM
Creating a Web Site
The Editor Presentation File

The Editor presentation file is an XSL stylesheet that defines how the page appears on the
final Web site each time a content file is checked in. The Editor presentation file merges
with the content object created from the content template through an XSLT (eXtensible
stylesheet language transformation) engine.
To add the starting tags:

The code of the Editor presentation file must go after the following starting tags.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="html" />
<xsl:strip-space elements="*"/>
<xsl:template match="*|@*|comment()|processing-instruction()|text()">
<xsl:copy>
<xsl:apply-templates select="*|@*|comment()|processing-instruction()|text()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="PAGE">
<xsl:text disable-output-escaping="yes">
<![CDATA[
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"

"http://www.w3.org/TR/REC-html40/loose.dtd">

4. Save this document as prod_detail_2_html.xsl.
To create your HTML:
1. Open the Editor presentation file, prod_detail_2_html.xsl in a text editor such

as Notepad.
2. Create code in the Editor presentation file, using Web-friendly code, to create your
Web page as you want it to look.
Here is an example of some HTML:
<html>
<head>
TM
Creating a Web Site
<link HREF="../style.css" TYPE="text/css" REL="stylesheet">

</head>

BGCOLOR="#FFFFFF">
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" HEIGHT="100%"

WIDTH="100%" >
<TR>
<TD VALIGN="TOP" >
]]>
</xsl:text>
<xsl:apply-templates select="PRODUCT" />
<![CDATA[
</TD>
</TR>
<TR>
</TD>
</TR>
</TABLE>
</BODY>
</html>
To build the XSL:

The XSL code combines with the content template to determine what to build on the
Web page. Place the list of elements, the image, product number, product title, product
dsescription, and product detail in this section. If you placed the HTML in the previous
procedure the elements would be hard coded not flexible.
as Notepad.
2. Type the following code to build the table area of your Web page.
The table is variable so you can add or remove rows.
<xsl:template match="PRODUCT">
<TABLE WIDTH="99%" CELLSPACING="20" CELLPADDING="0" BORDER="0">
TM
Creating a Web Site
<TR>
<xsl:apply-templates select="GRAPHIC"/>
 

<xsl:value-of select="PRODUCTNUMBER"/> 
<xsl:value-of select="PRICE"/> 
<a href="#"><img width="45" height="13" border="0"
src="../images/buy_btn.gif"/></a>

</td>
<td width="558" valign="TOP">
<xsl:value-of select="TITLE"/> 
<img width="300" height="8" border="0" src="../images/dots_300.gif"/> 
<xsl:apply-templates select="DESCRIPTION"/>
 
<xsl:apply-templates select="DETAIL"/>
</td>
</TR>
</TABLE>
</xsl:template>
3. Type the following code to build the image area of your Web page.
The image is variable enabling it to change to match the content file.
<xsl:template match="GRAPHIC">
<xsl:if test=’string()’>
<img border="0" src="{.}"/>
</xsl:if>
</xsl:template>
4. Type the following code to build the description area of your Web page.
The product description is a variable because it is a link to changing information to
match the content file.
<xsl:template match="DESCRIPTION">
<xsl:apply-templates/>
</xsl:template>
5. Type the following code to build the detail area of your Web page.
The product detail is variable because it is repeating information to match the
content file.
<xsl:template match="DETAIL">
<ul>
<xsl:apply-templates />
</ul>
</xsl:template>
TM
Creating a Web Site
6. Type the following code to build the benefiit areas of your Web page.
The product benefits are variable because they change to match the content file.
<xsl:template match="BENEFIT">
<li>
</li>
</xsl:template>
To add the end tag:

as Notepad.
2. Type the following code at the end of the file.
</xsl:stylesheet>
The final Editor presentation should look something like the following. The HTML
section will match your HTML code.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="html" />
<xsl:template match="*|@*|comment()|processing-instruction()|text()">
<xsl:copy>
<xsl:apply-templates select="*|@*|comment()|processing-instruction()|text()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="PAGE">
<![CDATA[
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"

"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<link HREF="../style.css" TYPE="text/css" REL="stylesheet">
</head>
TM
Creating a Web Site

BGCOLOR="#FFFFFF">
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" HEIGHT="100%"

WIDTH="100%" >
<TR>
<TD VALIGN="TOP" >
]]>
</xsl:text>
<xsl:apply-templates select="PRODUCT" />
<![CDATA[
</TD>
</TR>
<TR>
</TD>
</TR>
</TABLE>
</BODY>
</html>
]]>
</xsl:text>
</xsl:template>
<xsl:template match="PRODUCT">
<TABLE WIDTH="99%" CELLSPACING="20" CELLPADDING="0" BORDER="0">
<TR>
<xsl:apply-templates select="GRAPHIC"/>
 

<xsl:value-of select="PRODUCTNUMBER"/> 
<xsl:value-of select="PRICE"/> 
<a href="#"><img width="45" height="13" border="0"
TM
Creating a Web Site
src="../images/buy_btn.gif"/></a>

</td>
<td width="558" valign="TOP">
<xsl:value-of select="TITLE"/> 
<img width="300" height="8" border="0" src="../images/dots_300.gif"/> 
<xsl:apply-templates select="DESCRIPTION"/>
 
<xsl:apply-templates select="DETAIL"/>
</td>
</TR>
</TABLE>
</xsl:template>
<xsl:template match="GRAPHIC">
<xsl:if test=’string()’>
<img border="0" src="{.}"/>
</xsl:if>
</xsl:template>
<xsl:template match="DESCRIPTION">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="DETAIL">
<ul>
</ul>
</xsl:template>
<xsl:template match="BENEFIT">
<li>
</li>
</xsl:template>
</xsl:stylesheet>
Once you have created the Editor presentation file you must import it into WebPublisher.
Refer to Using WebPublisherPro for more information on the Editor presentation file.
The Thumbnail File

The thumbnail file is a graphic file representing what the Editor presentation template
looks like. This file is a GIF or JPG file that is typically a miniature screen shot of the
TM
Creating a Web Site
template or another type of identifying icon. Thumbnails should be no more than 100 x
100 pixels.
To create the thumbnail file:
1. Open a graphics program such as a Paint Shop Pro.

You want to create a GIF or JPG.
2. Paste a screen shot of the Editor presentation file.
3. Save the screen shot as a GIF or JPG.
5. Save this document as ProductThumbnail.gif or jpg.
Once you have created the thumbnail file you must import it into WebPublisher. Refer to
Using WebPublisherPro for more information on the thumbnail file.
Verifying WebPublisher Editor Templates

To enable authors to create content using the templates you must import the templates
and files into the WebPublisher Docbase. Before you make the templates available to
users, test them.
You test templates by importing them into a Docbase in WebPublisher, associating them
together, adding new content to them, and publishing them to a Web site. You can import
your templates by using the IMPORT command in WebPublisher. If you want to deploy
your templates to various Docbases you should include them in your custom DocApp.
Importing Templates and Files

In each of the creation steps in the WebPublisher Editor and Templates section you were
asked to import the templates and files into WebPublisher. Be sure that each template
and file was imported into the proper location as outlined below.
• Editor Rules file location = WebPublisher/Configuration/Supporting
Templates/Editor
• Content template location = WebPublisher/Configuration/Content
Templates/<folder to which you want your the new template file to belong>.
• Editor Presentation file location = WebPublisher/Configuration/Supporting
Templates/Editor
• Thumbnail file location = WebPublisher/Configuration/Supporting
Templates/Thumbnails
Imported files created using an external editor can be modified using Documentum’s
Rules Editor. Choosing Checkout and Edit in WebPublisher Pro invokes the Rules Editor.
TM
Creating a Web Site
The Rules Editor performs some checking on the XML file to determine if the file is
created with well-formed XML If the file is well-formed then it opens in the Rules Editor.
If the file is not well-formed then a message opens telling you where the first error occurs.
The Rules Editor checks for errors and displays them one-by-one until all the errors are
fixed. Once the file is well-formed it the Rules Editor opens it for modification. Refer to
Using WebPublisherPro for more information on the importing the Editor rules file.
You can import the templates and files individually or you can import them into your
custom DocApp. If you import them into a custom DocApp you must then create a
DocApp archive to deploy the DocApp to each Docbase. Refer to Example DocApp
Customization, Chapter 2, Customization Overview, and Using WebPublisher Pro for more
information on importing templates and files, and packaging and deploying a DocApp
Validating Templates
Once you have imported the templates and files into a Docbase you must validate them
to ensure they are created correctly. Refer to Using WebPublisher Pro for more information
on validating templates.
Associating Templates
Once you have imported the templates and files into a Docbase you must associate the
content template with the supporting Editor rules, Editor presentation, and optional
thumbnail file so they will work together when you add new content. Refer to the Using
WebPublisher Pro for more information on associating templates.
Adding New Content

Once you have associated the templates authors can create new documents based on the
templates. Authors do this by adding new content, and choosing an associated template
file. Refer to Using WebPublisher Pro for more information on adding content.
Promoting Content
Once authors have added new content they can promote the content from WIP to Staging
so you can publish to a standard WIP Web site. Refer to the Using WebPublisher Pro for
more information on promoting content.
TM
Creating a Web Site
Publishing to a Private Web Site

Once content is promoted you can publish the contents to a standard WIP Web site to see
the end result. Refer to Using WebPublisher Pro for more information on publishing.
One example of an Accelera product page should look similar to the following.
Figure 10–10. Accelera Product Page
Example DocApp Customization

To copy custom WebPublisher applications easily from one Docbase to another you
should create a custom DocApp.
The Accelera sample Web site is available for installation through a custom
DocApp. The Accelera DocApp is available from Documentum’s FTP site in
.../Product-WebPublisher/English/<platform>/<database>/Current_Version-4.3
business or department.
The Accelera DocApp should already be installed to your test WebPublisher Docbase,
and should include the following objects:
• object_type
— ar_prod
— ar_press
TM
Creating a Web Site
• procedure
— PreConfigureSampleWebSite
— PostConfigureSampleWebSite
• DataObject
— Accelera.com
— English (US) active
• Templates
Each template has different formats to illustrate the variety of options users have
when developing templates.
— press release template
Formats include XML/HTML, Word/HTML
— product template
Formats include XML/XSL, XML/HTML, HTML/HTML, Word/HTML
Note: Developing DocApps contains all the information you need to create a custom
DocApp. Follow the DocApp tutorial to begin your DocApp creation.
WebPublisher lifecycles and workflows contain states and tasks that are specific to
WebPublisher so you need to use the information in Chapter 9, Creating Process Workflows
and Lifecycles to create WebPublisher specific-lifecycles and workflows. Then package
and deploy the DocApp.
Below is a quick outline of where to find information.
Note: If you are creating a custom object type and attributes in the same Docbase in
which you intend to use them you do not need to create a DocApp. You only need to
create a DocApp if you want to copy the DocApp attributes from one Docbase to another.
• Creating a DocApp: Developing DocApps
• Describing the Documentum Developer Studio (DDS) interface: Developing DocApps
• Describing a custom DocApp: Developing DocApps
• Creating object types: Developing DocApps
• Creating alias sets and permission set templates: Developing DocApps
• Creating WebPublisher process workflows and lifecycles: Customizing Documentum
WebPublisher
• Testing your DocApp: Customizing Documentum WebPublisher
TM
Creating a Web Site
Testing your DocApp, Lifecycle, and Workflow

After you have created a custom DocApp, templates, lifecycle, and workflow in DDS,
you should install the DocApp archive to your WebPublisher Docbase, create content,
and test your lifecycle and workflow.
Once you install the DocApp archive in your WebPublisher Docbase, you must log in to
WebPublisher as an administrator or Web developer and add the workflow. Refer to the
Using WebPublisher Pro for step-by-step instructions on how to add a workflow.
You package a DocApp into an archive that you can deploy to other Docbases.
If you are reusing the DocApp and deploying it to another Docbase that services a
different set of users in your company, permission sets are of great value.
When you install the DocApp archive into a Docbase, you are prompted to provide
values (user names, groups, cabinets, or directories) for the aliases in your DocApp.
Use DDS to package your DocApp into an archive. Use DocApp Installer to install the
DocApp archive into the Docbase.
Note: When the instructions do not ask you to specify a value for a field or to select an
option, accept the default.
To package Accelera into an archive:
1. In DDS, choose DocApp>Create DocApp Archive.

The Choose Directory dialog box opens.
2. Navigate to the directory in which you want to create the Accelera archive.
You do not need to create an Accelera directory. DDS automatically creates a
directory with the same name as your DocApp and places the archive files in it.
To install the Accelera archive into a Docbase:
1. Choose Start>Programs>Documentum>DocApp Installer.

The Select DocApp Archive dialog box opens.
2. Connect to the Docbase by typing your user name and password when prompted,
and click OK.
3. Click Browse to find the Accelera archive folder.
4. Select the Accelera archive folder, and click OK.
5. Click OK in the Select DocApp Archive dialog box.
You return to the main window.
6. Click Start Installation.
TM
Creating a Web Site
7. If a message appears stating that there are connected users, click Yes to continue.
The Resolve Alias dialog box opens.
8. If you have not created the corresponding users, groups, and folders in the Docbase,
create them.
a. Use DDS to create the folders shown in the Group and Folder Alias table.
b. Use Documentum Administrator to create the users and groups shown in the
Docbase.
9. In the Resolve Alias dialog box, select the alias or folder in the Docbase as shown in
Group and Folder Alias table.
a. To find the appropriate folder, click the browse button, select the folder. Do not
double-click it to open it. Click Select.
b. Select the corresponding user or group from the drop-down list
10. Click OK.
After you have resolved all the aliases, the DocApp Installer installs the Accelera
DocApp archive. Any errors that occur are displayed in the Installation Status
window. Refer to the following section, Troubleshooting Your DocApp Installation
for information on DocApp installation errors.
The following table lists and describes the folders and users for the aliases in your
DocApp.
Table 10–10. Group and Folder Aliases
Name Description
Creators A group for authors of sales_info documents.
Reviewers A group for reviewers of sales_info documents.
Content Managers A group for content managers.
Authoring Location docbase_cabinet\ProductBase\Authoring
Review Location docbase_cabinet\ProductBase\Review
Approved Location docbase_cabinet\ProductBase\Approved
Published Location docbase_cabinet\ProductBase\Published
Expired Location docbase_cabinet\ProductBase\Expired
Suspended Location docbase_cabinet\ProductBase\Suspended
Note: docbase_cabinet is the cabinet that has the same name as your Docbase.
Troubleshooting Your DocApp Installation
TM
Creating a Web Site
Summary
You have created a portable DocApp that includes:

• new types
• aliases
• alias sets
• permission set templates
• a lifecycle
• a workflow
• a customized attribute component.
Updating the XSL File for Previewing Documents

Created from XML Templates
On the sample WebPublisher Web site, if you want to preview HTML renditions of a
documents created from XML templates, you must update the XSL file.
To update the XSL file:
1. Replace the second line, which reads
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/
Transform" version="1.0">
With the following three lines
<xsl:transform xmlns:xsl="http://www.w3.org/XSL/Transform/1.0">
<xsl:output method="html" indent="yes"/>
2. Replace the last line, which reads

</xsl:stylesheet>
With the following line:
</xsl:transform>
TM
Appendix A
Troubleshooting
This troubleshooting chapter provides you with information about common RightSite
and WebPublisher problems. Please read this section before you contact Documentum’s
Technical Support team. You may find the answers you need.
This chapter discusses the following topics:
• Working Around Memory Caching Issues
• Locating Docbasic Errors by Line Number
Working Around Memory Caching Issues

By default, RightSite compiles and caches Docbasic script files in WebPublisher
directories the first time it encounters an uncompiled script. These cached files
are placed in .ebc files under the RightSite\product\cache\fs\wcm\product and
RightSite\product\cache\fs\wcm\custom\default folders.
By default RightSite caches about 100K of these script files into memory. This means that
if you edit a script file RightSite does not compile and read your newest changes into
memory until you restart RightSite. To avoid this situation you need to:
• Use the RightSite Administrator to set the RightSite environment variable
DMW_MAX_CACHE_SIZE to 1. This forces RightSite to always read the compiled
Docbasic cached files from disk instead of caching them in memory.
• When you modify a script file, find the corresponding .ebc file in the
RightSite\product\cache\fs\wcm\custom\default folder hierarchy and delete it.
The next time you try to access the feature you are customizing, RightSite realizes
that the compiled .ebc file no longer exists and compiles your modified .ebs file and
reads it into memory to execute.
Additionally, WebPublisher caches the contents of the start.htm and .xml configuration
files to improve performance. For example, if you add an attribute to an XML file, you
will not see the result until you restart the browser. To avoid this caching, use the
RightSite administrator to set a new environment variable DMW_SSI_CACHE_PAGE
to FALSE.
TM
Customizing Documentum WebPublisher A–1
Troubleshooting
For optimal performance you should not have these variable settings for your production
site.
Locating Docbasic Errors by Line Number

Occasionally in WebPublisher you will encounter a Docbasic error when testing a new or
customized Docbasic script. There are two ways in which you can execute a Docbasic
script in a form: the script can be an external .ebs file and be called from an HTML form
or it can occur in-line within the HTML form. Locating the error is slightly different
depending on how the script is executed.
When Your Form Calls an External .ebs File

When RightSite compiles a new Docbasic script that is external to the HTML form and
encounters a Docbasic error, RightSite returns an error window which gives you the
name of the .ebs file and the line number where RightSite thinks the error occurred
within that file. Usually, the line number is the exact line where the error is generated,
but occasionally you have to check the lines immediately surrounding the line number
RightSite provides (usually above) to locate the exact cause of the error.
When Your Docbasic Script Is In-line

When RightSite finds an error within a Docbasic routine that is embedded into an HTML
form, it also returns an error that includes a file name. The file name will be the name
of the .htm form in which the script is located. RightSite also lists two line numbers.
The first line number is the location of the DMW_EXEC WebQL tag that introduces
the Docbasic script within the HTML form. This line number counts from the top of
the HTML form. The second line number an offset telling you exactly where the error
occurred within the function itself. To use this number, count downwards from the
subfunction call, just below where all the arguments are defined.
As when working with any Docbasic script, the line number will usually be the exact line
where the error is generated, but sometimes you will have to check the lines immediately
surrounding the line number RightSite provides (usually just above) to locate the exact
cause of the error.
TM
A–2 Customizing Documentum WebPublisher
Glossary
action list
A list of operations that users can perform on selected documents. The action list displays on the
right hand side of the WebPublisher window.
Active
In a default configuration the lifecycle status (state) of a file that is in use on one or more live
Web site(s).
administrator
The WebPublisher user or user group responsible for installing, customizing, and configuring
WebPublisher to meet specific organizational requirements. An administrator will use other
Documentum products to customize and configure WebPublisher.
alias set
An alias set contains one or more alias names that can be used as placeholders for certain objects
in a Documentum Docbase. Web developers and administrators can create alias sets.
Approved
In a default configuration, the lifecycle status (state) of a file that is ready for publication but is
awaiting its effective date.
The file becomes active when the effective date occurs or when an approved page is manually
promoted.
attribute
Information, or metadata, that is associated with an object. Attributes are also called properties. A
Docbase object can have many different properties associated with it. Each property can take on
multiple values. For example the property of format could take on the value of .htm, .doc, .xsl.
TM
Customizing Documentum WebPublisher GL–1
Glossary
authoring interface
WebPublisher provides two interfaces: the authoring interface and the WebPublisher Pro interface.
The authoring interface allows non-technical users (content authors and content managers) to
create content for Web sites without having to understand the mechanics of Web page creation.
automatic task
A task that promotes a file without a user intervention. For example, a workflow might contain an
automatic task that promotes files to the Staging lifecycle status (state).
change set
A group of content files that travel together through workflows and share the same lifecycle. If a
change set effective date is set, all files in the change set publish to the active Web site at the same
time. Web developers and administrators can create change sets.
choice
An element describing the selection list editor component.
content
Any information, such as text, graphics, or charts, published to a Web page.
content author
A WebPublisher user or user group who creates content for Web sites without getting involved in
the technical details of the Web site creation or maintenance.
content manager
A WebPublisher user or user group who assigns content to be written by a content author, and
makes sure content adheres to organizational practices.
delivery cabinet
A cabinet in the WebPublisher Docbase that contains the files belonging to a particular Web site.
Delivery cabinets are visible only to Web developers and administrators.
descriptive name
A name used to identify a file in WebPublisher. It is not limited to the naming conventions used on
the Web and gives you more latitude to describe a file. The descriptive name is optional. If a file
has no descriptive name, WebPublisher identifies the file by the file name. When WebPublisher
lists files, the file name is the primary identifier, and the descriptive name appears underneath.
dispatcher
A WebPublisher component that controls the overall operation of WebPublisher on the Web
server. It calls various features and forms to display a list or page, or perform an action.
DocApp
A DocApp is a Documentum application that encapsulates customized Docbase objects. DocApps
usually contain, object types, properties, lifecycles, workflows, alias sets, and WebPublisher
Editor templates.
TM
GL–2 Customizing Documentum WebPublisher
Glossary
DocApp archive
A portable representation of a DocApp in a file on the file system.
Docbase
An object repository. Docbases store Web pages and other objects that you use to create Web sites.
Docbasic
An easy-to-use programming language provided by Documentum. You can write Docbasic
procedures to interact directly with a Documentum server. You write Docbasic procedures using
the Docbasic Editor, which comes with Documentum Developer Studio.
edition
A snapshot of a Web site at a specific point in time. Administrators can create editions.
Editor presentation file

A template that controls the final look and feel of the content on the Web site.
Editor rules file

The file that controls the items on the WebPublisher Editor form used to create content.
effective date
The date a file is to be published to a Web site.
expiration date
The date a file is to be removed from a Web site.
Expired
In a default configuration, the lifecycle status (state) of a file that has been removed from a
Web site.
feature
An action or link in WebPublisher.
file format
The type of file, often indicated in the file name.
file name
The name that identifies a file on the Web. The file name must follow naming conventions used
for Web documents. For example, Web documents cannot have spaces or symbols.
FTP
File Transfer Protocol. The protocol used on the Internet for sending files.
ftpIntegrator
A Documentum application that provides direct integration between the WebPublisher Docbase
and any Web-authoring tool that supports FTP (File Transfer Protocol) over a TCP/IP network.
ftpIntegrator allows you to use client applications, such as Macromedia Dreamweaver, HomeSite
and GoLive, to securely transfer files of any format to and from the Docbase through FTP.
TM
Glossary
Administrators can configure ftpIntegrator to automatically assign properties to files during

import. ftpIntegrator can communicate with several clients and several repositories at once.
group
A set of users. The users in a group can be individual users, groups of users or a combination
of both. WebPublisher has four default user groups: administrators, Web developers, content
authors, content managers.
history mechanism
A WebPublisher component that returns users to a logical place in the WebPublisher user interface
upon completion of an operation such as saving a file.
HTML
HyperText Markup Language. HTML is a collection of platform-independent styles (indicated by
markup tags) that define the various components of a Web document.
HTTP
HyperText Transfer Protocol. HTTP is a generic stateless object-oriented protocol, that can be
used for similar tasks such as name servers, and distributed object-oriented systems, by extending
the commands, or "methods", used.
keyword
A property of a content object that can be used to locate the content object in a search.
lifecycle
The different states a file goes through on its way to publication to a Web site. A file’s current
lifecycle state determines how the file is used and who has access to it.
list item
A property, such as a subject, author, or date, displayed under your specified document type in
the FILE LIST page
lock
A lock ensures that only one person at a time is able to edit a file. When you edit a file, the file is
locked in the WebPublisher Docbase so that no one else can edit it. When a file is locked, other
users can view the last version saved to the Docbase.
navigation path
The hierarchy of categories through which a file or page type is accessed in the WebPublisher
object
An entity in a Documentum Docbase. In Documentum, all items such as documents, folders,
cabinets, and even users are objects. All objects have associated descriptive characteristics, called
properties, and associated operations, called methods
TM
Glossary
object type
A template for objects (usually documents) that play a special role in a DocApp. An object
type inherits properties from its supertype (usually dm_document or one of its subtypes). The
additions or modifications you make to these properties define the object type. You create object
types using Documentum Developer Studio.
page type
A template for creating new content files. In the WebPublisher authoring interface, templates
are called page types.
permission set
A permission set controls the ways in which specified users can interact with an object in a
Docbase. You can attach a permission set to an object to specify permissions for the object owner,
generic users (the world), and any other users or groups
process workflow
The standard way of routing Web page content to other users. The process workflow is integrated
with the lifecycle so that Web page content can be automatically when approved by a reviewer.
property
Information, or metadata, that is associated with a object. A Docbase object can have many
different properties associated with it. Each property can take on multiple values. For example the
property of format could take on the value of .htm, .doc, .xsl.
publish
Moving content to the active Web site; refers to the automatic jobs that WebCache runs to push
files out to the Web server.
rendition
A copy of a file that differs from the original only in the format of the content.
repeatdef
A repeating editor element.
Rules Editor
A GUI application enabling users to create or modify an Editor rules file and template file through
a user-friendly interface. The Editor rules file creates or modifies the WebPublisher Editor
interface.You access the Rules Editor from WebPublisher Pro.
Staging
In a default configuration, the lifecycle status (state) of a completed file waiting to receive final
approval for publishing.
synchronize
A WebPublisher feature that enables you to manually update the files on the Web server.
tabledef
A table editor element.
TM
Glossary
template
The files upon which new content files are based. When an author chooses a template,
WebPublisher makes a copy of the template and saves it as a new content file. The content file
inherits the template’s content and properties. WebPublisher chooses where to store the file in
the Docbase by applying a set of mapping rules to the content file’s properties. The rules are
contained in the FolderMap.xml file.
In the authoring interface, templates are called page types.
textline
A single-line text element.
textselector
An element describing the boilerplate text selector editor template.
texttrigger
A Read-Only element such as label.
thumbnail
A file that is a visual representation of a file or template, to make it easier for users to recognize
the file.
URL
Uniform Resource Locator, the global address of documents and other resources on the World
Wide Web. The first part of the address indicates what protocol to use, and the second part
specifies the IP address or the domain name where the resource is located.
validate
A WebPublisher feature that checks to see that template files are well-formed XML files.
version
An instance of a file as it was saved to the Docbase. When you save a file to the WebPublisher
Docbase, WebPublisher saves it as a new version with an incremental number. WebPublisher
keeps the previous versions of the file, as well.
Web developer
The WebPublisher user responsible for creating and managing Web page templates and Web sites.
Web page
A document formatted in HTML and viewable on the World Wide Web portion of the Internet.
Web ready
A content file that Web browsers can read.
Web server
An HTTP server that gives access to a Web site.
TM
Glossary
Web view
A WebPublisher feature that allows you to preview what content will look like when it people
view it on the Web site.
WebPublisher Docbase
See Docbase.
WebPublisher Editor
A browser-based application for creating and modifying Web page content.
widget
An item in a WebPublisher Editor file—such as a textbox, checkbox, or table—that authors
use to create content.
WIP
Work In Progress. In a default configuration, the lifecycle status (state) of a file that is not yet
complete and not yet ready for publishing. Anytime a file is versioned or demoted, its lifecycle
starts over at the WIP state.
workflow
A predefined sequence of tasks users perform to process files. WebPublisher administrators
create and define workflows. When users are to perform a task, they are notified in their email
inbox and their WebPublisher task list.
workflow supervisor
The user who is responsible for a workflow in progress and who has permission to modify or
stop it.
XML
Extensible Markup Language. XML is the universal format for structured documents and data on
the Web, and is a method for putting structured data in a text file.
Xselector
An element that extends the functionality of the graphic selector and text selector.
XSL
Extensible Stylesheet Language. An XSL stylesheet specifies the presentation of a class of XML
documents by describing how an instance of the class is transformed into an XML document
that uses the formatting vocabulary.
XSLT
Extensible Style Language Transformation, the language used in XSL stylesheets to transform
XML documents into other XML documents.
XSLT is used when creating WebPublisher Editor files.
TM
Glossary
TM
Index
A example
action list HTML product title, 10–75
new action, 8–6 HTML start and end tags, 10–75
actionlist product benefits, 10–73
adding features, 8–4 product description, 10–73
alias set product image, 10–72
definition, 2–3, 2–9 product number, 10–72, 10–75
attribute, 4–1 product price, 10–72
See also property product title, 10–72
adding, 4–7 product type, 10–73
adding or removing, 4–19 start and end tags, 10–71
attributes.xml file, 4–4 create page
copying, 4–4 customizing, 7–5
definition, 2–2, 2–8 page, 7–1
deleting, 4–6 tab, 7–5
displaying, 4–17 customization, 2–13
displaying and hiding, 4–16 dispatcher, 2–20
hiding, 4–16 features, 2–14
list item, 5–3, 5–6 history mechanism, 2–18
Read-Only, 4–18 methodology, 2–13
script, 4–14 object types, 2–14
value assistance, 4–9 testing, 4–20, 7–5, 7–8
value selection, 4–9
D
C dctmEditor, 10–14
checkbox, 10–41 directory
choice element, 10–15 custom, 2–31
content product, 2–31
adding new, 10–85 dispatcher
promoting, 10–85 customization, 2–20
publishing, 10–86 definition, 2–28
content element, 10–6 environment variables, 2–20 to 2–21
content template examples
definition, 10–71 URL and DMW_INCLUDE, 2–26
global variables, 2–20, 2–23
RightSite methods, 2–20
understanding, 2–30
TM
Customizing Documentum WebPublisher Index–1
Index
URLs, 2–20 to 2–21, 2–28 components, 2–31

using variables, 2–26 confirmation pages, 2–31
DocApp creating custom, 8–1
Accelera DocApp, 10–86 dictionary, 2–15
custom, 2–1, 2–7, 10–86 dispatcher, 2–31
definition, 2–1, 10–86 HTML files, 2–31
deploying, 2–4, 2–10, 10–88 pages, 2–15
installing, 10–88 success pages, 2–31
packaging, 10–88 XML, 2–16
references, 10–87 features
testing, 2–4, 2–10, 10–88 dictionary, 2–31
troubleshooting, 10–89 failure pages, 2–31
Docbase form
cabinets, 1–5 templates, 2–31
folders, 1–5
Docbasic
errors
G
external .ebs file, A–2 graphic element, 10–17
in-line script, A–2 graphic selector, 10–17
documentation, hard copy, –
H
E hard copy, –
Editor presentation file hierarchy
complete code example, 10–81 custom folder, 2–13
definition, 10–78 product folder, 2–32
example product folders, 1–4
building XSL, 10–79 history mechanism
end tag, 10–81 definition, 2–18, 2–32
HTML, 10–78 dispatcher, 2–32
start tag, 10–78 failure pages, 2–18
Editor rules file history_utils script, 2–32
complete code example, 10–69 start.htm, 2–32
definition, 10–64 success pages, 2–18, 2–32
example HTML
benefits, 10–68 XSL file, 10–90
description, 10–67
product image, 10–66 I
product name, 10–64 import
product number, 10–65
adding or removing, 7–4, 7–7
product price, 10–65
customizing, 7–1, 7–5
start and end, 10–64 page, 7–1, 7–5
F L
feature lifecycle
actionlist, 8–4
definition, 2–3, 2–9
attributes, 2–15, 2–31
TM
Index–2 Customizing Documentum WebPublisher
Index
testing, 10–88 bu_header.htm file sections, 6–13

list item custom
adding, 5–1 affected_departments, 6–7
adding attributes, 5–3 approval_department, 6–7
copying, 5–2, 5–6, 8–3 effective_date, 6–7
list_item.xml file, 5–2, 5–6, 8–3 r_object_type, 6–7
modifyin attributes, 5–6 sop_number, 6–7
SOP number, 5–4 custom object, 6–6
SOP number label, 5–4 customizing, 6–1
thumbnail, 5–6 default attribute, 6–11
default logical operator, 6–4
default object type, 6–4
N keywords, 6–11
new content new, 6–12
customizing, 7–1 object_name property, 6–5
page, 6–1, 6–12
O search_facility.xml file, 6–2, 6–10, 6–12
search_facility.xml file sections, 6–3,
object type
6–11
definition, 2–2, 2–8
SOP, 4–1 wd_header.htm file sections, 6–13
SOP
folder structure, 4–4
P
PDF, –
T
process workflows, 9–1
tabledef, 10–43
property, 4–4
See also attribute teComponentType, 10–14
template
page, 4–1
associating, 10–85
validating, 10–85
R templates
references customizing, 10–1
HTML and JavaScript, xii test
related documentation, xi DocApp, 2–4, 2–10
repeatdef, 10–45 text selector, 10–29
role, 3–1 textline, 10–4
rules file textselector, 10–29
attributes, 10–3 texttrigger, 10–63
creating, 10–3 thumbnail file
elements, 10–3 creating, 10–83
definition, 10–83
troubleshooting
S Docbasic errors, A–2
script external .ebs file, A–2
edit script, 4–14 in-line script, A–2
view script, 4–15 memory cache, A–1
search
TM
Customizing Documentum WebPublisher Index–3
Index
V WebPublisher Editor
value assistance associating, 10–85
attribute, 4–9 customizing, 10–1
value selection importing templates and files, 10–84
attribute, 4–9 templates, 10–1
variables templates and files
dispatcher, 2–26 definition, 2–5, 2–11
verifying, 10–84
adding new content, 10–85
W promoting content, 10–85
Web page publishing, 10–86
creating, 10–1 validating templates, 10–85
custom, 10–1 Web page, 10–86
example, 10–86 workflow
publishing, 10–86 definition, 2–3, 2–9
Web server testing, 10–88
components, 2–27 workflows
files, 1–4 process, 9–1
folder structure, 2–27
Web site
creating, 10–1
X
custom, 10–1 XML
WebPublisher configuration, 2–16
4i products fundamentals, 2–16
AutoRender Pro, 1–1 xselector, 10–48
Content Personalization XSL
Services, 1–1 building, 10–79
Developer Studio, 1–1 XSL file
Documentum Administrator, 1–1 HTML renditions, 10–90
eContent Server, 1–1
Engagement Services, 1–1
ftpIntegrator, 1–1
Media Services, 1–1
RightSite, 1–1
WebCache, 1–1
TM
Index–4 Customizing Documentum WebPublisher

Customizing Documentum Webpublisher: March, 2002

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Customizing Documentum Webpublisher: March, 2002

Diunggah oleh

Hak Cipta:

Format Tersedia

Customizing Documentum

Chapter 1 Functional Overview and Architecture .......................................... 1–1

Chapter 2 Customization Overview .................................................................... 2–1

Chapter 3 Customizing WebPublisher’s Default Settings ........................... 3–1

Chapter 4 Customizing the Properties Page ................................................... 4–1

Adding and Removing Object Attributes ............................................................... 4–6

Chapter 5 Modifying a List Item .......................................................................... 5–1

Chapter 6 Customizing Search Pages ............................................................... 6–1

Chapter 7 Customizing Content Pages ............................................................. 7–1

Chapter 8 Creating a Custom Feature ............................................................... 8–1

Chapter 9 Creating Process Workflows and Lifecycles ............................... 9–1

Troubleshooting Translation Workflows .............................................................. 9–13

Chapter 10 Creating a Web Site .......................................................................... 10–1

Appendix A Troubleshooting ................................................................................ A–1

Glossary ...................................................................................................................... GL–1

Index .......................................................................................................................... Index–1

Figure 1–1. Documentum 4i System ......................................................................................... 1–2

Table 1–1. WebPublisher Folders on Web Server ....................................................................... 1–4

Table 10–8. <repeatdef> Attributes ........................................................................................ 10–46

Purpose of the Manual

Chapter 1, Functional Overview and Architecture Discusses customization methodology and

Chapter 2, Customization Overview Discusses the WebPublisher hierarchy, the

Chapter 3, Customizing WebPublisher’s Default Discusses modifying WebPublisher’s

Chapter 6, Customizing Search Pages Discusses how to customize an existing

Chapter 8, Creating a Custom Feature Provides step-by-step instructions to create

Appendix A Provides you with information about

> Represents a pop-up or pull-down menu.

typewriter Represents code samples, user input, and computer output.

bold Represents a button in on the WebPublisher page.

• Documentum RightSite Reference Manual provides Documentum RightSite Web

HTML and JavaScript References

• Documentum Administrator for administering the eContent Server. Using

Figure 1–1. Documentum 4i System

Web Server Components

Figure 1–2. WCM Folder Subfolders

Table 1–1. WebPublisher Folders on Web Server

app_jarfiles Jar files for WebPublisher Editor.

application WebPublisher DocApp archive files.

Customization files for WebPublisher. Features in this folder over-

product Folders and files that control default WebPublisher behavior.

Scripts that are used by lifecycles and workflows in the WebPub-

temp Temporary system folder.

Docbase Cabinets and Folders

Figure 1–3. WebPublisher Configuration Cabinet

Table 1–2. WebPublisher Docbase Folders

Common Contains objects that apply across all of WebPublisher.

FolderMap An XML file that specifies where newly created files

System Configuration Object consisting of properties that define a set of

Content Templates Contains all content templates that can be selected

Favorites Contains the list of frequently accessed items

Supporting Templates Contains template files used by the content templates.

Editor Rules Contains rules files used by the WebPublisher Editor.

Thumbnails Contains thumbnail files that provide a pictorial

User Preferences Contains preference settings for individual

Default DocApp Components

During installation, the WebPublisher DocApp, which includes predefined WebPublisher

Figure 1–4. WebPublisher Object Model

Table 1–3. dm_sysobject

Property Name Description Value

a_category Describes the categorization of the char (64) on Oracle,

a_effective_label Name of the delivery channel char (32) repeating

a_effective_flag Indicates whether a pending char (8) repeating

a_effective_date Date the object should become date repeating