Oracle® Fusion Middleware

Developer's Guide for Site Studio for External Applications

11g Release 1 (11.1.1)

E13650-01

May 2010

Oracle Fusion Middleware Developer's Guide for Site Studio for External Applications, 11g Release 1 (11.1.1)

E13650-01

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Will Harris

Contributor:  Adam Stuenkel, David Wyman, David Truckenmiller, Sean Cearley, Ron van de Crommert

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Contents

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

1 About Site Studio for External Applications

- 1.1 Understanding the Site Studio Project Structure

- 1.2 Understanding Site Studio Site Files

- 1.3 Understanding the Site URL Format

- 1.4 Understanding Site Studio JSP/JSPX Templates

- 1.5 Understanding Security and Contributor Authentication

- 1.6 Understanding Content Caching

- 1.7 Understanding Service Caching with the Site Studio Tag Library

2 Understanding Site Studio Web Sites

- 2.1 Separation of Site Presentation and Content

- 2.2 Site Asset Storage

- 2.3 Site Roles

- 2.4 Presentation Model

- 2.5 Contribution Model

- 2.6 Site Object Hierarchy

- 2.7 Reusing Site Assets

- 2.8 Elements and Element Definitions

- 2.9 Region Templates and Region Definitions

- 2.10 Placeholders and Placeholder Definitions

- 2.11 Subtemplates

- 2.12 Page Templates

- 2.13 Contributor Data Files and Native Documents

- 2.14 Primary and Secondary Pages

3 Planning Your Web Site

- 3.1 Why is Planning Important?

- 3.2 Planning Your Site Hierarchy

- 3.3 Planning Your Contribution Model

- 3.4 Planning and Naming Your Site Assets

- 3.5 Creating Your Site Assets

- 3.5.1 Step One: Create Your Element Definitions

- 3.5.2 Step Two: Create Your Region Definitions

- 3.5.3 Step Three: Create Your Region Templates

- 3.5.4 Step Four: Create Your Subtemplates

- 3.5.5 Step Five: Create Your Placeholder Definitions

- 3.5.6 Step Six: Create Your Page Templates

4 Building a Site Studio Web Site Tutorial

- 4.1 Creating a Site Studio Project and Connection

- 4.1.1 Step 1: Creating a New Application and Project

- 4.1.2 Step 2: Creating a Content Server Connection

- 4.1.3 Step 3: Adding the Connection to the Project

- 4.2 Creating a Sample Web Site

- 4.2.1 Step 1: Creating a New Web Site in the Content Server

- 4.2.2 Step 2: Specifying User Credentials for Contribution Mode

- 4.2.3 Step 3: Editing the Web Application Deployment Descriptor

- 4.2.4 Step 4: Creating the Home Page

- 4.2.5 Step 5: Associating the Page Template with the Site

- 4.2.6 Step 6: Running the Site and Viewing the Home Page

- 4.2.7 Step 7: Creating Site Fragments

- 4.2.8 Step 8: Creating the Element Definitions

- 4.2.9 Step 9: Creating a Region Definition

- 4.2.10 Step 10: Creating a Region Template

- 4.2.11 Step 11: Creating a Placeholder Definition

- 4.2.12 Step 12: Adding a Placeholder to the Home Page

- 4.2.13 Step 13: Assigning Content to the Placeholder

- 4.3 Creating Sidebar Links

- 4.3.1 Step 1: Creating a Static List Element Definition

- 4.3.2 Step 2: Creating a Sidebar Region Definition

- 4.3.3 Step 3: Creating Static List Data File

- 4.3.4 Step 4: Creating a Region Template

- 4.3.5 Step 5: Updating the Sidebar Fragment

- 4.3.6 Step 6: Creating a Sidebar Content Region Definition

- 4.3.7 Step 7: Creating a Sidebar Content Region Template

- 4.3.8 Step 8: Creating a Sidebar Content Placeholder Definition

- 4.3.9 Step 9: Adding a Sidebar Placeholder Mapping to the Site

- 4.3.10 Step 10: Assigning Content to the Sidebar

- 4.4 Creating A Dynamic Conversion Page

- 4.4.1 Step 1: Creating a Conversions Definition

- 4.4.2 Step 2: Creating a Page Template for the Native Document

- 4.4.3 Step 3: Creating a New Section for the Native Document

- 4.4.4 Step 4: Creating a Region Definition for the Native Document

- 4.4.5 Step 5: Creating a Region Template for the Native Document

- 4.4.6 Step 6: Creating a Placeholder Definition for the Native Document

- 4.4.7 Step 7: Adding the Placeholder to the Native Document Page

- 4.4.8 Step 8: Assigning Content to the Placeholder on the Native Document Page

5 Site Studio Application Components and Technology

- 5.1 Site Studio Application Components

- 5.2 Site Studio Technologies

- 5.2.1 Site Studio Servlets

- 5.2.2 Site Studio Filters

- 5.3 Using Site Studio Technologies in Your Integration

6 Site Studio Tag Library and Helper Methods

- 6.1 Site Studio Tag Library

- 6.1.1 Site Studio Tag Descriptions

- 6.1.2 Site Studio <wcm:context> Tag

- 6.1.3 Site Studio <wcm:dataFile> Tag

- 6.1.4 Site Studio <wcm:dynamicConversion> Tag

- 6.1.5 Site Studio <wcm:dynamicList> Tag

- 6.1.6 Site Studio <wcm:idcParameter> Tag

- 6.1.7 Site Studio <wcm:idcService> Tag

- 6.1.8 Site Studio <wcm:metadata> Tag

- 6.1.9 Site Studio <wcm:placeholder> Tag

- 6.1.10 Site Studio <wcm:staticPlaceholder> Tag

- 6.1.11 Site Studio <wcm:url> Tag

- 6.2 Site Studio Helper Methods

- 6.2.1 Site Studio <filterSections> Method

- 6.2.2 Site Studio <listSectionsForRows> Method

- 6.2.3 Site Studio <isNodeInNavigationPath> Method

- 6.2.4 Site Studio <lookupSection> Method

Index

Preface

The Developer's Guide for Site Studio for External Applications contains information to assist individuals who are responsible for the design and development of Web sites using Site Studio for External Applications and managed by Oracle Content Server.

Audience

This document is intended for those people identified in the organization who are responsible for designing an organization's Web site managed by Site Studio.

Documentation Accessibility

Our goal is to make Oracle products, services, and supporting documentation accessible to all users, including users that are disabled. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/.

Accessibility of Code Examples in Documentation

Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in Documentation

This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/support/contact.html or visit http://www.oracle.com/accessibility/support.html if you are hearing impaired.

Related Documents

For more information on Oracle Site Studio for External Applications and associated technologies, see the following documents:

- Oracle Fusion Middleware Site Studio for External Applications Java API Reference

- Oracle Fusion Middleware Services Reference Guide for Universal Content Management

- Oracle Fusion Middleware Remote Intradoc Client (RIDC) Java API Reference

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

1 About Site Studio for External Applications

Site Studio for External Applications is a powerful, flexible web development tool that offers a comprehensive approach to designing, building, and maintaining enterprise-scale Web sites in an Application Server environment. Web site development and template creation is performed in the JDeveloper environment. Site assets, such as files and graphics, are stored and managed in the content server. Page templates, region templates, and subtemplates (which are typically JSP or JSPX pages) are located in the WAR file of the web application associated with your JDeveloper project.

Site Studio for External Applications dramatically improves productivity and allows organizations to maintain accurate, timely, and current web content with consistent branding and presentation across all corporate sites. With Site Studio, you can centralize control of site architecture and presentation, while distributing content development and ongoing maintenance to business units or other teams. Additionally, Site Studio for External Applications can be integrated with third-party applications servers.

This section covers the following topics:

- "Understanding the Site Studio Project Structure"

- "Understanding Site Studio Site Files"

- "Understanding the Site URL Format"

- "Understanding Site Studio JSP/JSPX Templates"

- "Understanding Security and Contributor Authentication"

- "Understanding Content Caching"

- "Understanding Service Caching with the Site Studio Tag Library"

1.1 Understanding the Site Studio Project Structure

This is the basic structure of a Site Studio project:

+ Site Files
+ templates
+ page
+ region
+ subtemplates
+ Web Content
+ wcm
+ WEB-INF
+ sites
- wcm-config.xml
- web.xml
- weblogic.xml

Please note the following nodes and files:

- Site Files: This is a virtual node that points to the Web Content/wcm node.

- Web Content/wcm: This node contains the page templates, region templates, and subtemplates for this project.

- Web Content/WEB-INF: This node contains the XML descriptor files and configuration files.

- WEB-INF/sites: This node contains the XML files that store the data and configuration information for the Site Studio site. See "Understanding Site Studio Site Files" for more information.

- WEB-INF/wcm-config.xml: The Site Studio configuration file.

- WEB-INF/web.xml: The web-app XML descriptor file.

- WEB-INF/weblogic.xml: The Oracle WebLogic deployment descriptor file.

1.2 Understanding Site Studio Site Files

In JDeveloper, Site Studio site files are located in the sites directory of your Site Studio project (from the main menu, select View then Application Navigator then Projects then expand Web Content then expand WEB_INF then sites). Site Studio site files are XML files that store the data and configuration information for the Site Studio site. The XML file is maintained on JDeveloper, but all content resides on the content server.

The site files contain site-related information including:

- The site hierarchy.

- Properties of each site section (including associated page templates, region templates, and content files, and custom section properties).

- Explicit data file associations (for example, which content files are used and their location in the site).

- Mappings of placeholder names to placeholder definitions.

- Items in the asset pane (including how they are categorized).

1.3 Understanding the Site URL Format

The site URLs are hierarchical, allowing navigation through a given project file. They have the following general format:

/[Site Identifier]/[Section 1]/[Section 2]/.../[content].html

- Site Identifier: The path that identifies a site, the URL pattern listed in the wcm-config.xml file.

- Section: A list of sections, identified by the either the urlDirName attribute or the label attribute in the project file.

- Content: Can be the content ID (dDocName) of an item on Oracle Content Server, or index to refer to the primary page.

For example, a path to the primary page of the About section:

/mysite/About/index.html

A path to a piece of content to display in the Products section:

/mysite/Products/new_product.html

1.4 Understanding Site Studio JSP/JSPX Templates

Templates (page templates, region templates, and subtemplates) in Site Studio are typically JSP or JSPX pages. The templates are located in the WAR file of the Web application, typically as a subdirectory of the /wcm/templates directory. Any template type can contain any valid JSP syntax. However, it is assumed that the templates will have the following structure:

- Page Template: Contains wcm:placeholder tags that create areas in a page for assignable content.

- Region Template: For modeling data file content. Typically contains either a wcm:dataFile tag or wcm:dynamicConversion tag to retrieve the assigned content. It does not contain wcm:placeholder tags.

- Subtemplate: Like a page template, but is typically responsible for a portion of a page after being assigned to a placeholder. May contain other wcm:placeholder tags.

Template Registration

Templates are registered with a unique identifier in the wcm-config.xml file. This identifier is used to identify the template throughout the Site Studio application. The identifiers are used in the project file to identify page templates (either primary or secondary) and are used in placeholder definitions, to identify a region template or subtemplate.

This template maps the name homepage to the path /wcm/templates/page/homepage.jspx. When the homepage identifier is encountered, the RequestDispatcher is invoked to include the path.

<mappings>
<pageTemplates>
<mapping path="/wcm/templates/page/homepage.jspx" id="homepage"/>
</pageTemplates>
</mappings>

There is no requirement that the template has to point to a JSP or JSPX file. The mapping can point to any valid web application resource. For example, a section could point to another servlet for processing:

<mappings>
<pageTemplates>
<mapping path="/servlets/reserveMeetingRoom.do" id="reserveMeeting"/>
</pageTemplates>
</mappings>

1.5 Understanding Security and Contributor Authentication

Communication with the content server is through the IntradocPort, typically port 4444 on the content server. This allows Site Studio to assume the role of any user. All placeholder content is therefore retrieved as the user specified in the wcm-config.xml file, on the contentServer element as the adminUser. Subsequently, all content displayed in a placeholder (data files, native documents, etc.) and all content retrieved through the proxy servlet perform a security check for read access.

Security Settings

In the wcm-config.xml file, the security element defines how security is handled. If the enabled attribute is set to false, no security checks are performed in consumption mode and all content displayed through the placeholder will be readable. Requests through the proxy servlet will still be validated.

Depending on your content server configuration, you can also specify the level of security using the securityType attribute (each level is in addition to the previous level):

- groups: Check security based on the content server security group.

- accounts: After checking the group, check the security accounts.

- acl: After checking the accounts, validate against any access control lists (ACLs).

Contribution & Design Mode Authentication

Contribution and design modes require authentication to the application server running the site. This is done using the security settings in the web.xml file:

<security-constraint>
<web-resource-collection>
<web-resource-name>ContributionMode</web-resource-name>
<url-pattern>/wcm-contrib/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>WCMContributor</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>FORM</auth-method>
<realm-name>OpenWCM</realm-name>
<form-login-config>
<form-login-page>/wcm/support/login/wcm-login.jsp</form-login-page>
<form-error-page>/wcm/support/login/wcm-login.jsp</form-error-page>
</form-login-config>
</login-config>

<security-role>
<role-name>WCMContributor</role-name>
</security-role>

Upon selecting Ctrl+Shift+F5 on a page with placeholder content, the page is refreshed to a URL with /wcm-contrib as the first segment. The application server then validates that the user has the appropriate application role assigned to them via the application server. The role name, as described in the web.xml, is WCMContributor. If the user does not have this role, a login screen is presented and the application server denies access until the credentials are validated and the role condition is met.

The default login page can be customized by changing the web.xml to point at a customized JAAS login page or by adding a local copy of the file /wcm/support/login/wcm-login.jsp to your web application. This page will then be used instead of the shared default version.

Once in contribution mode or design mode, the user ID is now used to validate security and all placeholder content is retrieved live from the content server. Additionally, the rendition is switched from Latest Released to Latest so the contributor user can view content in workflow or otherwise not yet released.

1.6 Understanding Content Caching

Content is cached in a temporary location on the application server. This can be customized to a particular location using the stagingDir attribute on the staging element in the wcm-config.xml file. The content cache stores a local copy of all files, associated metadata, and any associated conversions or renditions.

Any request for content first checks the local cache. If not found, the content server is contacted and the content is placed into the cache. Note that no security information is cached; all security calls go to the content server. Additionally, only Latest Released content is cached; content retrieved during contributor or design modes (Latest Rendition) is not put into the cache.

A background thread, controlled by the contentServer element using the pollerInterval attribute, pings the content server at regular intervals to keep the cache content up to date. A content server administrator can, using cache information, request all caches be refreshed by visiting the Cache Administration page on the content server at this URL (example):

http://localhost:16200/cs/idcplg?IdcService=SSXA_GET_ADMIN_PAGE

1.7 Understanding Service Caching with the Site Studio Tag Library

The caching facilities in Site Studio allow for the caching of service calls. Any service call can be cached to the same location that content and metadata is currently cached. The caching facility is defined using DataBinder properties:

1. Specify a special parameter to enable caching.

2. Determine the cache key using one of the following methods:

- Specify a custom cache key.

- Specify the local data fields to use to generate a key.

- Allow the system to calculate the cache key by using a hash of all local data.

Caching Properties

All caching is controlled using properties set in the DataBinder. For JSP/JSPX, these properties can be added with the wcm:idcParameter tag to either a wcm:idcService call or a wcm:dynamicList call.

Parameters:

- __ssxaCacheEnabled: Set to true to enable caching.

- __ssxaCacheKey: Specify a cache key to use for this request. Optional.

- __ssxaCacheFields: Specify a CSV list of fields to use to generate the cache key (if not specified, all local data is used). Optional.

- __ssxaCacheTTL: Specify a time to live value, in milliseconds, for the cached data. If not specified, the default value of 5 minutes is used. If specified a value of 0 or less, the cache item will live indefinitely (no timeout). Optional.

Example of caching a dynamic list, with the value being refreshed every 60 seconds:

<wcm:dynamicList var="searchResponse" element="nativedocs">
<wcm:idcParameter name="__ssxaCacheEnabled" value="true" />
<wcm:idcParameter name="__ssxaCacheTTL" value="60000" />
</wcm:dynamicList>

Example of caching a GET_SEARCH_RESULTS service call:

<wcm:idcService var="dataBinder" service="GET_SEARCH_RESULTS">
<wcm:idcParameter name="QueryText" value="" />
<wcm:idcParameter name="__ssxaCacheEnabled" value="true" />
</wcm:dynamicList>

Cache Details

Service calls are staged into the cache directory, alongside the content, metadata and project files. The directory /idc-service is created with this directory structure:

/idc-service/service_name/user_name/cacheID.hda

This example shows a cache directory for a search results:

+- idc-service/
+- ssxa_get_dynamic_list_results/
+- anonymous/
+- 3164744485.hda
+- get_search_results/
+- anonymous/
+- 2452981209.hda

2 Understanding Site Studio Web Sites

Site Studio provides a powerful set of tools that can allows you to design, build, and maintain Web sites efficiently. To get the most out of these tools, it is useful to understand some basic concepts about Site Studio Web sites.

This section covers the following topics:

- "Separation of Site Presentation and Content"

- "Site Asset Storage"

- "Site Roles"

- "Presentation Model"

- "Contribution Model"

- "Site Object Hierarchy"

- "Reusing Site Assets"

- "Elements and Element Definitions"

- "Region Templates and Region Definitions"

- "Placeholders and Placeholder Definitions"

- "Subtemplates"

- "Page Templates"

- "Contributor Data Files and Native Documents"

- "Primary and Secondary Pages"

2.1 Separation of Site Presentation and Content

One thing that makes Site Studio a valuable tool is that it allows Web site content to be completely separate from Web site presentation. This way, different people can manage and be responsible for the information on a Web site without inadvertently affecting the layout, design, or look-and-feel of the site. In addition, the people assigned to manage the site content can make changes as necessary without having to send them to someone else to complete the task. This removes an important bottleneck that exists in many site management scenarios, where all site changes must be handled by a very limited number of site administrators.

With separation of site presentation and content in mind, the files associated with a Web site can be divided into three main categories:

- Site Presentation Files

- Site Content Files

- Site Control and Configuration Files

Site Presentation Files

A number of the files associated with a Site Studio Web site are used to define what the site looks like in terms of page layout and formatting. They provide the design framework within which the site content is displayed. Any changes to these files typically affect the entire site (or large portions of it), and they are usually created and managed by dedicated site designers.

Site Studio uses the following files for site presentation:

- Page templates: Fully-formed HTML files that define the layout and high-level look-and-feel of web pages, including the placement of contribution regions (that is, editable areas on the page), navigation aids (in the form of fragments) and site-wide images (banners and the like). Page templates are the highest-level site design object. See "Page Templates" for more information.

- Region templates: Partial HTML files (that is, without head and body sections) that define the layout and look-and-feel of the data in contribution regions within web pages. See "Region Templates and Region Definitions" for more information.

- Subtemplates: Partial HTML files (that is, without head and body sections) that can be inserted into placeholders on page templates to divide them into further smaller, reusable areas with their own placeholders and contribution regions. See "Subtemplates" for more information.

In addition to these files, which directly affect the site presentation, there are also several files configuration files that have an impact on Web site presentation. See "Site Control and Configuration Files" for more information.

Site Content Files

The site content (that is, the actual information on the site) is stored in separately managed files, separate from the presentation context in which they appear. This enables them to be managed separately and reused within a Web site, or even between Web sites (providing these sites are all managed using the same content server).

Site Studio uses the following files for site content:

- Contributor data files: Content files in XML format that are generated by Site Studio. Contributor data files are edited using the Site Studio Contributor application. See "Contributor Data Files and Native Documents" for more information.

- Native documents: Content files created using familiar third-party applications such as Microsoft Word. Native documents are converted to HTML format using Dynamic Converter, and they are edited using their associated application. See "Contributor Data Files and Native Documents" for more information.

- Images: Graphic files (JPG, GIF, PNG) that are included in content files or page templates (for example, corporate banners or product images).

- Other media: Any other media files that could be used on a Web site, such as Flash animations, video files, audio files, and so on.

Site Control and Configuration Files

In addition to the files that directly affect site presentation, there are several configuration files that also have an impact on Web site presentation.

Site Studio uses the following files for site control and configuration:

- Element definitions: Files that define the editing experience for element types. Specifically, they specify what a contributor can do when editing an element. See "Elements and Element Definitions" for more information.

- Region definitions: Files that define the type of content that elements of a particular type consists of. They also specify the content creation and switching options available to contributors for contribution regions, and set default metadata for content files associated with these regions. See "Region Templates and Region Definitions" for more information.

- Placeholder definitions: Files that define what region definitions, region templates, and subtemplates are allowed for the associated placeholders. They also specify what contributor actions are allowed for the placeholders. See "Placeholders and Placeholder Definitions" for more information.

- Validation scripts: JavaScript files that define the validation rules for element data to determine that the data meets the requirements (for example, it does not exceed a certain maximum length or contain some illegal characters).

- Conversion definitions: Files that specify the conversion rules for native documents on a Web site.

- Custom configuration scripts: JavaScript files that override the default Contributor editor configuration to provide contributors with a customized editing experience.

- Custom element forms: HTML files that define custom forms for use in elements (for example, selection forms for specific file types). Site Studio comes with several predefined custom element forms. (These forms are also checked into the content server when the Site Studio component is installed.)

2.2 Site Asset Storage

All files associated with a Site Studio Web site are stored and managed using Oracle Content Server. A number of custom metadata fields specific to Site Studio are used to specify where and how the files are used.

Figure 2-1 Site Studio Metadata Fields on Content Information Page of Site Asset

Site Studio uses the following metadata fields for all site-related files:

- Web Site Object Type: Specifies the type of file for the Web site (for example, “Data File,” Stylesheet,” “Region Template,” and “Placeholder Definition”).

- Web Sites: Lists the Web site(s) that the file is associated with. This means that the file can be used on the listed site(s), although it is not necessary. A file may be associated with multiple Web sites, which means it can be reused between sites. This makes multi-site management more efficient.

- Exclude From Lists: Lists the Web site(s) for which a contributor has specified that a particular content file (a contributor data file or native document) should not display in dynamic lists on the Web site.

- Web Site Section: Specifies where a content file is displayed by default on a Web site (unless a target section is explicitly specified in the original hyperlink).

- Region Definition: Specifies the region definition that a region template or content file (contributor data file or native document) is associated with. This determines how the file displays on the site and what contributors are allowed to do. A region template and content file can be associated with only one region definition, but a region definition may have many region templates and content files associated with it.

Please note that some fields are automatically set as the file is created and checked into the content server. Also, not all metadata fields are used for all site assets, since they may not be relevant. For example, the xRegionDefinition metadata field is not used for page template, since these are not associated with region definitions.

You can change the values of these fields on the content information page of a file, but be carefully when doing that, since this may affect the way the file is used on a site.

2.3 Site Roles

When the various roles for Web site creation and management within the organization are determined, each can focus on specific tasks in making the Web site work.

Designers focus on how the Web site looks. That is, the structure of the pages, the way the pages are laid out, the design, and the corporate identity.

Contributors are then able to place the content on the page without having to code the pages. Contributors can then update and edit the content without affecting how the page is displayed, and without having to make multiple changes to multiple areas of the Web site. The designer, for the most part, does not control the content. Contributors, for the most part, do not control how the content displays on the site.

2.4 Presentation Model

Site Studio completely separates the presentation layer from the content layer of a Web site, as shown in Figure 2-2.

Figure 2-2 Presentation Model for Site Studio Web Sites

Page templates are used to define the site framework within which content is displayed. They contain standard HTML layout and formatting code, along with Site Studio tags to specify where fragments and/or placeholders go. Placeholders specify where the contribution regions (that is, editable areas) are on the page. Please note that they do not specify anything about what goes in these regions, both in terms of content and visual presentation. That is handled by region templates (with their associated region definitions).

Region templates define the layout and look-and-feel of the data in a contribution region (marked on a page template using a placeholder tag). They are separately managed site assets, which makes them easy to reuse within Web sites, or even between Web sites. (Please note that in Site Studio releases prior to 10gR4 region presentation was not separately managed, but included within page templates, or 'layout pages' as they were called in these previous releases.)

The content of contribution regions is stored in data files, which are also separately managed site assets. When it is time to generate a web page, Site Studio looks at the placeholder on the page template, takes its associated region template and data file, and merges these two to create HTML code that is inserted into the page template at the position of the placeholder tag. This creates the final web page, which all content in place, presented and formatted in accordance with the site and page settings.

2.5 Contribution Model

As with the presentation model, the contribution side of Site Studio Web sites separates site content from presentation, as shown in Figure 2-3.

Figure 2-3 Contribution Model for Site Studio Web Sites

When site contributors decide that they want to edit the contents of a web page, they press a key combination to reload the page in contribution mode. (The default key combination is Ctrl+Shift+F5, but this may be modified.)

After a page is in contribution mode, all contribution regions (that is, editable areas) on a web page are marked and underlying code has been added to the page to identify what placeholder is associated with the contribution region. Based on this information, Site Studio can establish what placeholder definition and region definition are used for the placeholder. The region definition identifies the structure of the content in the contribution region in terms of its constituent data segments (elements). Each element has an element definition, which defines what editing options are available to contributors for the element.

When the contributor decides to edit the content in a contribution region, its associated contributor data file is checked out of the content server. The structure of the data file matches that of its associated region definition in terms of number and types of elements. The data is loaded from the data file and presented in the Contributor editor. Each element in the data file is presented as an editable element in the editor, with the editing features as defined in the element definition for the element type.

When the contributor is done editing and clicks the save icon in the Contributor editor, the data file is updated and checked into the content server again. The web page is then updated in accordance with the site update schedule.

Please note that the Contributor editor always shows all elements in the region definition (and hence, data file) associated with a contribution region, even if they are not used in that particular region. The other elements may be used elsewhere on the Web site, so editing that information may affect other pages on the site.

2.6 Site Object Hierarchy

Figure 2-4 shows the hierarchy of site objects that are used to create and manage a Site Studio Web site.

Figure 2-4 Object Hierarchy of Web Sites

Page templates are at the top of the hierarchy. They provide the framework for the pages in a Web site within which the site content is displayed. In addition to standard HTML layout and formatting code, they contain site-wide images and other assets, and tags for fragments and/or placeholders. Page templates are stored and managed on the content server. See "Page Templates" for more information.

A placeholder is an insertion point on a page template to identify where there is a contribution region (that is, editable area) on the web page. What that contribution region contains and what it looks like is defined using region templates and region definitions. A page template may contain multiple placeholders. There are no files associated with placeholders. Placeholders are controlled by placeholder definitions, which specify what content can go in the contribution region and how it is displayed, as well the actions available to contributors (for example, switching content or modifying metadata). A placeholder contains either one subtemplate or one region template. See "Placeholders and Placeholder Definitions" for more information.

A subtemplate is a partial HTML file (that is, without a head and body section) that provides a mechanism to divide a placeholder on a page template into further smaller, reusable areas with their own placeholder(s). There is a circular relationship between placeholders and subtemplate; that is, a placeholder may contain a subtemplate, which, in turn, may include one or more placeholders. Subtemplates are stored and managed on the content server. See "Subtemplates" for more information.

A region template is a partial HTML file (that is, without a head and body section) that defines the layout and look-and-feel of the data in a contribution region (marked on a page template using a placeholder tag). Region templates are controlled by region definitions, which define what kind of content can go in the region template. They also specify the content creation and switching options available to contributors for the contribution region, and set default metadata for content files associated with the region. Both region templates and region definitions are stored and managed as separate assets on the content server. A region template may have one or more references to elements. See "Region Templates and Region Definitions" for more information.

Elements are the smallest chunks of reusable information in a Site Studio Web site. They are referenced in region templates, which causes their data to be pulled into the region template using the layout and presentation defined in the template. A region template may contain multiple element references. There are no files associated with elements. Groups of elements are arranged in region definitions, which specify site content types. Elements are controlled by element definitions, which specify the editing experience available to contributors for an element type. Specifically, they set the available editing features in the Contributor editor when a contributor is editing elements in a contributor data file. See "Elements and Element Definitions" for more information.

Figure 2-5 shows an example of a site object hierarchy.

Figure 2-5 Example of Site Object Hierarchy

In Figure 2-5, there is a placeholder (that is, an editable contribution region on a page template) that has two region templates available to it (as specified in the placeholder definition). Region template A shows a limited data view, with just the title and a brief introductory text. Region template B presents a more elaborate data view, with the title, subtitle, body text, and an image. Either can be used for the placeholder, depending on the site context. Both region templates are associated with a region definition that has elements for each of the reusable chunks of information (Title, Subtitle, Intro_Text, Body_Text, and Image). Each of these elements is associated with an element definition.

The Title and Subtitle elements are of the same type (text only), but they have different element definitions, which means that the editing features available to contributors are different. The Intro_Text and Body_Text elements are both WYSIWYG elements, which typically means that contributors have a broad array of editing options available to them when editing these elements (for example, the ability to add tables or use advanced text formatting). The editing experience for contributors is the same for these elements.

One or more contributor data files are associated with the region definition, and ultimately with the contribution region. Their structure matches that of the region definition. They contain the same elements: Title, Subtitle, Intro_Text, Body_Text, and Image. When a contributor decides to edit the content in a contribution region, its associated contributor data file is loaded into the Contributor editor, which provides one editing area for each element in the data file. The editing features available in each area are set by the element definition.

2.7 Reusing Site Assets

One of Site Studio's most useful and powerful features is the ability to reuse site assets within a Web site and even across multiple sites (providing these sites are all managed on the same content server). When an asset is changed once, it is changed everywhere that asset is used. It is no longer necessary to keep track of all instances of a piece of data to ensure that all of the web pages are updated. This applies both to files associated with site presentation and site content (see "Separation of Site Presentation and Content"). Page templates, region templates, elements, and the like are most efficiently used when they are used multiple times. Similarly, the same content files can be displayed in different locations on a site, either completely or partially (different segments), to suit the context.

Figure 2-6 and Figure 2-7 show an example of site content being reused. In Figure 2-6, you can see a list of items consisting of a title, image, and subtitle. This information is taken from separate contributor data files. Each of these list items could be hyperlinked to open the full page as shown in Figure 2-7. In fact, this is the type of design that you see on many sites. That is, information is displayed on a primary page, and the full information is shown on a subsequent page when you click a link.

Figure 2-6 Web Page With Introductory Content

Figure 2-7 Web Page With Full Content

The web page in Figure 2-7 displays many of the same pieces of information. That is because the same data file is being used on both the region template in Figure 2-6 and the page in Figure 2-7. The elements are the same as well. An image-only element would be used to present the image, for instance, and a text-only element to present the title, with WYSIWYG possibly being the element type used to display the remaining information. There are few elements, typically, necessary in creating a Web site, as one WYSIWYG element can be used anywhere on the Web site where you may want that style of editing for the contributor.

Because site assets are intended to be reused across the Web site, it is particularly important that the Web site is fully planned out before the designer creates anything in the Web site. See Chapter 3, "Planning Your Web Site" for more information.

2.8 Elements and Element Definitions

Elements are the smallest chunks of reusable information in a Site Studio Web site (for example, a title, a product image, or the body text of a press release). Since element data can be reused within (or even between) Web sites, you, as the site designer, should carefully consider how the site content should be broken up into segments. This may take some work up front, but maximizes reusability of site content and also makes managing the site content more efficient in the long run.

Each defined element is of a particular type: WYSIWYG, text only, image only, static list, dynamic list, or custom. These types characterize what the element content consists of, and, through element definitions, what editing options are available to contributors. For example, the title of a press release could be set up as a text-only element (which typically provides only limited editing options to contributors), whereas the actual press release text could be a WYSIWYG element (which typically gives contributors much more editing control, such as the capability to add images or tables).

Elements are controlled by element definitions. An element is basically an instantiation of its associated element definition, which specifies the editing experience available to contributors for the element on the web page (specifically, what editing features are available in the Contributor editor). Element definitions are individually managed site assets, which means that they can be reused within a Web site, or even across Web sites (providing all sites are managed on the same content server). As shown in Figure 2-8, elements of the same type (Title and Subtitle) may have different element definitions associated with them to provide different editing environments for contributors depending on the context in which the element is used. Similarly, multiple elements (Intro_Text and Body_Text) may share the same element definition, providing the same editing experience to contributors for each of the elements.

Figure 2-8 Elements and Element Definitions

Individual elements are not separately managed site asset. Groups of elements are arranged in region definitions, which specify site content types. As shown in Figure 2-8, there could be a region definition called “Press_Release,” which consists of the elements Title, Subtitle, Intro_Text, Body_Text, and Image. A region definition could thus be thought of as a 'content class'.

Element data is stored in contributor data files associated with region definitions. Each contributor data file contains an instance of each element from its associated region definition. In the example of Figure 2-8, the contributor data files would have five elements called Title, Subtitle, Intro_Text, Body_Text, and Image. Contributors can edit the element data in the contributor data files using the editing features available to them for each element, as set in the associated element definitions.

2.9 Region Templates and Region Definitions

Region definitions define the types of content used on a Web site. They could be thought of as 'content classes'. They are essentially groups of individual elements which define the various chunks of reusable information for a particular site content type. For example, as shown in Figure 2-8, there could be a region definition ('content class') called “Press_Release,” which consists of the elements Title, Subtitle, Intro_Text, Body_Text, and Image. Contributor data files are associated with a region definition to store the data for each element in the region definition. (What a contributor can do with the data is controlled by element definitions; see "Elements and Element Definitions".)

In addition to defining site content types in terms of its constituent parts (elements), region definitions also specify the content creation and switching options available to contributors for its associated contribution region(s). For example, if a contribution region is set up to allow contributors to switch the content of that region, they might be allowed to use existing contributor data files on the server only (not native documents or new contributor data files). (Please note that placeholder definitions control whether contributors can actually switch content in contribution regions.) Finally, region definitions also set the default metadata for content in contribution regions as it is checked into the content server.

Region templates define the layout and look-and-feel of the data in contribution regions within web pages. They are partial HTML files in that they do not have a head and body section. This allows them to be inserted into other HTML code as the web pages are generated for the Site Studio site.

Region templates consist of layout and formatting code, along with Site Studio tags to specify where elements (from contributor data files) or dynamic conversions (of native documents) are placed. Some elements from contributor data files may be displayed in some region templates, but not in others, which allows the information to be reused across different pages (as shown in Figure 2-5).

The site designer will probably create region templates more than any other site asset. Region templates allow you to present the information in contributor data files or native documents differently in various contexts of the Web site. As with elements, it is worthwhile spending time considering how the information on your site should be presented through region templates. Judicious use of region templates maximizes the reusability of site content, and also makes site content management more efficient.

In short, region definitions specify what contribution regions on a web page contain, whereas region templates define what contribution regions look like. In other words, region definitions specify the structure (and attributes) of site content, and region templates define the visual presentation of that content on a web page.

There can be multiple region templates for each region definition. This allows site content to be displayed differently depending on the context within the site. If there are multiple region templates for a region definition, then the default region template is used unless a different one was specifically set to be used.

Region templates can be used to display information in multiple places in different layouts, while using data from the same data files. A common example of this is a list of items showing, for example, a title, a brief subtitle, and a small image. An example of this is shown in Figure 2-9, which represents a region template (with sample content) that shows these three elements arranged with the image on the left and the title and subtitle on the right.

Figure 2-9 Region Template With Limited Element Set From Region Definition

The content in Figure 2-9 could be hyperlinked to open a new page with a different region template that shows the same data, but now with more elements from the data file. Figure 2-10 shows an example of such a region template (with sample content), with a title at the top and a subtitle, introductory text, and body text below it. The region template also includes the image (although sized and positioned differently). All content is taken from the same data file as used in Figure 2-9.

Figure 2-10 Region Template With Full Element Set From Region Definition

In the case of Figure 2-9 and Figure 2-10, the contribution regions could be set up to allow contributors to edit the data on either page, but they would be editing the same data file and any changes would be reflected in all places where the data file is used. Please note that if contributors edited the data file from the region template showing the limited element set (Figure 2-9), they would see all elements of the data file in the Contributor editor, even though not all elements are being used in that particular context.

2.10 Placeholders and Placeholder Definitions

A Placeholder is an insertion point (a tag) on a page template (see "Page Templates") to identify where there is a contribution region (that is, editable area) on the web page. A placeholder is represented by a simple tag:

<!--$wcmPlaceholder("Name")-->

What the contribution region identified by the placeholder contains, and how it looks on the site, is defined using region templates and region definitions (see "Region Templates and Region Definitions"). A page template may contain multiple placeholders, each of which representing a contribution region on the page. There are no files associated with placeholders.Figure 2-11 shows a representation of a web page that contains one placeholder, marked with a dotted line (with sample content).

Figure 2-11 Placeholder on Web Page (With Sample Content)

When you insert a placeholder in a page template, all you are doing is marking a named position in the template where content may be inserted. To control how content is handled at that position, you must associate the placeholder name with a placeholder definition. Placeholder definitions specify what content can go in the contribution region and how it is displayed, and the actions available to contributors. For example, a placeholder may be set up to allow contributors to update the metadata of content displayed in the contribution region, or they may be allowed to switch the content of contribution regions. (Please note that region definitions control what kind of content contributors can switch to.)

Associating a placeholder with a placeholder definition (also called 'mapping') can be done in several ways:

- At the site level (using global mappings): You can set up default placeholder mappings that apply to the entire site unless any section-level or placeholder-level overrides are specified. You do this in Designer by opening the Tools menu and then choosing Define Placeholder Definition Mappings. This enables you to associate placeholder names with placeholder definitions for primary and secondary pages. The placeholder names are subsequently referenced in page templates. Placeholder names may be used on multiple templates in multiple sections and the mappings still apply.

- At the section level (using a section property): You can also set a specific placeholder definition mapping for the primary and/or secondary page of a site section. If you establish the mapping in this way, then it replaces any mapping that may have existed at the site-wide (global) level. Please note that the section where you do this now uses different mapping from any other section where the same placeholder is used.

- At the placeholder level (using a parameter in the placeholder tag): You can also set a specific placeholder definition for a specific placeholder. You do this by adding the placeholderDefinitionDocName=[NAME] to the placeholder tag (in source view). If you establish the mapping here, then this overrides all section-level and site-wide (global) mappings. It also means that this template uses this definition everywhere it used. The template then always uses the specified definition regardless of where in the site it is used. Also note that the only way to change this is to modify the template in source view. This would be considered the least flexible way of specifying a definition mapping as it is hard-coded, but this method can be used if desired.

- As a catch-all (using Web site properties): You can set up a default placeholder definition that is used if none of the three other methods above apply. You do this by setting the Default Placeholder Definition property in the Web site properties category of a site.

You can also set up a default placeholder definition, which serves as a catch-all placeholder (if no other applies).

Placeholder definitions specify what content can go in a contribution region (as marked by a placeholder tag) and how this content is displayed, as well the actions available to contributors. For example, a placeholder may be set up to allow contributors to update the metadata of content displayed in the contribution region, or they may be allowed to switch the content of contribution regions. (Please note that region definitions control what kind of content contributors can switch to.)

Placeholder definitions also specify what region definitions, region templates, and subtemplates are available for the associated placeholder (that is, contribution region) on the web page. Take, for example, a placeholder definition that allows three region definitions: REGION_DEFINITION_1, REGION_DEFINITION_2, and REGION_DEFINITION_3.

Region definition 1 has three associated region templates: A, B, and C, with region template A being the default one. This means that region template A is applied to all content files (contributor data files or native documents) associated with region definition 1 unless a different region template was specifically set. You generally associate a region definition with a content file when you create that file, although you can always change this association on the content information page (see "Site Asset Storage").

2.11 Subtemplates

Subtemplates are the same as page templates, but do not have <HTML>, <HEAD>, and <BODY> sections. As such, they are essentially chunks of HTML code that can be inserted in page templates. Subtemplates may contain very simple HTML code, but they can also be quite complex, with their own scripts and the like. The code in a subtemplate is treated exactly as it would be when placed directly in a page template.

As shown in the site object hierarchy (Figure 2-4), subtemplates can only be placed within placeholders, and subtemplates may contain their own placeholder(s). Subtemplates are typically used as a method of dividing a placeholder (that is, contribution region) on a page template into further smaller, reusable areas with their own placeholders, as shown in Figure 2-12. A placeholder can contain a subtemplate that contains one of more other placeholders, each with their own subtemplate or region template.

Figure 2-12 Subtemplate in a Placeholder

Please note that a good site design does not necessarily need subtemplates, and many Web sites do not use them at all, since the addition of a subtemplate does mean that the designer has an additional type of site asset to manage.

Subtemplates can be used to help reduce the number of page templates used in a Web site. This would be done by creating one main page template that can be used as broadly as possible for ease of reuse, and then in certain cases using subtemplates to change a placeholder on the main page template into multiple placeholders using subtemplates. This further allows reusability. A site designer can create a large area with one placeholder, which can then be used and reused with a placeholder containing a subtemplate with multiple placeholders in different layouts.

2.12 Page Templates

Page templates define the layout and high-level look-and-feel of web pages, including the placement of contribution regions (that is, editable areas on the page), navigation aids (in the form of fragments) and site-wide images (banners and the like). They provide the framework within which site content is displayed.

Page templates consist of layout and formatting code, along with Site Studio tags to specify where placeholders go. As such, they are typically light-weight in that they only contain high-level references to where contribution regions go on the page; they do not specify anything about what goes in these regions, both in terms of content and visual presentation (see "Region Templates and Region Definitions"). Page templates typically include site-wide graphics, such as corporate banners or page layout images, and recurring, non-editable content, such as navigation aids or standard page content (footers and the like).

The number of page templates required for a Web site depends on the site complexity, but usually only a very limited number should be necessary. For example, it could be sufficient to use one page template for the home page, and another page template for all other pages. The variations of content displayed on the various Web site pages could then be handled using region templates (and region definitions) within the placeholders on the page templates. With fewer page templates, a Web site is easier to maintain. This does require more work up front; that is, more thought must be put into the design of a Web site, how the materials are laid out, and what information appears in which sections of the Web site, and so forth. This also means that the site designer should carefully consider what information contributors are allowed to change, and what should remain fixed.

Figure 2-13 shows a generic page template that is often used for the homepage of a Web site. It shows a banner image at the top, a navigation fragment on the left, a footer fragment at the bottom, and several small placeholders in the center, each of which representing some content. Placeholders do not delineate any page areas. They are no more than insertion points that specify the location of a contribution region. What goes in these regions and how it is presented is handled by region templates and region definitions. Site visitors can then click this content to see the content in full. This full content could be displayed in a page template that could potentially be used for all site pages other than the homepage. Figure 2-14 shows a generic example of such a page template. The template is basically same as for the homepage (Figure 2-13), but the content area is now a single placeholder to show page content in full.

Figure 2-13 Generic Page Template for the Home Page of a Web Site

Figure 2-14 Generic Page Template for All Other Pages of a Web Site

2.13 Contributor Data Files and Native Documents

The content of Site Studio Web sites is stored in either of two file types: contributor data files or native documents. These content files are stored on the content server, and they are the files that contributors interact with when adding or editing Web site content. You, as the site designer, decide which of these (or both) are used for a particular Web site.

The content files for a Web site (contributor data files or native documents) are initially selected or created by the designer or contributor, and modified by the contributor. Contributors may be able to switch the content file associated with a contribution region if the designer has specifically allowed this in the placeholder definition associated with that region.

When a web page displays site content in a contribution region, it displays the content through a region template and region definition, which define where and how each named part of a content file displays within the page. You can assign a unique contributor data file or native document to contribution regions, or assign the same file many times, depending on whether you want to reuse specific content on your site. You choose the name and metadata for the content file when you first create it and check it into the content server. The names that you use for content files may be useful when managing these files on your site. Also, the names that you choose may depend on how often you are reusing content. See "Planning and Naming Your Site Assets" for more information.

Contributor Data Files

Contributor data files are XML files that are created by Site Studio. Each contributor data file is associated with one (and only one) region definition that defines its 'content class' in terms of its constituent elements (see "Region Templates and Region Definitions"). For example, if a region definition comprises four elements called Title, Subtitle, Body_Text, and Image, then all contributor data files associated with that region definition contain these same four elements. Each element in the contributor data file can be edited in accordance with the element definition associated with that element in the region definition (see "Elements and Element Definitions"). The element definitions specify the editing options that are available to contributors when they edit an element in a contributor data file. Some elements may be set up to be plain text only with very limited formatting capability, while others might be WYSIWYG (What You See Is What You Get), which generally offers a much broader editing experience.

The content of contributor data files can easily be reused on a Web site; that is, it can be displayed in different locations on a site, either completely or partially (different elements), depending on where it is used. It is worth noting that when contributors edit a contributor data file, they see all its elements in the Contributor editor, even if only some elements are actually displayed in the contribution region being edited. The other elements may be used elsewhere on the Web site, so editing that information may affect other pages on the site.

Native Documents

Native documents are files that are created using familiar third-party applications such as Microsoft Word. They are converted to HTML format using Dynamic Converter so that they are viewable on the Web site. Dynamic Converter uses conversion rules and templates to decide how to convert a native document. Native documents are edited using their associated application (for example, Microsoft Word for '.doc' files).

The content of native documents can also be reused on a Web site, although native documents are generally not as flexible in their reusability as contributor data files. Judicious use of styles and other formatting features in Microsoft Word may overcome some reusability drawbacks of native documents. One important benefit of using native documents is that most contributors are already quite familiar with, say, Microsoft Word, which makes this application an easy and convenient editing environment for the site content.

2.14 Primary and Secondary Pages

The primary page of a site section is the page that is displayed when a visitor first enters that section. Sections in the site hierarchy usually have a primary page assigned to them, but this is not required. For example, a search results page, which you do not want users to browse to directly, may only have a secondary page. You assign a page template as the primary page of a site section.

The information on a primary page is statically linked. Contributors can change the contributor data file on the primary page using the Contributor editor, and native documents using their associated third-party application.

Secondary pages are optional for site sections, and they are typically used to dynamically present content on a Web site. A secondary page can have static content, but what makes secondary pages useful is their ability to have dynamically placed and replaceable content. As such, they are used to create multiple versions of the pages within a site section; they provide a different content view for a site section. Secondary pages allow you to handle large sites without needing to physically create thousands of pages.

A secondary page basically serves as the backdrop for content added to the site by a contributor. Secondary pages are required if you allow contributors to add new contributor data files or native documents (both of which amount to new web pages) to the Web site. These files are made available to the site when they are picked up by a dynamic list, a search, or the target of a link. Page templates can be configured as secondary pages.

You can create a site comprised entirely of primary pages, but then you must create sections with new primary pages in order for the site to grow. By using secondary pages, your site can grow on its own from additional content submitted by contributors, and you, the designer, do not have to do anything. Your site becomes much more scalable with secondary pages.

One common use of secondary pages is with dynamic lists of hyperlinked items (for example, press release titles, as shown in Figure 2-15), each of which, when clicked, opens in full on a secondary page. More specifically, the target of the link opens in the replaceable region on the secondary page of the same section (by default).

Figure 2-15 Dynamic List With Press Releases

3 Planning Your Web Site

Planning is key to building a successful Web site with Site Studio. Before you begin inserting text, graphics, and scripts into your page templates, you should ask “What is the function or role of the site?” Is it a department-level site, a company-wide site, an internal site, an external site? How many users will visit the site? How many users will contribute to the site? Will there be different security access levels for each contributor? Do you plan to replicate or publish the site? Is the site expected to grow over time?

These are all important questions to ask before you begin. We cannot predict your particular needs, but we can suggest some key points that you should consider before developing your site:

- "Why is Planning Important?"

- "Planning Your Site Hierarchy"

- "Planning Your Contribution Model"

- "Creating Your Site Assets"

3.1 Why is Planning Important?

Proper planning of the Web site helps determine how to maximize reusability of the Web site through appropriate use and reuse of page templates, subtemplates, and region templates.

It is important to understand that the more time spent on the planning process, the easier the Web site and the site assets are to create and manage. You might think that there is more time required to plan a managed Web site using Site Studio, but the result is much less time spent managing the assets.

Proper planning is vital to making the site easier to run. In the beginning stages, it might seem as if more time is being spent before any pages are complete compared to older methods of creating a Web site. But the results of time spent properly planning the Web site makes the construction of it through the site assets much easier, and the maintenance of the Web site, especially when making later changes when the Web site is live.

What Parts of the Site Will Be Reused?

When you consider the Web site, you should look at all content and all of the structure and consider what is reusable, and what should be used only once. When considering this, it could be thinking of simply the layout of the page, or it could be simply what data is displayed, or it could be a consideration of a certain piece of data displaying in a certain way.

Because there are so many ways of arranging and reusing the different parts of the site, it may be helpful to look at these examples of organization and reuse to think about while you consider your own Web site.

In a typical Web site, there is the navigation on the left, the banner graphic on top, and a large central area with the information on the page itself. We would expect that the banner and the navigation should be on all pages, so this would be placed on the page template itself. But the information in the middle will obviously be different from page to page. This is where the considerations are most important.

The way the information is organized is the most important consideration. When you look at one page, it may have objects arranged in one column, or in an array, or broken up with images. It's possible to arrange everything in one placeholder, but there is the other aspect, where you can create smaller sections, each with its own smaller contributor data file.

Consider a page on your Web site that would list open employment positions. You could create the page such that it is one placeholder, listing all internal positions and all external positions. Or you could create a subtemplate within that placeholder (which would then contain separate placeholders and region templates, and so forth), so that the external positions would be stored separately from the internal positions. Each could be maintained in a separate contributor data file, so that the external Web site would contain only the external announcements, and the internal Web site would contain both the contributor data file with external announcements and the one with internal announcements.

Another use would be where each department in the company could list their own job openings; then, on one central page, you could collect all of those individual openings and display them all. In these instances, you can use a subtemplate to easily manage the differing numbers of placeholders.

Other considerations for how you lay the data out on the page, and how to organize the placement of the data within the Web site, needs this kind of consideration on a page by page basis.

You should consider these questions: Would it be best to use one placeholder on the page template, then use a subtemplate to break that placeholder up into parts? Or would it be better to have a few more page templates to allow for different placeholder arrangements?

Another example would be an instance where you have a small piece of information that does not necessarily need a separate page, but you would definitely want to reuse. An example of this could be stockholder contact information, or possibly job application information, separate from typical corporate contact information. The information is not enough to necessarily warrant its own page.

In all of these cases, the page template would be the same. It would have the banner, the navigation, a footer, and then in the middle, the placeholder representing the area that can be replaced and filled with any information you need, structured exactly as you need it. It was the consideration of how to use a subtemplate to further use a placeholder or multiple placeholders within that template that enables you to keep the single look that you need for all pages.

It would also be possible to achieve this layout with different page templates on each page. Again, it depends on how you plan your site.

As you can see, the most important part of the site creation is to figure out how each portion of the Web site, both in terms of structure and content, is displayed. With Site Studio, the more time you invest in planning before you create, the less time you spend creating the hundreds and even thousands of pages your Web site delivers.

3.2 Planning Your Site Hierarchy

The site hierarchy is the framework of your Web site. You should give yourself plenty of time to plan the hierarchy before you start creating web pages. The site hierarchy not only helps you organize and manage content on your site, but it is also used by Site Studio to automate certain tasks.

How Deep Should the Hierarchy Be?

A deep hierarchy places information at multiple levels where information is heavily categorized. This works well for large organizations or any organization that anticipates growth on the Web site.

When planning the Web site, a lot of care should be taken in considering the hierarchy of the web pages within the site. The Web site hierarchy can be as deep as you want, and as deep as you want. You can create as many different sections from the home page as needed, and a section can contain as many sections as needed as well. However, the thing that should be kept in mind while designing the hierarchy is that while the structure can be as wide as needed (that is, sections can be nested to any depth), that this can create unwieldy URLs. The wider a section is nested in a Web site, then the longer the URL is to retrieve that information. Usually this is a trivial consideration, but for some designers this can be a major point.

Each section listed in the site hierarchy can have a primary page, and a secondary page. Since secondary pages are the pages that have replaceable content, the secondary pages are used to create multiple versions of the pages within a section. The primary page within a section is the page that opens for that section, it could be considered the landing page for that section.

How Will The User Navigate the Site?

While you use your site hierarchy to manage your site, visitors use your hierarchy to browse to and locate content. In Site Studio, when you add a navigation fragment to a page template, the fragment reads your site hierarchy and generates links that comprise the overall site navigation. You can easily add, remove, and rename sections of your site, and these changes are seen in your site navigation. You should think carefully about the visitor's experience as you construct this hierarchy.

How Should the Sections Be Named?

Your site hierarchy has individual sections with names such as Products, Services, and About Us. These names are important. They not only help you organize content on your site, but they display in the navigation on the site, where visitors see it. It is a good idea to revisit these names regularly to ensure that they reflect the content of the sections they represent.

Another thing to consider as you assemble your site hierarchy is the Web site address that contributors and site visitors see in their web browser address bar. By default, Site Studio uses the names (labels) that you give to the sections in your site hierarchy.

You can override these values, if you like, by specifying a different path name and page name for each section. It is best to plan this ahead of time to minimize any late changes to the site address or paths used in the address, which could result in broken links or missing shortcuts for contributors and site visitors.

How Reusable Should The Page Templates Be?

As you plan your site, you can create new page templates for each section, or you can reuse page templates that are already being used in other sections. When you design to use a small number of page templates, you then have fewer assets to manage, which makes the entire Web site easier to manage.

By reusing page templates, you can maintain the look and feel of your Web site in one or just a handful of page templates, and the changes are seen immediately across the site.

By creating new and unique page templates in each section, you might have more flexibility in the design of the site layout as a whole. You can create a unique design or slightly modify a different page template to accommodate the content that display there. However, if you make significant global changes to the site, then you have to modify multiple page templates. This might become a repetitive task that lends itself to mistakes and inconsistency.

If you choose multiple page templates, you should try to reuse fragments with referenced snippets as much as possible so that you can make global changes to just one or a handful of fragments.

However, through thoughtful use of subtemplates with the placeholders, it is typically possible to reduce the number of page templates.

Should There Be Both Primary and Secondary Pages?

There are several ways to handle page templates. You can assign one primary page and one secondary page for every section of your site hierarchy.

The primary page is the web page that users see when they go to that section on the Web site (similar to the default page on a conventional Web site). The information on the page is statically linked. Contributors can change the contributor data file or the native document on the primary page, or the information in the data file through the contributor interface.

The secondary page is a page that can have its content dynamically placed. A secondary page can have static content, but what makes secondary pages useful is their ability to have dynamically-placed content.

You can create a site comprised entirely of primary pages, but then you'll have to create new sections with new primary pages in order for the site to grow. By using secondary pages, your site can grow on its own from additional content submitted by contributors, and you, the designer, do not have to do anything. Your site becomes much more scalable with secondary pages.

Primary and secondary pages can have the same page template. The page template is not related to whether the page using the template is primary or secondary.

How Will Content Be Reused?

You can share and reuse contributor data files and native documents across a single Web site and even multiple Web sites in the content server. When you add these items to your site, you specify a specific location, or multiple locations by reusing associated site assets, where you would like them to appear.

You can even add content to your site that is not currently associated with any Web site in the content server. You can show the same document on different sites, each with its own look and feel, without having to create multiple versions of that same document.

If you choose to do this, however, you must ensure that the content is appropriate for the Web site and for public viewing. Workflows are good to implement to ensure this. You also must ensure that you have a secondary page with a replaceable region template in each section where the content appears.

Will A Manager Be Necessary?

You can create and manage the site hierarchy yourself, or you can hand this responsibility over to a site manager. The site manager can create sections, modify sections, and more.

These changes can significantly change the appearance and behavior of the site. You should think about these changes and how they affect the structure of the site, workflow, replication, the role of contributors, and much more.

3.3 Planning Your Contribution Model

As you plan the site hierarchy and prepare the assets for the Web site, you must think about your contribution model. That is, how content gets placed on the site by users (contributors and managers).

How Much of the Site Will be Provided by the User?

There are some things that the designer must add to the site, such as the background color, positioning devices (HTML tables or CSS), site navigation, and custom scripts. But much of the content for each web page (that is, the actual information on the page) can be created and edited by a contributor.

To really harness the power of Site Studio, you should open up as much of the Web site as possible to these users. This way, your Web site can be continuously updated without the bottlenecks or delays typically associated with a Web site.

How Much Control Will the User Have?

On every page template, you can have one large contribution region or several small contribution regions. Within a region template, you can have one or several elements, each one appearing as a field where users (contributors) add and edit content.

There are different types of elements that can be used for specific purposes, like adding and editing text, graphics, and updating lists. You can turn on or off certain formatting attributes, such as the choice of typeface, font size, images, tables, and custom properties. These choices depend on how much control you want the contributor to have over a given web page. You can also enforce what content is added using the validation feature or your own validation scripts.

Will There Be Different Security Access for Each User?

You should know your users, their role in the organization, and their knowledge of web publishing before you give them access to the site. You may want to provide equal access to all contribution regions on the Web site for all users, or you may want to limit access for some and grant full access to others.

For example, you may want to provide full access to the entire web page for members of the marketing department and access to only a portion of that page to all other departments. To do this, you would set up different users on the content server, assign a different contributor data file or native document to each region, and assign unique security metadata (using the metadata framework on the content server) to those files.

As a result, only the files that a particular contributor has permission to edit will display a contribution graphic (Figure 3-1) on them on the web page when in contribution mode.

Figure 3-1 Contribution Graphic

Sections of the Web site can also be marked so that only certain users can view them. This is handled in the section settings within the Web site hierarchy. After the section has limited access, the section is available for viewing (and editing, if you want) to only those users that you want to have access.

Will Contributors Submit Native Documents?

In addition to adding and editing content stored in Site Studio data files, contributors can also add native documents (created from applications like Microsoft Word, Excel, or PowerPoint) to the site. These documents can be converted into web-viewable renditions using dynamic converter component on the content server.

Contributors can add new and existing native documents directly to the Web site (for example, by assigning one to a region, using the link wizard, or adding one to a dynamic list).

If you allow contributors to submit native documents to the Web site (and again, you control this in a contribution region, an element, and a list fragment), you should educate them on how they should use the native document and any style guidelines you may be enforcing.

How Will the Contribution Process Be Coordinated?

If you are the designer, manager, and contributor of your Web site, you know when and where the site must be updated. If, as the designer, you are working with a single contributor or manager, you must communicate the required updates for the site. Specifically, you should inform them of certain changes to the site. The contributor, however, may also alert you when content has been added.

If you are working with multiple users, communication can quickly become complex. You must include some kind of communication process between users. One solution is to introduce a formal review process using workflows. This means that various persons review and approve site changes before they become live.

3.4 Planning and Naming Your Site Assets

Site assets in Site Studio are intended to be reused. Since the asset itself can be used in not only different areas of a Web site, but also in different Web sites that you are designing, the naming of each asset is important. With a good naming scheme, assets can be more easily managed and more easily deployed in one or many areas of a Web site, and one or many Web sites.

The best way to name an asset is to describe what it does and how it functions, rather than by using a name based on where an asset is used in a Web site.

The first thought of many designers is to put the name of the Web site in the name of each asset. This would group them when listing the contents of the content server. But the difficulty here is when you run multiple Web sites, since all of the assets are reusable. Rather than create an entirely new set of assets and definitions for a certain section in your Web site, you can easily import the other assets you've already created. In doing so, though, when the assets have the name of the other Web site in the name, this can cause some issues of continuity, understanding, and even some confusion regarding why some assets are present.

Names of the assets should also avoid the place of the asset within the Web site as you may run into some issues when reusing assets. For example, by naming a page template originally intended to be the primary page template as primary_template, there may be some confusion when that same template also ends up being used on the secondary pages. Proper planning would have eliminated this issue, giving the template a name such as page_template_with_2_placeholders.

Consider these two different methods of naming the site assets in your project:

Naming convention with little planning toward maintenance:

Naming convention with considered planning toward maintenance

placeholder_def_1
p_def_2

default_definition

front_page_template

subtemplate_up

element_title

region_replace

element_def_WYSIWYG_fulledit
element_def_imageonly_minedit

placeholderdef_subtemplate_newslist

regiondef_customform

regiontemplate_title_and_body

pagetemplate_home

pagetemplate_errorhandler

Future updates are much easier to handle when the assets are named to describe what they do, allowing you to place them as needed. This also means you do not have to look in all managed Web sites for an asset that you have already created.

3.5 Creating Your Site Assets

After the Web site has been planned, the assets used to construct the Web site should be created. For the most efficient use, it is recommended that you create these assets in a particular order.

The most efficient method of asset creation for most Web sites is to build the assets from the bottom up, starting with your element definitions.

- "Step One: Create Your Element Definitions"

- "Step Two: Create Your Region Definitions"

- "Step Three: Create Your Region Templates"

- "Step Four: Create Your Subtemplates"

- "Step Five: Create Your Placeholder Definitions"

- "Step Six: Create Your Page Templates"

It is not required that you create the assets in this order. However, your Web site can be quickly and efficiently assembled if you follow this order.

3.5.1 Step One: Create Your Element Definitions

The most efficient assets to define first are the elements. Elements are the assets that define the editing interface that the contributor uses. The specific use of each one is handled through element definitions. By creating an element definition, you are defining how the contributors work with the data files by defining the editing regions and the toolbars accessible to the contributors.

In the element definition you can control exactly which editing features are available to the contributor in the toolbar. For instance, you might not want the contributor to be able to change the font size or color, but still be able to use bold and italics. Generally you define at least one of each kind of element (WYSIWYG, text only, image only, static list, dynamic list, and custom) and usually, you define two or more of each type of element to allow for the different toolbars in Contributor.

The element definition is used to control the toolbar that the contributors can access to edit the pages. However, it might be that you want to have several different definitions for each element so that you can have multiple options of toolbars for the contributors, rather than one or two. It is important to consider the role of the contributor and how much they contribute on different pages.

It is highly recommended that you name the element definitions carefully, as naming the elements with respect to place on the page or with the name of the site in them can make reusing them less intuitive. It is not recommended that you name the element in terms of its place on the page, within the Web site, or even by using the name in the Web site within the element definition. The optimal method for naming an element definition is to list a relative amount of access in the toolbar, such as element_WYSIWYG_fulledit or element_text_undo_only.

Notice that the element definitions were named starting with the word element. That is to make all elements appear together when searching for them in the content server. Using other naming conventions such as including the name of the Web site would also group the assets in the web server, but this would make the definitions less intuitive to manage if you use the same definitions for multiple Web sites.

3.5.2 Step Two: Create Your Region Definitions

You should create region definitions before you create region templates. A definition (region definition, placeholder definition, element definition) controls which data is displayed and how the contributor interacts with the data. The template (region template, subtemplate) control how the data is displayed. The region definition, specifically, controls which elements (WYSIWYG, Image only, and so forth) open in Contributor. The region template is used to arrange the placement of the elements and how that particular data is displayed on the web page.

As you create a region template, you are asked to associate it with a region definition. If the definition is not already defined, the region template is not easily associated with the definition afterward.

The typical region definition contains multiple elements, and various combinations of these elements are used on several different region templates. That is, the region definitions are as broad and encompassing as possible. This allows multiple region templates to access the same grouping of elements (but it does not have to be the same data file) and arranging them in different ways.

Because the region definitions limit the availability of elements in the contribution model, it is especially important to follow good naming conventions for region definitions. This helps you sort out which definitions are best suited for the different region templates you create.

3.5.3 Step Three: Create Your Region Templates

Region templates are the assets that format the data files into HTML. You use region templates to place the content, such as text, images, or other simple items, that would not be inside of an element, and the elements. The region templates are used to arrange the elements (limited by the region definition) into the layout desired to be reused as you see fit in the different places in your Web site.

The region template has available to it only those elements that have element definitions listed in the region definition for the template. However, the region template does not have to use all elements listed in the definition. This allows for a great deal of variety in the different templates available.

It is likely that region templates are the largest number of assets you create for the Web site. Because of this, the naming convention you use in creating the region templates is important. The name should help define what the template does, not where on the page it is used or where in the Web site. A name such as regtem_titlebodyview or rt_bodynoimage would likely be a more useful name when maintaining the site than would, say regiontemplate14 or RT_SupportForum.

Since region templates can contain HTML and images and other assets (for example, a region template-specific CSS) that are not part of the data file that is passed through the elements, the templates can be used to incorporate some information and text that is not editable by the contributor. However, it is important to understand that any of that information is not part of the contributor data file that the contributor edits. This means that as you reuse a region template, the data associated with it displays in the same manner regardless of what data is associated with that region template. It also means that the designer is the only person who would be able to modify that particular data. The contributor would be able to create and edit any data that is assigned to the elements in the region template through the placeholder, but anything that is placed outside of the elements, but still within the region template, would be static.

3.5.4 Step Four: Create Your Subtemplates

Subtemplates are major portions of HTML that can contain placeholders. This makes them very useful as a way to reduce several page templates while still maintaining several different ways the pages in the Web site can appear.

Subtemplates can only appear in a placeholder. Subtemplates can only contain a placeholder, or static content such as HTML or an image. A subtemplate can also reference a CSS file.

Is a Subtemplate Necessary for the Site?

One of the benefits of using a subtemplate is that you can reduce the number of page templates used in a Web site. Through a subtemplate, you can have the same page template used for both primary and secondary pages.

This is one reason why planning is essential. While a subtemplate can reduce the number of page templates, it also means that you have a subtemplate to manage for the Web site. Fewer page templates means that site-wide changes are easier to make. Subtemplates can also add a level of static information because you can add HTML, images, and other similar static site assets to a page that you may want placed on a certain number of pages (such as the secondary pages) that would otherwise have to be managed separately from the subtemplate.

The subtemplate can also help you place multiple placeholders within a single placeholder. Since a placeholder can contain a subtemplate, and a subtemplate can contain a placeholders, then it could be that you want the subtemplate present for future Web site expansion that is still to be determined.

3.5.5 Step Five: Create Your Placeholder Definitions

Placeholder definitions are what connect each placeholder to the content and other assets associated with that placeholder to display.

How Will The Placeholder Function On The Page?

The placeholder, not to be confused with the placeholder definition, is simply a mark on the page in the application to identify where there is a contribution region (that is, editable area) on the web page. Placeholders are simply conceptual boundaries. The actual amount of space that a placeholder uses on a web page is determined by the size of the content placed in it.

The data associated with the placeholder depends on which page the placeholder is on, which happens after the site structure is complete and you begin to place content in the sections of the Web site.

It is the placeholder definition that determines how the placeholder functions, and what the placeholder contains. This means that you should view the placeholder as an available section for you to use and reuse content in broad areas. It is common to have a page template, for instance, with only the navigation and the header image and nothing but a placeholder in between. This placeholder would then be easily replaced on any number of pages with the content specific to those pages. The content can be broken down into smaller placeholders if your design planning has led you to create a site based on a minimal number of page templates and using multiple placeholders and subtemplates in different ways.

What Will The Placeholder Definition Control?

The placeholder is little more than a tag that is meant to define an area on the page where the content is shown. The placeholder definition lists which region definitions (and their associated region templates) and which subtemplates are available to pass information through.

You can also control other details on a placeholder-by-placeholder basis through the placeholder definition. Some of these items include workflow, whether the contributor can edit the data displayed through the placeholder, whether the contributor can edit the metadata, ability to view Web site usage reports, and the ability to view content tracker reports.

3.5.6 Step Six: Create Your Page Templates

A large number of Web sites can be reduced to two simple page templates: the home page, and then all other pages. It is not uncommon for a Web site to have a home page that is distinct in terms of layout and design compared to the other pages in the Web site.

It may be the case that there are multiple templates for your site. It is also possible to make an entire Web site work with one page template. If you do design the Web site with several page templates, you should possibly consider the use of subtemplates to reduce the number of page templates. Fewer page templates on a Web site makes site-wide changes much easier.

Will Primary and Secondary Pages Require Different Templates?

Primary and secondary pages can both use the same page templates. However, since secondary pages are the only pages that can have dynamically placed content, you should consider the effect on how you view your page templates (and even your placeholders and placeholder definitions) with respect to the advantages of dynamically placed content.

A secondary page serves as the backdrop for content added to the site by a contributor. Secondary pages are required if you allow contributors to add contributor data files or native documents (both of which amount to new web pages) to the Web site. These files are made available to the site when they are picked up by a dynamic list, a search, or the target of a link.

It may be that you first build your site with just primary pages, saving secondary pages until after you set up contribution regions on the primary pages and know exactly what type of content contributors submit to the site. Then, you could add the secondary pages to handle this content.

Regardless of whether you use the same or different page templates for the primary and secondary pages in your Web site, it is important that you name the page templates appropriately. This is the same for all other site assets in Site Studio. Say, a page template is used for both the primary and secondary pages. If the name of that page template was based on where it was initially placed in the site, the template name could lead to confusion when the site is expanded and the page template is being reused for secondary pages as well.

The most efficient naming of site assets, including page templates, should be based on how the page template is used. Naming conventions based on where the asset is used in a Web site (for instance, page_template_primarypage) or based on in the order of creation (for instance, pagetemplate3) can make the assets harder to manage.

4 Building a Site Studio Web Site Tutorial

This section describes the steps for creating a Site Studio Web site in the JDeveloper environment. This tutorial demonstrates how to create a simple Web site with navigation. It covers the following topics:

- "Creating a Site Studio Project and Connection"

- "Creating a Sample Web Site"

- "Creating Sidebar Links"

- "Creating A Dynamic Conversion Page"

4.1 Creating a Site Studio Project and Connection

These are the steps for creating a Site Studio project and content server connection:

- "Step 1: Creating a New Application and Project"

- "Step 2: Creating a Content Server Connection"

- "Step 3: Adding the Connection to the Project"

4.1.1 Step 1: Creating a New Application and Project

Follow these steps to create a new application and new site studio project:

1. From the JDeveloper main menu, select File, and then New.
The New Gallery opens.

2. In the Categories list, select General, and then Applications.

3. In the Items list, select Generic Application.

4. Click OK.
The Create Generic Application wizard appears.

5. In the Name Your Application step:

- For Application Name, enter SiteStudioDemo.

- For Application Package Prefix, enter demo.SiteStudioDemo.

6. Click Next.

7. In the Name Your Project step:

- For Project Name, enter SiteStudioDemo.

- From the Available Technologies list, select Site Studio Technology and click the shuttle button to transfer the selection to the Selected Technologies list.

8. Click Finish.

9. From the JDeveloper main menu, select File, and then Save All.

4.1.2 Step 2: Creating a Content Server Connection

Follow these steps to create a connection to the content server and add it to your Site Studio project:

1. If the Application Navigator is not already open, select View, and then Application Navigator.

2. Select the Application Resources panel.

3. Right-click Connections, select New Connection, and then Site Studio.

4. In the Create Content Server Connection dialog:

- Application Resources: If not already selected, enable this option.

- Connection Name: Enter the hostname of your content server (for example, developmentserver2 or developmentserver2.mycompany.com).

- Design Time URL: This field is auto-filled based on the connection name you provided. If you are not using default settings on your server you may need to edit this field.

- Run Time URL: This field is auto-filled based on the connection name you provided. If you are not using default settings on your server you may need to edit this field.

- Specify credentials for this JDeveloper session: Enable this option.

- Username: Enter your content server administrative username.

- Password: Enter your content server administrative password.

5. Click Test Connection and Login.
If the connection fails, verify that you have the correct connection name and URL for the content server and have supplied valid login credentials.

6. Click OK.

4.1.3 Step 3: Adding the Connection to the Project

Follow these steps to add a content server connection to your Site Studio project.

1. In the Application Navigator, select the Applications Resources panel.

2. Expand Connections, and then expand Site Studio.

3. Right-click the new content server connection, and select Add to Project.

4. In the Select Project dialog, select SiteStudioDemo.jpr from the list.

5. Click OK.

6. From the JDeveloper main menu, select File, and then Save All.

4.2 Creating a Sample Web Site

These are the steps for creating a sample Web site:

- "Step 1: Creating a New Web Site in the Content Server"

- "Step 2: Specifying User Credentials for Contribution Mode"

- "Step 3: Editing the Web Application Deployment Descriptor"

- "Step 4: Creating the Home Page"

- "Step 5: Associating the Page Template with the Site"

- "Step 6: Running the Site and Viewing the Home Page"

- "Step 7: Creating Site Fragments"

- "Step 8: Creating the Element Definitions"

- "Step 9: Creating a Region Definition"

- "Step 10: Creating a Region Template"

- "Step 11: Creating a Placeholder Definition"

- "Step 12: Adding a Placeholder to the Home Page"

- "Step 13: Assigning Content to the Placeholder"

4.2.1 Step 1: Creating a New Web Site in the Content Server

Follow these steps to create a new Web site in the content server.

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Web Content, and then expand WEB-INF.

4. Right-click wcm-config.xml and select Open.

5. Select the Server tab, and then expand Sites.

6. Click the Create Sites button.

7. In the Create New Site dialog, enter SiteStudioDemo for both the Name and ID fields.

8. Click OK.

9. From the main menu, select File, and then Save All.

4.2.2 Step 2: Specifying User Credentials for Contribution Mode

Follow these steps to specify user credentials for contribution mode:

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Web Content, and then expand WEB-INF.

4. Right-click weblogic.xml and select Open.

5. Select Security and expand Security Role Assignments.

6. Click the Create Security Role Assignment button.

7. For Role Name, enter WCMContributor .

8. In the Principal section, click the Create Principal Name button.
For the newly created security role name add a principle (a user) that matches a principle that exists in your content server. For this tutorial we will use the weblogic principle.

9. For Principal Name, enter weblogic.

10. From the main menu, select File, and then Save All.

4.2.3 Step 3: Editing the Web Application Deployment Descriptor

Follow these steps to edit the Web application to process JSPF files:

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Web Content, and then expand WEB-INF.

4. Right-click web.xml and select Open.

5. Select Pages and expand the JSP Property Group.

6. Click the Create JSP Property Group button.

7. In the new JSP Property Group, select the General tab:

- For Display Name, enter Fragments.

- For Page Encoding, enter UTF-8.

- Enable the Is XML option.

8. Select the URL Patterns tab.

9. Click the Create URL Pattern button.

10. Enter *.jspf as a new URL pattern.

11. From the main menu, select File, and then Save All.

4.2.4 Step 4: Creating the Home Page

Follow these steps to create a simple home page for your application:

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Site Files, and then expand templates.

4. Right-click page and select New.

5. In the New Gallery dialog, expand Web Tier, and select JSP.

6. Select JSP in the Items section.

7. Click OK.

8. In the Create JSP dialog:

- For File Name, enter home.jspx.

- Enable the Create as XML Document option.

- Enable the Register Site File option.

- For Asset Type, select Page Template from the list.

- For Site File ID, enter ssd-home-pt.

- For Description, enter Homepage for the SiteStudioDemo site.

9. Click OK.

10. The new page template opens in the editor. Select the Source tab.

11. The page template should have content similar to this:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
doctype-system="http://www.w3.org/TR/html4/loose.dtd" doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>SiteStudioDemo Site</title>
<link type="text/css" rel="stylesheet"
href="../wcm/support/css/template.css"/>
</head>
<body>
<jsp:include page="/wcm/templates/fragments/header.jspf"/>
<div id="container">
<jsp:include page="/wcm/templates/fragments/menu.jspf"/>
<jsp:include page="/wcm/templates/fragments/sidebar.jspf"/>
<!--
Add content below.
-->
<jsp:include page="/wcm/templates/fragments/footer.jspf"/>
</div>
</body>
</html>
</jsp:root>

4.2.5 Step 5: Associating the Page Template with the Site

Follow these steps to associate the newly created home.jspx page template with your SiteStudioDemo site.

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Web Content, then WEB-INF, and then sites.

4. Right-click SiteStudioDemo.xml and select Open.
The Site Structure editor displays.

5. Right-click Home and select Select Primary Page Template.
The Select a Page Template dialog displays.

6. Select the SiteStudioDemo-home page template.

7. Click OK.

4.2.6 Step 6: Running the Site and Viewing the Home Page

Followed these steps to view the Home page:

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Web Content.

4. Right-click startSiteStudioDemo.jspx and select Run.

5. The integrated WebLogic Server launches and displays startup information in the Log panel. After the application has started, a browser window will open and display the SiteStudioDemo home page.

4.2.7 Step 7: Creating Site Fragments

Follow these steps to add JSP segments for the header, footer, sidebar, and menu:

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Site Files.

4. Right-click Templates and select New.
The New Gallery dialog displays.

5. From the Categories list, select All Items.

6. From the Items list, select Folder (General).

7. Click OK.
The Create Folder dialog displays.

8. For Folder Name, enter fragments.

9. Click OK.

Create a JSP Segment (Header)

10. Right-click the new fragment folder and select New.
The New Gallery dialog displays.

11. From the Categories list, expand Web Tier and select JSP.

12. From the Items list, select JSP Segment.

13. Click OK.
The Create JSP Segment dialog displays.

14. For File Name, enter header.jspf.

15. Click OK.

16. Right-click the header.jspf page and select Open.

17. Select the Source tab.

18. Add the following content:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<div id="top">
<b>
<a href="#">SiteStudioDemo Demo</a>
</b>
</div>
</jsp:root>

Create a Second JSP Segment (Footer)

1. Right-click the new fragment folder and select New.
The New Gallery dialog displays.

2. From the Categories list, expand Web Tier and select JSP.

3. From the Items list, select JSP Segment.

4. Click OK.
The Create JSP Segment dialog displays.

5. For File Name, enter footer.jspf.

6. Click OK.

7. Right-click the footer.jspf page and select Open.

8. Select the Source tab.

9. Add the following content:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<div id="footer">
<p align="center">
Copyright © 2010 | SiteStudioDemo
</p>
</div>
</jsp:root>

Create a Third JSP Segment (Sidebar)

1. Right-click the new fragment folder and select New.
The New Gallery dialog displays.

2. From the Categories list, expand Web Tier and select JSP.

3. From the Items list, select JSP Segment.

4. Click OK.
The Create JSP Segment dialog displays.

5. For File Name, enter sidebar.jspf.

6. Click OK.

7. Right-click the sidebar.jspf page and select Open.

8. Select the Source tab.

9. Add the following content:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<div id="sidebar">
<h1 class="first">The Sidebar</h1>
<p>
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
In sit amet lacus sed lacus egestas fringilla eu sit amet leo.
In hac habitasse platea dictumst.
</p>
<h1>Linkroll</h1>
<ul class="linkroll">
<li>
<a href="#">Link 1</a>
</li>
<li>
<a href="#">Link 2</a>
</li>
<li>
<a href="#">Link 3</a>
</li>
<li>
<a href="#">Link 4</a>
</li>
</ul>
</div>
</jsp:root>

Create a Fourth JSP Segment (Menu)

1. Right-click the new fragment folder and select New.
The New Gallery dialog displays.

2. From the Categories list, expand Web Tier and select JSP.

3. From the Items list, select JSP Segment.

4. Click OK.
The Create JSP Segment dialog displays.

5. For File Name, enter menu.jspf.

6. Click OK.

7. Right-click the menu.jspf page and select Open.

8. Select the Source tab.

9. Add the following content:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:fn="http://java.sun.com/jsp/jstl/functions">
<div id="menu">
<ul id="nav">
<li>
<wcm:url var="root" type="node"
url="${wcmContext.project.structure.rootSection.ID}"/>
<a href="${root}">
${wcmContext.project.structure.rootSection.properties.label}
</a>   </li>
<c:set var="sections"
value="${wcmContext.project.structure.rootSection.activeChildren}"/>

<!-- Iterate through the site structure nodes and add them to the menu -->   <c:forEach var="section" items="${sections}">
<wcm:url var="sectionUrl" type="node" url="${section.ID}"/>
<li>
<a title="${section.properties.label}" href="${sectionUrl}">
<em>
${fn:substring(section.properties.label, 0, 1)}
</em>
${fn:substring(section.properties.label, 1, -1)}
</a>
</li>
</c:forEach>
</ul>
<br class="clear"/>
</div>
</jsp:root>

4.2.8 Step 8: Creating the Element Definitions

Follow these steps to create two element definition files in the content server.

1. From the main menu, select View, then Site Studio, and then Site Assets.

2. From the Project drop-down list (top left), select the SiteStudioDemo project.
Note: If your project is not listed, it means you are not logged in to your connection (from the Application Resources panel, expand Connections, then Site Studio, right-click the connection, and select Login.)

3. From the Asset Type drop-down list (top right), select Element Definition.

4. Click the Create New Asset Type button and select New Plain Text Element Definition.

5. For both Title and Content ID, enter ssd-plaintext-ed.

6. Click the Create New Asset Type button again and select New WYSIWYG Element Definition.

7. For both Title and Content ID, enter ssd-wysiwyg-ed.

4.2.9 Step 9: Creating a Region Definition

Follow these steps to create a region definition:

1. From the Asset Type drop-down list (top right), select Region Definition.

2. Click the Create New Asset Type button and select New Region Definition.

3. For both Title and Content ID, enter ssd-content-rd.

4. Right-click the ssd-content_rd asset and select Edit.

5. Click Add.

6. In the Element Instance dialog:

- For both Name and Label, enter content.

- For location, click Browse button and select the ssd-plaintext-ed element definition.

7. Click OK.

8. Click Add.

9. In the Element Instance dialog:

- For both Name and Label, enter content.

- For location, click Browse button and select the ssd-wysiwyg-ed element definition.

10. Click OK.

11. Save the ssd-content-rd file and check it in.

4.2.10 Step 10: Creating a Region Template

Follow these steps to create a region template that uses a region definition file.

1. In the Application Navigator, select the Projects panel.

2. Expand your Site Studio project (SiteStudioDemo).

3. Expand Site Files then Templates.

4. Right-click region and select New.
The New Gallery dialog displays.

5. From the Categories list, expand Web Tier and select JSP.

6. From the Items list, select JSP.

7. Click OK

8. In the Create JSP dialog:

- For File Name, enter content.jspx.

- Select the Create as XML Document option.

- Select the Register Site File option.

- Select Region Template from the Asset Type drop-down list.

- For Site File ID, enter ssd-content-rt.

- For Description, enter Content Region Template.

- For Region Definition, click Browse and select the ssd-content-rd region definition.

9. Click OK.

10. The new content.jspx file should have content similar to this:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm">
<wcm:dataFile var="dataFile"/>
<div id="content">
<h1><a href="#">${dataFile.title}</a></h1>
<p>${dataFile.content}</p>
</div>
</jsp:root>

4.2.11 Step 11: Creating a Placeholder Definition

Follow these steps to create a placeholder definition that uses the new region template and new region definition:

1. From the Asset Type drop-down list (top right), select Placeholder Definition.

2. Click the Create New Asset Type button and select New Placeholder Definition.

3. For both Title and Content ID, enter ssd-content-phd.

4. Right-click the ssd-content-phd asset and select Edit.

5. For the Region Definition table, click Add and enter ssd-content-rd.

6. For the Region Template table, click Add and enter ssd-content-rt.

7. Select all the Allowed Actions options.

8. Save, check-in, and close the Placeholder Definition.

4.2.12 Step 12: Adding a Placeholder to the Home Page

Follow these steps to add a placeholder to home.jspx:

1. From the main menu, select View, and then Component Palette.

2. On the Component Palette, select Site Studio from the drop-down list.

3. Drag the Placeholder tag below the Add Content Below comment.

4. In the Insert Placeholder dialog:

- For Name, enter content.

- Enable the Add Name to Placeholder Definition Mappings option.

- Select SiteStudioDemo from the drop-down list.

5. Expand your Site Studio project (SiteStudioDemo).

6. Expand Web Content, then WEB-INF, and then sites.

7. Right-click SiteStudioDemo.xml and select Open.
The Site Structure editor displays.

8. Expand the Web Site (SiteStudioDemo) node.

9. Click the Switch Placeholder Definition Role value, and select the admin security role from the drop-down list.

10. Click the Design Mode Role value, and select the admin security role from the drop-down list.

11. Click the Placeholder Definition Mappings button.

12. From the list, select content and click Edit.
The Edit Placeholder Definition Mapping dialog displays.

13. For Primary Definition ID, click Search.

14. Select ssd-content-phd and click OK.

15. Click OK again.

4.2.13 Step 13: Assigning Content to the Placeholder

Follow these steps to enter contribution mode and add content to the placeholder on the homepage:

1. Expand your Site Studio project (SiteStudioDemo) and expand Web Content.

2. Right-click startSiteStudioDemo.jspx and select Run.

3. Once the application is loaded, use Ctrl+Shift+F5 to enter contribution mode.

4. Click the Assign Content button on the content placeholder.

5. From Switch Content, select New Contributor Data File.

6. Click Next.

7. In the check-in content page:

- For Content ID, enter ssd-home-pt-df.

- For Web Sites, make sure that SiteStudioDemo is selected (this should be done automatically).

- For Region Definition, make sure that ssd-content-rd is selected (this should be done automatically.).

8. Click Finish.

9. Click the Edit Region Content button for the content placeholder.

10. For Title, enter Introduction.

11. In the content editor add some text.

12. Click Save and Close.

13. Exit contribution mode using Ctrl+Shift+F5.

4.3 Creating Sidebar Links

This section builds on the previous sections. Follow these steps to create a static placeholder and display several links on the site sidebar:

- "Step 1: Creating a Static List Element Definition"

- "Step 2: Creating a Sidebar Region Definition"

- "Step 3: Creating Static List Data File"

- "Step 4: Creating a Region Template"

- "Step 5: Updating the Sidebar Fragment"

- "Step 6: Creating a Sidebar Content Region Definition"

- "Step 7: Creating a Sidebar Content Region Template"

- "Step 8: Creating a Sidebar Content Placeholder Definition"

- "Step 9: Adding a Sidebar Placeholder Mapping to the Site"

- "Step 10: Assigning Content to the Sidebar"

4.3.1 Step 1: Creating a Static List Element Definition

Follow these steps to create a static list element definition:

1. From the main menu, select View, then Site Studio, and then Site Assets.

2. From the Project drop-down list (top left), select the SiteStudioDemo project.

3. From the Asset Type drop-down list (top right), select Element Definition.

4. Click the Create New Asset Type button and select New Static List Element Definition.

5. For both Title and Content ID, enter ssd-links-staticlist-ed.

6. Right-click the ssd-links-rd asset and select Edit.

7. Click Elements and add two elements.

8. First Element:

- For both Name and Label, enter label.

- For Location, click Browse button and select the ssd-plaintext-ed element definition.

9. Click OK.

10. Second Element:

- For both Name and Label, enter url.

- For Location, click Browse button and select the ssd-plaintext-ed element definition

11. Click OK and then click OK again.

12. From the main menu, select File then Save All.

4.3.2 Step 2: Creating a Sidebar Region Definition

Follow these steps to create a sidebar region definition:

1. From the Asset Type drop-down list (top right), select Region Definition.

2. Click the Create New Asset Type button and select New Region Definition.

3. For both Title and Content ID, enter ssd-links-rd.

4. Right-click the ssd-links-rd asset and select Edit.

5. Click Add and enter these values in the Element Instance dialog:

- For both Name and Label, enter links.

- For Location, click Browse button and select the ssd-links-staticlist-ed element definition.

6. Click OK.

7. Save the ssd-links-rd file and check it in.

4.3.3 Step 3: Creating Static List Data File

Follow these steps to create a static list data file:

1. From the Asset Type drop-down list (top right), select Data File.

2. Click the Create New Asset Type button and select New Contributor Data File.

3. For both Title and Content ID, enter ssd-sidebarlinks-df.

4. For Region Definition, click Browse snd select the ssd-links-rd region definition.

5. Click OK.

4.3.4 Step 4: Creating a Region Template

Follow these steps to create a region file that uses a region template:

1. Expand Site Files, and then expand templates.

2. Right-click the region node and select New.
The New Gallery dialog displays.

3. From the Categories list, expand Web Tier and select JSP.

4. From the Items list, select JSP.

5. Click OK.

6. In the Create JSP dialog:

- For File Name, enter links.jspx.

- Select the Create as XML Document option.

- Select the Register Site File option.

- Select Region Template from the Asset Type drop-down list.

- For Site File ID, enter ssd-links-rt.

- For Description, enter Sidebar Region Template.

- For Region Definition, click Browse and select the ssd-links-rd region definition.

7. Click OK.

8. The links.jspx file should have content similar to this:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core">
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<wcm:dataFile var="dataFile"/>
<ul class="linkroll">    <c:forEach var="row" items="${dataFile.links.rows}">
<li>
<a href="${row.url}">${row.label}</a>
</li>
</c:forEach>
</ul>
</jsp:root>

In the above sidebar region template, note how we are using the new ssd-sidebarlinks-df data file and referencing the properties to format the data.

4.3.5 Step 5: Updating the Sidebar Fragment

Follow these steps to update the sidebar fragment:

1. Expand Site Files, then templates, and then fragments.

2. Right-click the sidebar.jspf fragment and select Open.

3. The file should have content similar to this:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:fn="http://java.sun.com/jsp/jstl/functions">
<div id="sidebar">
<h1 class="first">Sidebar</h1>
<p>
<wcm:placeholder name="sidebar"/>
</p>
<h1>Linkroll</h1>

<wcm:staticPlaceholder dataFile="XABLOG_SIDEBAR_DF"
template="@ssd-sidebarlinks-df"/>
</div>
</jsp:root>

In the above sidebar region template note how we are using a data file and referencing the properties of the data file.

4.3.6 Step 6: Creating a Sidebar Content Region Definition

Follow these steps to create a sidebar content region definition:

1. From the Asset Type drop-down list (top right), select Region Definition.

2. Click the Create New Asset Type button and select New Region Definition.

3. For both Title and Content ID, enter ssd-text-rd.

4. Right-click the ssd-content-rd asset and select Edit.

5. Click Add and enter these values in the Element Instance dialog:

- For both Name and Label, enter text.

- For Location, click Browse button and select the ssd-wysiwyg-ed element definition.

7. Click OK.

8. Save the ssd-text-rd file and check it in.

4.3.7 Step 7: Creating a Sidebar Content Region Template

Follow these steps to create a sidebar content region template file:

1. Expand Site Files, and then expand templates.

2. Right-click the region node and select New.
The New Gallery dialog displays.

3. From the Categories list, expand Web Tier and select JSP.

4. From the Items list, select JSP.

5. Click OK.

6. In the Create JSP dialog:

- For File Name, enter simple.jspx.

- Select the Create as XML Document option.

- Select the Register Site File option.

- Select Region Template from the Asset Type drop-down list.

- For Site File ID, enter ssd-simple-rt.

- For Description, enter Text Region Template.

- For Region Definition, click Browse and select the ssd-text-rd region definition.

7. Click OK.

8. The new simple.jspx file should have content similar to this:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core">
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<wcm:dataFile var="dataFile"/>
<p>${dataFile.text}</p>
</jsp:root>

4.3.8 Step 8: Creating a Sidebar Content Placeholder Definition

Follow these steps to create a sidebar content placeholder definition:

1. From the Asset Type drop-down list (top right), select Placeholder Definition.

2. Click the Create New Asset Type button and select New Placeholder Definition.

3. For both Title and Content ID, enter ssd-simple-phd.

4. Right-click the ssd-simple-phd asset and select Edit.

5. For the Region Definition table, click Add, and select ssd-text-rd.

6. For the Region Template table, click Add, and select ssd-text-rt.

7. Select all Allowed Actions options.

8. Save, check-in, and close the placeholder definition.

4.3.9 Step 9: Adding a Sidebar Placeholder Mapping to the Site

Follow these steps to add a sidebar placeholder mapping to the site:

1. Expand Wed Content, then WEB_INF, and then sites.

2. Right-click SiteStudioDemo.xml and select Open.

3. Click the Placeholder Definition Mappings button.

4. Click Add to add a new Placeholder Definition mapping.

5. For Name, enter sidebar.

6. For Primary Definition ID, click Search and select ssd-simple-phd.

7. Click OK.

8. Click OK again.

4.3.10 Step 10: Assigning Content to the Sidebar

Follow these steps to enter contribution mode and add content to the placeholders on the sidebar:

1. Expand your Site Studio project (SiteStudioDemo) and expand Web Content.

2. Right-click startSiteStudioDemo.jspx and select Run.

3. Once the application is loaded, use Ctrl+Shift+F5 to enter contribution mode.

4. Click the Assign Content button on the sidebar placeholder.

5. From Switch Content, select New Contributor Data File.

6. Click Next

7. On the check-in content page, enter ssd-sidebarcontent-df for Content ID.

8. For Web Sites, select SiteStudioDemo.

9. For Region Definition, select ssd-text-rd.Click Finish.

10. Return to contribution mode by clicking the Switch to Contribution Mode button.

11. For the sidebar placeholder, click the Edit Region Definition button.

12. In the text enter, enter the title Messages.

13. Click Save and Close.
Next we will assign content to the ssd-sidebar-df static placeholder.

14. Switch to contribution mode using Ctrl+Shift+F5.

15. For the ssd-sidebar-df placeholder, click the Edit Region Content button.

16. In the links editor add the following link rows:
Link 1:

- For Label, enter Google.

- For URL, enter http://www.google.com.

Link 2:

- For Label, enter Yahoo!.

- For URL, enter http://www.yahoo.com.

Link 3:

- For Label, enter Bing.

- For URL, enter http://www.bing.com.

17. Click Save and Close.

18. Exit contribution mode using Ctrl+Shift+F5.

4.4 Creating A Dynamic Conversion Page

This section builds on the previous sections. This section adds a dynamic conversion page that demonstrates the use of native documents in the application. Before you proceed make sure the DynamicConverter component for the content server is enabled and configured properly.

- "Step 1: Creating a Conversions Definition"

- "Step 2: Creating a Page Template for the Native Document"

- "Step 3: Creating a New Section for the Native Document"

- "Step 4: Creating a Region Definition for the Native Document"

- "Step 5: Creating a Region Template for the Native Document"

- "Step 6: Creating a Placeholder Definition for the Native Document"

- "Step 7: Adding the Placeholder to the Native Document Page"

- "Step 8: Assigning Content to the Placeholder on the Native Document Page"

4.4.1 Step 1: Creating a Conversions Definition

Follow these steps to create a conversions definition:

1. From the Asset Type drop-down list (top right), select Conversions Definition.

2. Click the Create New Asset Type button and select New Conversions Definition.

3. For both Title and Content ID, enter ssd-default-cd.

4. Right-click the ssd-default-cd asset and select Edit.

5. Click Add to add a dynamic conversion rule to the definition.

6. In the Native Document Conversion Settings dialog:

- For Name, enter simple

- For Options, enable Use simple inline dynamic conversion.

7. Click OK.

8. Save the ssd-default-sd file and check it in.

9. Expand Wed Content, then WEB_INF, and then sites.

10. Right-click SiteStudioDemo.xml and select Open.

11. Expand the Web Site (SiteStudioDemo) node.

12. Double-click the Conversions Definition value to display the Select a Conversions Definition Dialog. Select the ssd-default-cd conversion definition.

13. Click OK.

4.4.2 Step 2: Creating a Page Template for the Native Document

Follow these steps to create a page template for the native document:

1. Expand your Site Studio project (SiteStudioDemo).

2. Expand Site Files, and then expand templates.

3. Right-click the page node and select New.

4. In the New Gallery dialog, expand Web Tier and select JSP.

5. Select JSP in the Items section.

6. Click OK.

7. In the Create JSP dialog:

- For File Name, enter native.jspx.

- Enable the Create as XML Document option.

- Enable the Register Site File option.

- For Asset Type, select Page Template from the list.

- For Site File ID, enter ssd-native-pt.

- For Description, enter Native Documents Page for the SiteStudioDemo site.

8. Click OK.

9. The new page template should have content similar to this:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm">
<jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
doctype-system="http://www.w3.org/TR/html4/loose.dtd"
doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>SiteStudioDemo - Demo Blog</title>
<link type="text/css" rel="stylesheet"
href="../wcm/support/css/template.css"/>
</head>
<body>
<jsp:include page="/wcm/templates/fragments/header.jspf"/>
<div id="container">
<jsp:include page="/wcm/templates/fragments/menu.jspf"/>

<jsp:include page="/wcm/templates/fragments/sidebar.jspf"/>
<!--
Add content below.
-->
<jsp:include page="/wcm/templates/fragments/footer.jspf"/>
</div>
</body>
</html>
</jsp:root>

4.4.3 Step 3: Creating a New Section for the Native Document

Follow these steps to associate the new page template with your site:

1. Expand Wed Content, then WEB_INF, and then sites.

2. Right-click SiteStudioDemo.xml and select Open.

3. Expand the Web Site (SiteStudioDemo) node.

4. Right-click Home and select Add New Section.

5. In the Add New Section dialog:

- For Label, enter About.

- For URL, enter About.

6. Click OK.

7. Right-click on the new About section node and select Include Section in Navigation.

8. Right-click on the About section node and select Select Primary Page Template.

9. In the Select a Page Template dialog, select the ssd-native-pt page template.

10. Click OK.

4.4.4 Step 4: Creating a Region Definition for the Native Document

Follow these steps to create a region definition:

1. From the Asset Type drop-down list (top right), select Region Definition.

2. Click the Create New button and select New Region Definition.

3. For both Title and Content ID, enter ssd-native-rd.

4. Click OK.

5. Refresh the list.

6. Right-click ssd-native-rd and select Edit to open the file in the editor.

7. Select an element from the table and click Switch Region Content.

8. In the Region Content Options dialog, enable the Create new native document option.

9. For Document Types, click Select.

10. Choose any document type from the list and click OK.

11. From the main menu, click File then Save All.

4.4.5 Step 5: Creating a Region Template for the Native Document

Follow these steps to create a region template file that uses a region definition file:

1. Expand your Site Studio project (SiteStudioDemo).

2. Expand Site Files, and then expand templates.

3. Right-click the region node and select New.

4. In the New Gallery dialog, expand Web Tier and select JSP.

5. Select JSP in the Items section.

6. Click OK.

7. In the Create JSP dialog:

- For File Name, enter conversion.jspx.

- Enable the Create as XML Document option.

- Enable the Register Site File option.

- For Asset Type, select Region Template from the list.

- For Site File ID, enter ssd-conversion-rt.

- For Description, enter Native File Region Template.

- For Region Definition, click Browse and select the ssd-native-rd region definition.

8. Click OK.

9. The new conversion.jspx file should have content similar to this:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm">
<div id="content">
<wcm:dynamicConversion rule="simple"/>
</div>
</jsp:root>

4.4.6 Step 6: Creating a Placeholder Definition for the Native Document

Follow these steps to create a placeholder definition that utilizes the newly created region template and region definition:

1. From the Asset Type drop-down list (top right), select Placeholder Definition.

2. Click the Create New Asset Type button and select New Placeholder Definition.

3. For both Title and Content ID, enter ssd-native-phd.

4. Right-click the ssd-content-phd asset and select Edit.

5. For the Region Definition table, click Add, and select ssd-native-rd.

6. For the Region Template table, click Add, and select ssd-conversion-rt.

7. Select all the Allowed Actions options.

8. Save, check-in, and close the placeholder definition.

4.4.7 Step 7: Adding the Placeholder to the Native Document Page

Follow these steps to add a placeholder to the native.jspx file:

1. From the Component Palette, select Site Studio.

2. Drag the Placeholder tag below the Add Content Below comment.

3. In the Insert Placeholder dialog:

- For Name, enter native.

- Select the Add Name to Placeholder Definition Mappings option.

- Select SiteStudioDemo as the site.

4. Click OK.

5. Expand Wed Content, then WEB_INF, and then sites.

6. Right-click SiteStudioDemo.xml and select Open.

7. Click the Placeholder Definition Mappings button.

8. Right-click the native Placeholder Definition Mapping and select Edit. The Edit Placeholder Definition Mapping dialog displays.
The Edit Placeholder Definition Mapping dialog displays.

9. For Primary Definition ID, click Search and select ssd-native-phd.

10. Click OK.

11. Click OK again.

4.4.8 Step 8: Assigning Content to the Placeholder on the Native Document Page

Follow these steps to enter contribution mode and assign content to the placeholder on the native document page.

1. Expand your Site Studio project (SiteStudioDemo) and expand Web Content.

2. Right-click startSiteStudioDemo.jsp and select Run.

3. On the About page, use Ctrl+Shift+F5 to enter contribution mode.

4. Click the Assign Content button on the native placeholder.

5. For Switch Content, select the ssd-native-rd region definition.

6. Click Next.

7. On the Choose Content File wizard page, select the Existing Local File association.

8. Click Next.

9. On the check-in content page, enter ssd-about-native-df for both Title and Content ID.

10. Browse to the primary file, and select it.

11. For Web Sites, select SiteStudioDemo.

12. For Region Definition, select ssd-native-rd.Click Finish.

13. Use Ctrl+Shift+F5 to exit contribution mode.

14. The content of ssd-about-native-df.doc is displayed on the About page.

5 Site Studio Application Components and Technology

This section covers the following topics:

- "Site Studio Application Components"

- "Site Studio Technologies"

- "Using Site Studio Technologies in Your Integration"

5.1 Site Studio Application Components

A Site Studio application is an EAR file, containing multiple WAR files that deliver Site Studio Web sites.

JavaEE EAR File

The examples in this section uses a Site Studio application called MyApplication with a web project called MySites. The structure of the EAR file is as follows:

+-- MyApplication.ear
+-- MySites.war
+-- adf/META-INF/
+-- connections.xml
+-- META-INF/
+-- application.xml
+-- weblogic-application.xml

MySites.war: This is the war file that references a single content server and delivers sites from that content server. See "JavaEE WAR File" for more information.

adf/META-INF/connections.xml: The ADF connections file that holds the definition of which content server is being queried at runtime.

META-INF/weblogic-application.xml: The Weblogic-specific application file that holds a reference to the Site Studio (and RIDC) shared EAR libraries.

JavaEE WAR File

Site Studio Web sites are delivered via a WAR file. The Site Studio libraries can communicate with a single Oracle Content Server instance per WAR file. The structure of the WAR file is as follows:

+-- MySites.war
+-- wcm/templates/
+-- WEB-INF/
+-- web.xml
+-- wcm-config.xml
+-- weblogic.xml

wcm/templates: Directory containing all local templates (JSP/JSPX files) that are registered in the wcm-config.xml file.

WEB-INF/wcm-config.xml: The main Site Studio configuration file, which lists the available sites, connection name, and other configuration settings.

WEB-INF/weblogic.xml: Weblogic-specific file that holds the reference to the shared Site Studio WAR library.

WEB-INF/web.xml: The standard JavaEE configuration file that lists out the servlets, filters and security settings for the application.

5.2 Site Studio Technologies

Site Studio technology uses servlets, filters and tag libraries to deliver Site Studio sites via the deployed web application.

The examples in this section describe the default configuration for a single Site Studio site using the site ID MySite and is delivered via a Site Studio application called MyApplication:

- Site Studio Servlets

- Site Studio Filters

5.2.1 Site Studio Servlets

These are the available Site Studio servlets:

- SiteStudio Proxy Servlet: Proxies the content from Oracle Content Server to your local application; allows the content server to be treated as a local resource within the domain, allows for single sign-on via identity propagation.

- Initialization Servlet: Initializes the Site Studio libraries; does not handle any web requests.

5.2.2 Site Studio Filters

These are the available Site Studio filters:

- Mode Filter: Handles the determination of the mode of the current request. The mode will either be Consumption, Contribution, or Design.

- Site Filter: Delivers Site Studio Web pages using the Site Studio URL syntax, based on the associated project file in Oracle Content Server.

- Proxy Filter: Proxies the content server content to allow for the content server UI to be served from the local web application.

Mode Filter

The mode filter listens for URLs which map to the contribution mode root (/wcm-contrib/*) or the design mode root (/wcm-design/*). If the first segment of the URL matches either of these URLs, the mode is set for the request and the resource is then forwarded, without the first segment, to the web application for processing.

Site Filter

The site filter allows for the processing of Site Studio URLs. Site Studio URLs are hierarchical, based on the structure of the a project file. A typical Site Studio URL looks like /mysite/about/index.html. For more information see "Understanding the Site URL Format".

Site Studio control flow:

1. Site URL via the browser is requested: /mysite/about/index.html

2. Determine the current site ID and section.

- Matches against urlPath in the wcm-config.xml file.

- The site ID is set to mysite and site path set to /about/index.html

3. Instantiate a new SiteContext object and place it in the HttpServletRequest as an attribute named wcmContext.

4. Determine the Page Template ID. In this case, page template is primary via the index.html file name.

5. Lookup the template ID in the wcm-config.xml file to find the local JSP/JSPX resource.

6. Invoke RequestDispatcher to include and render the associated JSP/JSPX page

Proxy Filter

The proxy filter proxies the content server content, using the local user ID, to enable the Oracle Content Server user interface to be served from the local web application. This allows the web application to be integrated with Site Studio Contributor and the Oracle Content Server user interface pages, which reside in the content server domain.

5.3 Using Site Studio Technologies in Your Integration

This section provides notes on the various Site Studio technologies that can used to provide web content management functionality in external applications by integrating with other technologies and frameworks.

Site Studio technologies, including the Site Studio tag library, Site Studio helper methods and various Site Studio filters and servlets can be integrated with other technologies and frameworks, such as ADF components, to deliver web content management functionality to an existing application.

Using Links

When using placeholder tags in externally managed pages or applications, the customer is entirely responsible for the validity of any links in the data file or generated by the region template. The conventional Site Studio section and content links are not relevant to an unmanaged site or application.

Using Site Studio Tags

Context, Datafile, and Template tags are used in conjunction with Placeholder tags, and can be used in externally managed applications.

See "Site Studio Tag Library".

Using Site Studio Helper Methods

Site Studio helper methods are available for scripting templates.

See "Site Studio Helper Methods".

Integrating with Other Technologies or Frameworks

Site Studio tags can be added to other technologies (such as an ADF application or JSF page on a Web site). When used in an integration, all URL management must be handled by the application or application server. Site Studio does not manage the application structure, perform the URL mapping, or the page templating.

Site Studio content can be combined with other components or task flows by adding either a static placeholder or dynamic placeholder to page or application.

- A static placeholder is a placeholder with an explicitly assigned dDocName (content ID). In other words, the static placeholder is associated with the backing data file (and, optionally, region display template) at design time.

- A dynamic placeholder is a placeholder that stores its backing data file dDocName (and, optionally, region template) in a project file. A dynamic placeholder is associated with a backing data file by business users using the switch region content functionality that is part of the contribution process. A context tag must to be included to define where in the project file the switch content action will write the values generated by the switch content wizard.

6 Site Studio Tag Library and Helper Methods

This section provides information on the Site Studio tag library and the Site Studio helper methods. It covers the following topics:

- "Site Studio Tag Library"

- "Site Studio Helper Methods"

Note:
Site Studio tags and helper methods are subject to change with each release of Site Studio. For information on tag library service caching see "Understanding Service Caching with the Site Studio Tag Library".

6.1 Site Studio Tag Library

This topic provides information on the Site Studio tag library and provides descriptions and details for each tag.

- "Site Studio Tag Descriptions"

- "Site Studio <wcm:context> Tag"

- "Site Studio <wcm:dataFile> Tag"

- "Site Studio <wcm:dynamicConversion> Tag"

- "Site Studio <wcm:dynamicList> Tag"

- "Site Studio <wcm:idcParameter> Tag"

- "Site Studio <wcm:idcService> Tag"

- "Site Studio <wcm:metadata> Tag"

- "Site Studio <wcm:placeholder> Tag"

- "Site Studio <wcm:staticPlaceholder> Tag"

- "Site Studio <wcm:url> Tag"

6.1.1 Site Studio Tag Descriptions

This section lists each Site Studio tag and provides a brief description. See the specific tag for additional details.

Tag

Description

wcm:context

The Context tag creates a new SiteContext object and sets it on the current HttpServletRequest. This overrides any existing SiteContext already present. Subsequent calls to any Site Studio API or tag will use this context.

wcm:dataFile

The Data File tag loads content from the content server and parses it into a DataFile object. The object is then exposed as a variable to be used by the Expression Language (EL) to access the individual components of the data file.

wcm:dynamicConversion

The Dynamic Conversion tag is used to specify the conversion rule to use when creating a dynamic conversion of a native document.

wcm:dynamicList

The Dynamic List tag executes the query from the dynamic list element specified that is in the region definition, and makes the results available in the variable var.

wcm:idcParameter

The Idc Parameter tag is used in combination with the Idc Service tag to execute a IDC service call on the content server. Takes a name/value pair.

wcm:idcService

The Idc Service tag is used in combination with the Idc Parameter tag to execute a IDC service call on the content server.

wcm:metadata

The Metadata tag performs a DOC_INFO service call for the content item, and makes the resulting DataBinder available containing the document information about the given content item.

wcm:placeholder

The Placeholder tag is used to specify where an item will be inserted in a template. This will typically be content, but it can also be navigation, code, subtemplates, etc.

wcm:staticPlaceholder

The Static Placeholder tag can be used to add a placeholder with a fixed data file. This is useful for content that does not change, such as headers and footers.

wcm:url

The URL tag renders either hierarchical links into the site structure or links to content server content.

6.1.2 Site Studio <wcm:context> Tag

The Context tag creates a new SiteContext object and sets it on the current HttpServletRequest. This overrides any existing SiteContext already present. Subsequent calls to any Site Studio API or tag will use this context.

If the context is not initialized from the current path (initFromPath is false or not specified), then the new SiteContext will have the same site ID and same URL (unless specified) as the existing SiteContext, if available.

Parameters

- siteID: The site identifier. Required.

- url: The site path. This is a portion of path minus the site ID (for example, /about/index.html. Required.

- initFromPath: Set to true to initialize the context from the current HttpServletRequest path (the url parameter is then ignored).

Example

Initialize a new context to the primary page of the about section for site ID "mysite":

<wcm:context siteID="mysite" url="/about/index.html" />

Reset the current SiteContext to a new URL, without specifying the site ID:

<wcm:context url="/index.html" />

6.1.3 Site Studio <wcm:dataFile> Tag

The Data File tag loads content from the content server and parses it into a DataFile object. The object is then exposed as a variable to be used by the Expression Language (EL) to access the individual components of the data file. Typically the wcm:dataFile tag is used on a region template, to load the assigned DataFile for display.

The DataFile object implements the Map interface, allowing access to all members by the element name. There are two types of elements that can be retrieved:

- TextElement: The text content.

- ListElement: The static list content. The ListElement implements the List interface, which each member of the list a map of TextElements.

Parameters

- var: The variable name of the resulting DataFile object. Required.

- dataFile: The content ID of the data file. If not specified, it uses the currently assigned ID for the current placeholder if called from within a wcm:placeholder tag. Optional.

Example

Assume the data file, with a content ID of AWARDS has the following shape:

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="http://www.stellent.com/wcm-data/ns/8.0.0" version="8.0.0.0">
<element name="title">Awards</wcm:element>
<list name="list">
<row>
<element name="name">2007 Outstanding Organization Award</element>
</row>
<row>
<element name="name">2006 Top 50 Company</element>
</row>
</list>
</root

From a region template, load the assigned data file:

<wcm:dataFile var="dataFile" />

Alternatively, load the data file by specifying the content ID:

<wcm:dataFile var="dataFile" contentID="" />

Model the data into some HTML:

<h2>${title}</h2>
<ul>
<c:forEach var="row" items="${dataFile.list}">
<li>${row.name}</li>
</c:forEach>
</ul>

6.1.4 Site Studio <wcm:dynamicConversion> Tag

The Dynamic Conversion tag is used to specify the conversion rule to use when creating a dynamic conversion of a native document.

Parameter

- rule: The name of the dynamic conversion rule as defined in the ConversionsDefinition file. Required.
From View > Property Inspector > Rule > Edit you can select a rule for the dynamic conversion tag. If a rule is not selected, the default rule is used.

- page: The page number to display. Optional.

- var: Variable to assign the output of the dynamic conversion. If not specified, the output of the conversion will be written to the page directly. Optional.

- dataFile: The dDocName (content ID) of the item to convert. If not specified, the data file assigned to the current placeholder will be used. Optional.

Example

Convert the current data file using the rule ruleName:

<wcm:dynamicConversion rule="ruleName" />

Convert the data file MY_WORD_DOC using the rule ruleName:

<wcm:dynamiConversion dataFile="MY_WORD_DOC" rule="ruleName" />

6.1.5 Site Studio <wcm:dynamicList> Tag

The Dynamic List tag executes the query from the dynamic list element specified that is in the region definition, and makes the results available in the variable var.

Parameters

- element: Name of the element within the list used to construct the list element. Required.

- var: A dynamic list variable. Required.

- dataFile: The data file assigned to the placeholder rendering this dynamic list. Optional.

- placeholder: The name of the placeholder rendering this dynamic list. Optional.

Example

Query using the assigned data file in a region template:

<wcm:dynamicList element="example" var="example"/>

Model the results:

<ul>
<c:forEach var="row" items="${example.resultSets.SearchResults.rows}">
<li>${row.dDocName} - ${row.dDocTitle}</li>
</c:forEach>
</ul>

6.1.6 Site Studio <wcm:idcParameter> Tag

The Idc Parameter tag is used in combination with the Idc Service tag to execute a IDC Service call on the content server. Takes a name/value pair.

Important: Parameters will vary depending on the service called. Refer to the Oracle Fusion Middleware Services Reference Guide for Universal Content Management for the list of service calls and parameters.

Parameters

- name: The IDC Parameter. Enter the parameter for the IDC Service call made on the content server. Use the Site Studio IdcService Tag to define the IDC Service call to be executed on the content server. Required.

- value: An Idc Parameter variable. Enter a valid value for this parameter. Required.

- file: If true, the value parameter specifies a path (either a local file path or a relative file path in this web application) and will be added to the DataBinder as a file object. Optional.

Example

This example used both the Idc Service tag and Idc Parameter tag. In this example, the CHECKIN_UNIVERSAL service is called and the parameters for the service are defined using name/value pairs.

- The doFileCopy parameter is set to TRUE (1), so the file will not be deleted from hard drive after successful check in.

- The dDocName parameter defines the Content ID.

- The dDocTitle parameter defines the Title.

- The dDocType parameter defines the Type.

- The dSecurityGroup parameter defines the Security Group.

- The dDocAuthor parameter defines the Author.

- The primaryFile parameter defines original name for the file and the absolute path to the location of the file as seen from the server.

<wcm:idcservice service="CHECKIN_UNIVERSAL" var="callStatus"
<wcm:idcparameter name="doFileCopy" value="1"/>
<wcm:idcparameter name="dDocName" value="RemoteTestCheckin23"/>
<wcm:idcparameter name="dDocTitle" value="Test1"/>
<wcm:idcparameter name="dDocType" value="ADACCT"/>
<wcm:idcparameter name="dSecurityGroup" value="Public"/>
<wcm:idcparameter name="dDocAuthor" value="sysadmin"/>
<wcm:idcparameter name="primaryFile" value="C:/inetpub/Scripts/query2.asp"/>
/>

This example shows how to get data back from the service call:

<wcm:idcService service="DOC_INFO_BY_NAME" var="docinfo">
<wcm:idcParameter name="dDocName" value="DATAFILE1234" />
<wcm:idcParameter name="RevisionSelectionMethod" value="LatestReleased" />
</wcm:idcService>
<c:forEach var="row" items="${docinfo.resultSets.DOC_INFO.rows}">
<p>The content item <em>${row.dDocName}</em> is a
<u>${row.xWebsiteObjectType}</u></p>
</c:forEach>

6.1.7 Site Studio <wcm:idcService> Tag

The Idc Service tag is used in combination with the Idc Parameter tag to execute a IDC service call on the content server.

Important: Parameters will vary depending on the service called. Refer to the Oracle Fusion Middleware Services Reference Guide for Universal Content Management for the list of service calls and parameters.

Parameters

- service: The Idc Service. Enter the IDC Service call to be executed on the content server. The service call returns a data binder. Use the Site Studio IdcParameter tag to set parameters for the service call. Required.

- var: An Idc Service variable. Enter a name for the variable that will hold the results of the returned response from the content server. Required.

- type: If set to stream, the response from the content server is an InputStream object. By default, the response is a oracle.stellent.ridc.model.DataBinder. Optional.

Example

This example used both the Idc Service tag and Idc Parameter tag. In this example, the CHECKIN_UNIVERSAL service is called and the parameters for the service are defined using field/value pairs

- The doFileCopy parameter is set to TRUE (1), so the file will not be deleted from hard drive after successful check in.

- The dDocName parameter defines the Content ID.

- The dDocTitle parameter defines the Title.

- The dDocType parameter defines the Type.

- The dSecurityGroup parameter defines the Security Group.

- The dDocAuthor parameter defines the Author.

- The primaryFile parameter defines original name for the file and the absolute path to the location of the file as seen from the server.

<wcm:idcservice service="CHECKIN_UNIVERSAL" var="callStatus"
<wcm:idcparameter name="doFileCopy" value="1"/>
<wcm:idcparameter name="dDocName" value="RemoteTestCheckin23"/>
<wcm:idcparameter name="dDocTitle" value="Test1"/>
<wcm:idcparameter name="dDocType" value="ADACCT"/>
<wcm:idcparameter name="dSecurityGroup" value="Public"/>
<wcm:idcparameter name="dDocAuthor" value="sysadmin"/>
<wcm:idcparameter name="primaryFile" value="C:/inetpub/Scripts/query2.asp"/>
/>

This example shows how to get data back from the service call:

<wcm:idcService service="DOC_INFO_BY_NAME" var="docinfo">
<wcm:idcParameter name="dDocName" value="DATAFILE1234" />
<wcm:idcParameter name="RevisionSelectionMethod" value="LatestReleased" />
</wcm:idcService>
<c:forEach var="row" items="${docinfo.resultSets.DOC_INFO.rows}">
<p>The content item <em>${row.dDocName}</em> is a
<u>${row.xWebsiteObjectType}</u></p>
</c:forEach>

6.1.8 Site Studio <wcm:metadata> Tag

The Metadata tag performs a DOC_INFO service call for the content item, and makes the resulting DataBinder available containing the document information about the given content item.

Parameters

- contentID: The content ID. Required.

- var: The metadata variable. Required.

Example

<wcm:metadata contentID="DATAFILE1234" var="metadata"/>
<c:forEach var="metadatarow" items="${metadata.resultSets.DOC_INFO.rows}">
<p>The content item <em>${metadatarow.dDocName}</em> is a
<u>${metadatarow.xWebsiteObjectType}</u></p>
</c:forEach>

You can also use the data file on a region template rather than a fixed ID, for example:

<wcm:metadata contentID="${wcmContext.placeholder.dataFile}" var="meta"/>

6.1.9 Site Studio <wcm:placeholder> Tag

The Placeholder tag is used to specify where an item will be inserted in a template. This will typically be content, but it can also be navigation, code, subtemplates, etc.

Parameters

- name: the name of the placeholder. Required.

- location: The location on the template. Optional.

- definition: Specifies the mapping to a placeholder definition, which overrides any mappings specified in other ways. Optional.

- template: The region template to use to render the Data File. Optional.

- dataFile: The dDocName of the data file to assign to this placeholder. Optional.

- regionDefinition: The dDocName region definition to use, instead of the xRegionDefinition on the data file. Optional.

- actions: The allowed actions of the placeholder definition. Any number of actions can be set. If you use parameters that do not work together (for example, specifying a subtemplate as well as a region definition), then the tag will execute based on the order of parameters listed above. Optional.

- Update [E]: Allows contributor update.

- Approve [A]: Allows workflow approval.

- Document Information [I]: Allows viewing document information.

- Switch Data File [S]: Allows switching the data file.

- View Usage Report [U]: Allows viewing the web usage report.

- View tracker Report [T]: Allows viewing the web tracker report.

- Document Information Update [M]: Allows updating the content information.

- Switch Region Template [V]: Allows switching the region template.

- Remove Content [N]: Allows content removal by the contributor.

Example

<wcm:placeholder name="yourplaceholdername" actions="E"/><wcm:placeholder name="yourplaceholdername" actions="EPRISUTMVN"/>

6.1.10 Site Studio <wcm:staticPlaceholder> Tag

The Static Placeholder tag can be used to add a placeholder with a fixed data file. This is useful for content that does not change, such as headers and footers.

Parameters

- dataFile : The dDocName (content ID) of the data file to assign to this static placeholder. Required.

- name: the name of the static placeholder. Optional.

- template: The region template to use to render the data file. Optional.

- actions: The allowed actions of the placeholder definition. Any number of actions can be set. If you use parameters that do not work together (for example, specifying a subtemplate as well as a region definition), then the tag will execute based on the order of parameters listed above. Optional.

- Update [E]: Allows contributor update.

- Approve [A]: Allows workflow approval.

- Document Information [I]: Allows viewing document information.

- Switch Data File [S]: Allows switching the data file.

- View Usage Report [U]: Allows viewing the web usage report.

- View tracker Report [T]: Allows viewing the web tracker report.

- Document Information Update [M]: Allows updating the content information.

- Switch Region Template [V]: Allows switching the region template.

- Remove Content [N]: Allows content removal by the contributor.

Example

<wcm:staticPlaceholder datafile="yourdatafile" actions="E"/><wcm:staticPlaceholder datafile="yourdatafile" actions="EPRISUTMVN"/>

6.1.11 Site Studio <wcm:url> Tag

The URL tag renders either hierarchical links into the site structure or links to content server content.

Parameters

- var: The variable name to store the link result.

- type: The type of link. Required.

- node: Defines a URL for a node.

- dcresource: Defines a URL for a dynamic conversion resource. Only valid inside a placeholder tag.

- dcpage : Defines a URL for a dynamic conversion page. Only valid inside a placeholder tag.

- rendition: Defines a URL for a rendition.

- resource: Defines a URL for a resource. Used to link to weblayout static resources, such as images.

- Link : Used to create links to content.

- url: The link parameter (format dependent on the type). Required.

- node: Format of nodeId|nodePath.

- dcresource: Format of dcResourcePath.

- dcpage: Format of dcPageNum.

- rendition: Format of dDocName/renditionName.

- resource: Format of dDocName or webLayoutPath.

- Link : Format of dDocName or (nodeId|nodePath)/dDocName.

- siteID: The site identifier for the link target. This consists of the section ID and the content ID for a site content item. For example, a section ID of 56 and content ID of TEST_ITEM.

Example

Create a link to the /About section (which has a section ID of 20):

<wcm:url var="url" type="node" url="/About" />
<wcm:url var="url" type="node" url="20" />

Create a link to a piece of content in the content server:

<wcm:url var="url" type="resource"
url="/groups/public/documents/document/news_article.doc" />

Url to a rendition of a content item::

<!--$wcmUrl("resource","dDocName")-->
<!--$wcmUrl("resource","groups/public/documents/adacct/mydocname.jpg")-->

Create a link to a piece of content to display inside a node (optionally specifying the section):

<wcm:url var="url" type="link" url="NEWS_ARTICLE" /><wcm:url var="url" type="link" url="20/NEWS_ARTICLE" />

6.2 Site Studio Helper Methods

These Site Studio Helper Methods are available for scripting templates:

- "Site Studio <filterSections> Method"

- "Site Studio <listSectionsForRows> Method"

- "Site Studio <isNodeInNavigationPath> Method"

- "Site Studio <lookupSection> Method"

6.2.1 Site Studio <filterSections> Method

Filter a section list to remove inactive sections and contributor-only sections if not in contribution mode.

public static List<SectionNode> filterSections (SiteContext siteContext, List sections) { }

Parameters

- siteContext: the site context

- sections: a list of {@link SectionNode} objects

- stopLevel: the level to stop (inclusive)

- includeHome: true to include the home section

Returns

- sectionList: return a list rows (represented as a list of sections)

Code

public static List<SectionNode> filterSections (SiteContext siteContext, List sections) {
if (sections == null) {
return null;
}

List<SectionNode> sectionList = new ArrayList<SectionNode> (sections.size ());
for (Object sectionObj : sections) {
SectionNode section = (SectionNode)sectionObj;
if (!Boolean.parseBoolean (section.getModel ().getActive ())) {
continue;
}
if (Boolean.parseBoolean (section.getModel ().getContributorOnly ())
&& !siteContext.isContributorMode ()) {
continue;
}

//add the section to the list
sectionList.add (section);
}

return sectionList;
}

6.2.2 Site Studio <listSectionsForRows> Method

Create a list of sections matching the given parameters. Each row in the list will contain all sections at that level.

public static List listSectionsForRows (SiteContext siteContext, int startLevel, int stopLevel, boolean includeHome) { }

Parameters

- siteContext: the site context

- startLevel: the level to start (inclusive)

- stopLevel: the level to stop (inclusive)

- includeHome: true to include the home section

Returns

- rows: return a list rows (represented as a list of sections)

Code

public static List listSectionsForRows (SiteContext siteContext, int startLevel, int stopLevel, boolean includeHome) {
List<List<SectionNode>> rows = new ArrayList<List<SectionNode>> ();
//get the first level
if (startLevel < 1) {
startLevel = 1;
}
if (stopLevel < 1) {
stopLevel = 1;
}
Project project = siteContext.getProject ();
for (int i = startLevel; i <= stopLevel; i++) {
List<SectionNode> sections = project.getStructure ().getSectionsAtLevel (i);
if (sections.isEmpty ()) {
//no more sections so we can end here
break;
}
rows.add (sections);
}
if (startLevel == 1 && includeHome) {
List<SectionNode> nodes = null;
if (rows.size () >= 1) {
nodes = rows.get (0);
} else {
nodes = new ArrayList<SectionNode> ();
rows.add (nodes);
}
nodes.add (0, project.getStructure ().getRootSection ());
}
return rows;
}

6.2.3 Site Studio <isNodeInNavigationPath> Method

Look to see if the current node is in the navigation path.

public static boolean isNodeInNavigationPath (SiteContext siteContext, String nodeID, boolean includeHome) { }

Parameters

- siteContext: the site context

- nodeID: the node ID

- includeHome: true to include the home section in this check, false to exclude

Returns

- isInNavPath: returns true if the node ID is part of the current navigation path

Code

public static boolean isNodeInNavigationPath (SiteContext siteContext, String nodeID, boolean includeHome) {         if (nodeID == null) {             return false;         }          boolean isInNavPath = false;         SectionNode section = siteContext.getSection ();         if (section != null) {             isInNavPath = (section.getID ().equals (nodeID));              if (!isInNavPath) {                 for (SectionNode parent : section.getAncestors ()) {                     if (parent.getParent () == null && !includeHome) {                         continue;                     }                     isInNavPath = (parent.getID ().equals (nodeID));                     if (isInNavPath) {                         break;                    }                }             }          }            return isInNavPath;      }

6.2.4 Site Studio <lookupSection> Method

Look up a section by path or ID.

public static SectionNode lookupSection (SiteContext siteContext, String id) { }

Parameters

- siteContext: the site context

- id: the section path or ID

Returns

- section: return the section or null if not found

Code

public static SectionNode lookupSection (SiteContext siteContext, String id) {
//see if this is a number
SectionNode section = null;
boolean isNumber = false;
try {
Integer.parseInt (id);
isNumber = true;
} catch (NumberFormatException exp) {
//ignored
}

if (isNumber) {
section = siteContext.getProject ().getStructure ().getSectionByID (id);
} else {
//fix up path
id = PathHelper.ensureForwardSlashes (id);
//handle relative
if (!id.startsWith ("/")) {
//get the current section
SectionNode current = siteContext.getSection ();
if (current != null) {
id = current.getUrlPath () + "/" + id;
}
}
section = siteContext.getProject ().getStructure ().getSectionByPath (id);
}

return section;
}

Index
A  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  V  W  X

Symbols

__ssxaCacheEnabled, 1.7

__ssxaCacheFields, 1.7

__ssxaCacheKey, 1.7

__ssxaCacheTTL, 1.7

A

access control lists, 1.5

application components, 5.1

assets

contributor data files, 2.1, 2.6, 2.13, 2.13

conversion definitions, 2.1

custom configuration scripts, 2.1

custom element forms, 2.1

element definitions, 2.1, 2.6, 2.6, 2.8

elements, 2.6, 2.6, 2.8

hierarchy, 2.6

images, 2.1

native documents, 2.1, 2.13, 2.13

other media, 2.1

page templates, 2.1, 2.6, 2.12

placeholder definitions, 2.1, 2.6, 2.10, 2.10

placeholders, 2.6, 2.10

region definitions, 2.1, 2.6, 2.6, 2.9

region templates, 2.1, 2.6, 2.6, 2.9

reusing, 2.7, 2.13

storage, 2.2

subtemplates, 2.1, 2.6, 2.11

validation scripts, 2.1

authentication

contribution mode, 1.5

design mode, 1.5

C

catch-all placeholder definition, 2.10

configuration files, 2.1

configuration scripts, 2.1

connections.xml, 5.1

content

separation of presentation and content, 2.1

content caching, 1.6 content files, 2.1, 2.13

reusing, 2.7, 2.13

content information fields for site assets, 2.2 content information page, 2.2 content server

security model, 3.3

context tag, 6.1.2 contribution

access levels, 3.3

contribution graphic, 3.3 contribution mode, 1.5, 2.5 contribution mode authentication, 1.5 contribution model, 2.5 contribution region

security model, 3.3

contributor

as content provider, 3.3

levels of contribution, 3.3

role, 3.3

contributor athentication, 1.5 contributor data file, 3.1

and secondary pages, 3.5.6

sharing across web sites, 3.2

contributor data files, 2.1, 2.6, 2.13, 2.13 contributors, 2.3, 2.13 control files, 2.1 conversion definitions, 2.1 custom configuration scripts, 2.1 custom element forms, 2.1

D

data files, 2.1, 2.13, 2.13

dataFile tag, 6.1.3

default placeholder definition, 2.10

definitions

conversions, 2.1

element, 2.1, 2.8

placeholder, 2.1, 2.10, 2.10

region, 2.1, 2.9

design mode, 1.5 design mode authentication, 1.5 designers, 2.3

role of, 3.3

dynamic lists

and secondary pages, 2.14

dynamicConversion tag, 6.1.4 dynamicList tag, 6.1.5

E

element definitions, 2.1, 2.6, 2.6, 2.8

naming conventions, 3.5.1

site planning, 3.3, 3.5.1, 3.5.2, 3.5.3, 3.5.4, 3.5.5, 3.5.6

element forms, 2.1 elements, 2.6, 2.6, 2.8 Exclude From Lists (metadata), 2.2

F

files

content, 2.1, 2.13

contributor data files, 2.1, 2.13, 2.13, 2.13

control and configuration, 2.1

conversion definitions, 2.1

custom configuration scripts, 2.1

custom element forms, 2.1

element definitions, 2.1

images, 2.1

media, 2.1

native documents, 2.1, 2.13, 2.13, 2.13

page templates, 2.1, 2.12

placeholder definitions, 2.1

presentation, 2.1

region definitions, 2.1

region templates, 2.1

subtemplates, 2.1, 2.11

validation scripts, 2.1

filters

mode, 5.2.2

proxy filter, 5.2.2

site filter, 5.2.2

filterSections method, 6.2.1 forms for elements, 2.1

G

global placeholder mapping, 2.10

H

helper methods

filterSections, 6.2.1

isNodeInNavigationPath, 6.2.3

listSectionsForRows, 6.2.2

lookupSection, 6.2.4

hierarchy of site objects, 2.6

I

idcParameter tag, 6.1.6

idcService tag, 6.1.7

images, 2.1

Initialization servlet, 5.2.1

isNodeInNavigationPath method, 6.2.3

J

JavaEE EAR file, 5.1

JavaEE WAR file, 5.1

jsp/jspx templates, 1.4

L

layout

and site planning, 3.1

Link wizard, 3.3 lists

dynamic, 2.14

listSectionsForRows method, 6.2.2 lookupSection method, 6.2.4

M

mapping placeholders with placeholder definitions, 2.10

media files, 2.1

metadata

and site planning, 3.3

site planning, 3.5.5

xRegionDefinition, 2.2

metadata fields

Exclude From Lists, 2.2

region definition, 2.2

web site object type, 2.2

web site section, 2.2

web sites, 2.2

xRegionDefinition, 2.2

metadata for site assets, 2.2 metadata tag, 6.1.8 mode filter, 5.2.2, 5.2.2 model for contribution, 2.5 model for presentation, 2.4

N

naming conventions

element definitions, 3.5.1

page templates, 3.4

region definitions, 3.5.2

region templates, 3.5.3

sections, 3.2

site assets, 3.4

site planning, 3.5.6

native documents, 2.1, 2.13, 2.13, 3.3

sharing across web sites, 3.2

submitting to a site, 3.3

navigating the site, 3.2

O

other media, 2.1

P

page templates, 1.4, 2.1, 2.6, 2.12

advantage of multiple, 3.2

and subtemplates, 3.5.4

explained, 3.2

multiple versus reusable, 3.2

primary pages, 3.5.6

secondary pages, 3.5.6

site planning, 3.2, 3.5.4, 3.5.6

pages

primary, 2.14

secondary, 2.14

placeholder definitions, 2.1, 2.6, 2.10, 2.10, 3.5.5

catch-all, 2.10

default, 2.10

placeholder tag, 6.1.9 placeholderDefinitionDocName, 2.10 placeholders, 2.6, 2.10

mapping, 2.10

planning a web site, 3, 3 planning the site hierarchy, 3.2 presentation files, 2.1 presentation model, 2.4 presentation, separation from content, 2.1 primary pages, 2.14

explained, 3.2

site planning, 3.2, 3.5.6

project structure, 1.1 proxy filter, 5.2.2, 5.2.2

R

region content

adding content not associated with a web site, 3.2

region definition (metadata), 2.2 region definitions, 2.1, 2.2, 2.6, 2.6, 2.9

naming conventions, 3.5.2

site planning, 3.5.2

region templates, 1.4, 2.1, 2.6, 2.6, 2.9

naming conventions, 3.5.3

site planning, 3.2, 3.5.3

registering templates, 1.4 reusable page templates, 3.2 reusing site assets, 2.7, 2.13 roles

contributors, 2.3

designers, 2.3

roles for web sites, 2.3

S

scripts

custom configuration scripts, 2.1

validation, 2.1

secondary pages, 2.14

and contributor data files, 3.5.6

dynamic lists, 2.14

explained, 3.2

site planning, 3.2, 3.2, 3.5.6

sections

name, 3.2

naming conventions, 3.2

placeholder mapping, 2.10

primary pages, 2.14

secondary pages, 2.14

site hierarchy, 3.2

security, 1.5 security model, 3.3 security settings

access control lists, 1.5

accounts, 1.5

groups, 1.5

separation of presentation and content, 2.1 servelets

Initialization, 5.2.1

servelets SiteStudio proxy, 5.2.1 service caching, 1.7 service caching parameters

__ssxaCacheEnabled, 1.7

__ssxaCacheFields, 1.7

__ssxaCacheKey, 1.7

__ssxaCacheTTL, 1.7

site assets, 3.4

contributor data files, 2.1, 2.6, 2.13, 2.13

conversion definitions, 2.1

custom configuration scripts, 2.1

custom element forms, 2.1

element definitions, 2.1, 2.6, 2.6, 2.8

elements, 2.6, 2.6, 2.8

hierarchy, 2.6

images, 2.1

management, 3.4

naming, 3.4

native documents, 2.1, 2.13, 2.13

order of creation, 3.5

other media, 2.1

page templates, 2.1, 2.6, 2.12

placeholder definitions, 2.1, 2.6, 2.10, 2.10

placeholders, 2.6, 2.10

region definitions, 2.1, 2.6, 2.6, 2.9

region templates, 2.1, 2.6, 2.6, 2.9

reusing, 2.7, 2.13

storage, 2.2

subtemplates, 2.1, 2.6, 2.11

validation scripts, 2.1

site configuration files, 2.1 site content files, 2.1 site control files, 2.1 site files, 1.2 site filter, 5.2.2, 5.2.2 site hierarchy

contribution model, 3.3

depth of, 3.2

planning, 3.2

purpose of, 3.2

section name, 3.2

sections, 3.2

site planning, 3.3, 3.5.6

site identifier, 1.3 site navigation

planning, 3.3

role of sections, 3.2

site object hierarchy, 2.6 site planning, 3.1, 3.2

and page templates, 3.1, 3.4

and region templates, 3.1

and subtemplates, 3.1

arranging data, 3.1

asset creation, 3.5

communication, 3.3

construction, 3.1

content, 3.1, 3.1

contributor data file, 3.1

contributor role, 3.3, 3.3, 3.3, 3.3

designer role, 3.3

element definitions, 3.3, 3.5.1, 3.5.2, 3.5.3, 3.5.4, 3.5.5, 3.5.6

examples

page templates, 3.1

placeholder, 3.1, 3.1

subtemplates, 3.1, 3.1, 3.1

importance of, 3.1 layout, 3.1 manager role, 3.3 metadata, 3.3, 3.5.5 multiple contributors, 3.3 naming conventions, 3.5.6 organization, 3.1 page templates, 3.2, 3.5.4, 3.5.6 placeholder definitions, 3.5.5 primary pages, 3.2, 3.5.6 region definitions, 3.5.2 region templates, 3.2, 3.5.3 secondary pages, 3.2, 3.2, 3.5.6 sections, 3.2 site hierarchy, 3.2, 3.3, 3.5.6 site navigation, 3.3 site updates, 3.4 structure, 3.1 subtemplates, 3.5.4, 3.5.4, 3.5.5, 3.5.6 user access, 3.3 workflow, 3.2, 3.3, 3.5.5 site presentation files, 2.1 site studio

contribution model, 2.5

metadata fields, 2.2

presentation model, 2.4

site object hierarchy, 2.6

site studio site files, 1.2 site studio technologies, 5.2 site URL format

content, 1.3

section, 1.3

site identifier, 1.3

SiteStudio proxy servlet, 5.2.1 staticPlaceholder tag, 6.1.10 storage of site assets, 2.2 structure of a site studio project subtemplates, 1.4, 2.6

and page templates, 3.5.4, 3.5.6

site planning, 3.5.4, 3.5.4, 3.5.5, 3.5.6

templates

subtemplates, 2.1, 2.11

T

tag for placeholders, 2.10

tag library

context, 6.1.2

dataFile, 6.1.3

dynamicConversion, 6.1.4

dynamicList, 6.1.5

idcParameter, 6.1.6

idcService, 6.1.7

metadata, 6.1.8

placeholder, 6.1.9

staticPlaceholder, 6.1.10

url, 6.1.11

template registration, 1.4 templates

page, 2.1, 2.12

page templates, 1.4

region, 2.1, 2.9

region templates, 1.4

subtmplates, 1.4

third-party applications, 2.13

U

urltag, 6.1.11

users

contributors, 2.3

designers, 2.3

V

validation scripts, 2.1

W

wcm-config.xml, 1.1, 5.1

web site

access by contributors, 3.3

adding content not currently associated, 3.2

content files, 2.1

control and configuration files, 2.1

planning, 3

presentation files, 2.1

reusing site assets, 2.7, 2.13

roles, 2.3

separation of presentation and content, 2.1

sharing a contributor data file, 3.2

sharing a native document, 3.2

submitting native documents, 3.3

updating, 3.3

web site object type (metadata), 2.2 web site properties

default placeholder definition, 2.10

web site section (metadata), 2.2 web sites (metadata), 2.2 weblogic-application.xml, 5.1 weblogic.xml, 1.1, 5.1 web.xml, 1.1, 5.1 wizard

link, 3.3

workflows

site planning, 3.2, 3.3, 3.5.5

X

XML, 2.13

xRegionDefinition, 2.2

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2014, Oracle and/or its affiliates. All rights reserved.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.