Content Management Implementation Guide 5.3 SP1

(1)

Content Management

Implementation Guide

5.3 SP1

Read this document to implement and learn about the following Content Manager features:

Publications Content configuration

Blueprint Publication structure Custom Pages

Users and Groups Event Log

Publishing configuration and behavior Metadata

Categories and Keywords Workflow

(2)

Content Management

Implementation Guide 5.3 SP1

R5_CMIG_53SP1

©

1999-2009 SDL Tridion Development Lab BV

NOTICE: The accompanying software package is confidential and proprietary to SDL Tridion Development Lab BV or its respective licensors. No use or disclosure is permitted other than as set forth by written license with the authorized distributors of SDL Tridion Development Lab BV. Trademarks

SDL Tridion and SDL Tridion R5 are trademarks of SDL Tridion Development Lab BV or its respective licensors. All other company or product names used herein are trademarks of its respective owners. Suggestions

Your suggestions and comments about SDL Tridion R5 functionality, documentation, and course material are highly valued and may be used to further enhance our offerings available to you. We will be glad to receive your suggestions at:

SDL Tridion Development Lab BV Product Management P. O. Box 22709 1100 DE Amsterdam The Netherlands fax: +31 (0)20 20 10 501 Email: [email protected] Additional Licenses

Please contact your SDL Tridion sales representative to order additional licenses of SDL Tridion R5 software. www.sdltridion.com offers you a complete overview of SDL Tridion's sales offices and further contact details.

(3)

Preface

About this Project Planning Guide

SDL Tridion R5 Content Delivery allows you to take content from the Content Manager and present it to the Web site visitor. This document explains how to plan, set up and organize Content Delivery.

Read this document if your are a project manager or software architect planning to implement SDL Tridion R5 Content Delivery, preferably before you start using SDL Tridion R5.

This Guide does not explain implementation details. To learn how to configure and implement Content Delivery and to find the API reference, refer to one of the Content Delivery Implementation Manuals:

• Content Delivery Implementation Manual (ASP) • Content Delivery Implementation Manual (ASP.NET) • Content Delivery Implementation Manual (JSP)

How to use this guide

Use this guide when you are planning and designing Content Delivery for your implementation of SDL Tridion R5, both in the functional design stage and the technical design stage.

Chapter 1 Tridion Content Delivery

Explains Content Delivery and the overall implementation plan of Content Delivery.

Chapter 2 Implementing Content Distribution

Explains how to plan the implementation of Content Distribution, that is, getting content from the SDL Tridion R5 Content Manager on to a Presentation Server.

Chapter 3 Developing the Web site

Explains how to plan the development of your SDL Tridion-based Web site.

Chapter 4 Profiling and personalization

Explains how to discover which visitor visits which type of content (profiling), and how to use that information to customize a Web site visit (personalization).

(4)

Content Delivery Project Planning Guide 5.3 SP1

Chapter 5 Designing the infrastructure

Explains how to design Content Delivery to multiple target machines.

Chapter 6 Content Delivery use case

Presents a basic use case scenario (Content Delivery project) and describes its implementation

Chapter 7 Advanced topics

Covers a number of advanced topics that are not part of a standard Content Delivery implementation

Version history

This version history list outlines the changes to the Content Delivery Project Planning Guide 5.3 SP1 since it was last released.

Product version Document number Changes

5.3 R5_CDPPG_10 New release and book.

(6)

(7)

Content Delivery Project Planning Guide 5.3 SP1

Chapter 4 Implementing dynamic functionality ... 25

4.1 Implementing search ... 25

4.2 Implementing Dynamic Component Presentations ... 26

4.3 Implementing Dynamic Linking ... 27

4.4 Implementing dynamic navigation ... 27

4.5 Dynamic Content Assembly ... 28

Chapter 5 Profiling and personalization ... 31

5.1 Profiling and personalization concepts ... 31

5.2 Profiling and personalization implementation decisions ... 32

5.2.a Choosing to implement Tracking ... 32

5.2.b Choosing to implement Tracking Keys ... 33

5.2.c Choosing to implement personalization ... 33

5.3 Profiling and personalization implementation plan ... 33

5.3.a Implementing Tracking and Tracking Keys ... 34

5.3.b Implementing personalization ... 34

Chapter 6 Content Delivery use case ... 37

6.1 Project definition and constraints ... 37

6.2 Setting up transport ... 38

6.3 Implementing dynamic functionality ... 39

(9)

Chapter 1 Content Delivery

Content Delivery is the process of getting content out of the Content Manager and presenting it to a Web site visitor.

1.1 Content Delivery concepts

Content Delivery consists of three parts: • Content Distribution

• Dynamic Publishing

• Profiling and Personalization

Content Distribution

Content Distribution refers to the transportation of content from the Content Manager, where content is created and maintained, to the Presentation Server, where content is stored and presented.

Dynamic Publishing

Dynamic Publishing refers to the implementation of functionality that require scripting on the Presentation Server, such as:

• search functionality • automatic navigation

• dynamically assembled content • dynamically resolved hyperlinks

You can choose to implement all, some or none of this functionality, depending on what kind of Web site you would like to build.

(10)

Chapter 1 Content Delivery

Profiling and Personalization refers to two processes:

• Profiling: collecting information about the browsing behavior of the visitors of your Web site

• Personalization: using the information collected during Profiling to customize the experience of the Web site visitor.

You can choose to either not implement Profiling and Personalization at all, to only implement Profiling, or to implement both.

1.2 Implementation plan

To implement Content Delivery, follow these steps:

Note that the order of these implementation steps is not rigid. For example, setting up the Presentation Server infrastructure may be done in parallel with the development of the Web site.

1.3 Licensing

The various functionality in Content Delivery has different licenses: • Content Distribution consists of two different parts:

Rendering and resolving content: this is covered by the license of the Content Manager.

Transporting content: the Transport Service license covers all

Table 1-1 Implementation plan for Content Delivery

Implementation step Description Explained in

1 Set up Content Distribution

Implement basic Content Distribution to ensure that you can publish content from your Content Manager to one Presentation Server.

Chapter 2

"Implementing Content Distribution" on page 5 2 Develop the Web site Choose a Web site model

and develop dynamic publishing for the Web site. Use the

Presentation Server to verify the results.

Chapter 3 "Developing the Web site" on page 13

3 Set up Profiling and Personalization (optional)

Implement profiling and personalization, using the Presentation Server to verify the results.

Chapter 5 "Profiling and personalization" on page 31

4 Set up a Presentation Server infrastructure

Create a more elaborate Presentation Server infrastructure.

(11)

Chap

ter 1

C

o

n

tent Deliv

e

ry

transport protocols offered by SDL Tridion R5.

• Web site development can involve one or both of the following: Dynamic Publishing, which requires a Web and Application Server

Integration (WAI) license

Dynamic Linking, which requires a Linking license.

• Profiling and personalization requires the Web and Application Server Integration (WAI) license.

(12)

(13)

Chapter 2 Implementing Content

Distribution

Content Distribution (also known as Publishing) involves a number of processes, each of which performs a specific task. This chapter explains the Content Distribution process in an overview, then explains how to implement Content Distribution, and then explains which parts of Content Distribution you can configure or adjust, and why you would want to.

Note This chapter describes how to implement Content Distribution from the Content Manager to one Presentation Server. The decisions listed here must be made for each Presentation Server to which you want to distribute content. To learn how to organize an infrastructure of Presentation Servers, refer to the Installation Manual.

2.1 Content Distribution concepts

Figure 2-1 shows the various parts of Content Distribution.

(14)

Chapter 2 Implementing Content Distribution

The purpose of Content Distribution (or Publishing) is to get content out of the Content Manager and on the Presentation Server. The Presentation Server is a Web and Application Server. This section describes the sequence of subprocesses that make up Content Distribution.

Not all of these processes can be configured or customized. Implementing Content Distribution consists of setting up the Presentation Server and making

customizations and configurations where needed. This is described in "Content

Distribution implementation plan" on page 12.

2.2 Content Distribution implementation decisions

Before you start implementing Content Distribution, you must make a number of decisions. Most of these decisions depend on technical factors, such as the technical expertise of your Web developers or the type of database you commonly use.

The following implementation decisions must be made:

• Which Web Application Server technology will the Presentation Server use? • Which type of data store will the Presentation Server use?

• Which transfer protocol will Content Distribution use?

• Which, if any, customizations will you make to content deployment?

• Which content will you store in the data store, and which content in the Web folders?

• Will you implement caching?

Table 2-1 Content Distribution process Subprocess Description

Publisher In the Content Manager, either a user or some automated event triggers the publishing of an item. The Publisher offers this item to the Transport Service.

Transport Service The Transport Service assembles this item, together with any other items on which it depends, into a transport package.

Sender A Sender sends the package to one or more destinations using a specific protocol. Each destination represents a Presentation Server (usually a remote machine). At this point, the content leaves the Content Manager.

Receiver On the Presentation Server, a Receiver receives the package, using the same protocol as the Sender.

Deployer Upon arrival, the package is processed by a Content

Deployer. By default, this means that the items in the package are sent on to a Content Broker. But you can add your own custom processing ("Customizing content deployment" on page 8 explains how).

Broker The Content Broker stores the data it receives from the Deployer. The Broker stores data in a data store (a database or the local file system) and in a Web folder.

(15)

Chapter 2 Im

plementi

ng Content D

istributi

on

2.2.a

Choosing the Web Application Server technology

Your Web Application Server can be one of the following: • Microsoft Internet Information Services (IIS) • ASP.NET Framework

• Java-based Web and Application Server (Tomcat, for example) You choose a technology based on the expertise you have available for

implementing that technology. That is, if you have a team of Java gurus, using an IIS-based Web Server is not the most logical choice.

Also note that an ASP.NET implementation is somewhat different from the IIS or Java-based implementations. Refer to the Content Delivery Implementation

Manual (ASP.NET) for details.

2.2.b

Choosing a type of data store

SDL Tridion R5 supports data storage in a variety of data stores: • A file system

• SQL type databases: Oracle

Microsoft SQL Server DB2

To choose between these options, use the following guidelines:

• Publishing to a file system is generally only a good idea if you are publishing to a corporate, local intranet.

• SQL type databases are the most commonly used. The choice between them depends on the expertise of your database administrators.

Regardless of the type of database you choose, always make sure that your Presentation Server data store has ample space to store all the published content.

2.2.c

Choosing a transfer protocol

More often than not, the Presentation Server to which you publish your content will dictate the protocol or protocols you can use. Your choice of protocols is:

• FTP

• SFTP (that is, FTP over SSH tunnels)

• SSHFTP (that is, SSH2 with a file transfer protocol subsystem) • HTTP

Important:

The Presentation Server must be able to connect to the data store. If the data store is a database, this means that you need a JDBC driver on the Presentation Server that can connect to this database.

(16)

Chapter 2 Implementing Content Distribution

• HTTPS

• Local file system • A custom protocol

Depending on the protocol you choose, you need different Sender/Receiver pairs. See the Content Delivery Implementation Manual to learn which Senders and Receivers are required for which protocol.

FTP or SFTP

The File Transfer Protocol is the easiest to implement and also the fastest in most cases. However, your Web Application Server may not allow you FTP access for security reasons, which means that HTTP is the logical alternative.

A secure FTP connection, if possible, helps to prevent third parties from intercepting and reading your transported content.

SSHFTP

If you are allowed to use an SSH2 server on your Presentation Server, but not allowed to use an FTP server, SSHFTP (that is, SSH2 using a file transfer protocol subsystem) is a good choice.

HTTP or HTTPs

If you transport over HTTP or HTTPs, you will need a small Web application on the receiving end:

• If your Web Application Server is based on IIS or ASP.NET, you must create a Web site, put an ASP page on it and register a DLL.

• If your Web Application Server is based on Java, you must deploy a Web application (.war file) that contains a servlet to receive incoming content. A secure HTTP connection, if possible, helps to prevent third parties from intercepting and reading the content that you transport.

Local file system

If you are publishing to a machine that the Content Manager can access as a network drive, publishing to local file system is a (fast) option. (Note that the local in "local file system" refers to the local network, not to the local machine.) The local file system protocol is especially useful for publishing to an intranet.

Custom protocol

If you cannot use any of these protocols, a final option is to implement your own custom protocol to transport the content over. This advanced topic is described in "Creating a custom transport protocol" on page 39.

2.2.d

Customizing content deployment

When SDL Tridion R5 publishes content to a Presentation Server, the Content Deployer always unpacks the incoming Transport Package and processes the transport instructions included with the package.

(17)

Chapter 2 Im

plementi

ng Content D

istributi

on

You can configure what it does next. By default, it runs through a list of item types (Pages, Components and so on) and for each type, it deploys all the items in the package. "Deploying" here means sending them to the Content Broker for further processing. Each step of the deployment process is called a Module, and the deployment process as a whole is called a Processor.

You can change this default behavior of the Content Deployer in several ways: • You can create a custom Module and add it to the Processor

• You can extend an existing Module

• You can create a custom Processor (by extending the default one)

Custom Modules: flushing cache, updating search index

In general, you would implement a custom Module and add it to a Processor if you want to do something more than simply storing the content in your data store. For example, you can use a custom Module for the following tasks:

• flushing the cache (see "Caching incoming content" on page 11) • updating the search index (see "Integrating search" on page 20)

Extending an existing Module: adding metadata

The existing deployment Modules all perform a deploy or undeploy of all items of a certain type in the Transport Package. If you want to add certain information to items of a specific type, you can extend an existing Module.

The most common reason for extending an existing Module is to add custom metadata (for example, a keyword) to an item. A dynamic Web site uses custom metadata to filter Component Presentations (see "Implementing Dynamic

Component Presentations" on page 26).

Extending the Processor: Module interdependencies

You can also modify the deployment process as a whole by extending the

Processor class. By default, the Processor class simply feeds the entire contents of its Transport Package to each of its Modules, which take turns processing the Package.

You can implement most custom deployment functionality by extending or creating a Module. The only reason to extend the Processor itself is if there are interdependencies between two Modules.

For example, say that you want to add the metadata of a Structure Group to each of the Pages contained in this Structure Group, or, similarly, add all Folder

metadata to the Components in that Folder. In both scenarios, the result of one Module analyzing one item type (Structure Groups or Folders) must be fed into another Module for another item type (Pages or Components). Such

interdependence of Modules calls for a custom Processor, which communicates data between Modules.

2.2.e

Configuring where to store incoming content

The Content Broker can store incoming content in a number of different places. However, not all types of content can be stored in all types of storage locations.

(18)

Chapter 2 Implementing Content Distribution

Storing all content in a Web folder

By default, the Content Broker stores all content in the Default Root Location, a configurable disk location in the Content Broker configuration file. If you set this disk location to a Web Folder, the Content Broker stores all your content in that Web folder. Only Categories and Keywords cannot be scored in a Web folder. The benefit of storing all your content in a Web folder is that all your data is in one location. But the drawback is that everything you publish, including, for example, metadata, is accessible through the Web site.

Storing Web content in a Web folder and other content in a normal file folder

As Table 2-2 shows, you only need to store rendered Pages, binary data and Component Presentations with scripting in a Web folder. All other types of content can be written to a data store.

One possible data store is the local file system, that is, a location on disk that is not a Web folder.

In this scenario, you do not use one Default Root Location, but rather, you make a distinction between your Web folder (known as the Document Root), where you store Web content, and your normal file folder (known as the Data Root) where you store other types of content.

The benefits of using the local file system for storing non-Web content is that this content is now no longer directly accessible through the Web site. A drawback of using the local file system for storing non-Web content is that it is often slow.

Storing Web content in a Web folder and other content in a database

Instead of storing non-Web content on the file system, you can also store your non-Web content in a relational SQL-type database. This can speed up your Web site considerably, and you can use the database to store Categories and Keywords. Consult Table 2-2 to learn which types of content you can store in a database. Then consult the Broker Bindings in the Content Broker configuration file and the

Content Delivery Implementation Manual to learn how to store content in your

database.

Table 2-2 Types of content and where to store them

Item type In Web Folder In a normal file folder In database Rendered Pages D U U

binary data (images, PDFs) D U U

Any Component Presentation with scripting D U U

Static Component Presentation without scripting D D D

Dynamic Component Presentation without scripting D _Da _U

(19)

Chapter 2 Im

plementi

ng Content D

istributi

on

2.2.f

Caching incoming content

To speed up your Web site, you may want to implement object caching (caching for short). Caching stores the most commonly used objects in the cache.

SDL Tridion R5 offers a default implementation (switched off by default) which works as follows:

• Policy: when the cache is full, the least recently used objects are removed from the cache.

• Features: when an item is removed from the cache, it is checked for dependencies to make sure that the cache is never out of sync.

• Cache Bindings: you can configure which types of items you want to cache by specifying Cache Bindings. By default, cache all types of items by following the sample CacheBinding fragment provided in the Content

Delivery Implementation Manual.

• Synchronization: if, say, your Deployer and Broker run on different virtual machines, you can start a Cache Channel Service to make cache

synchronization across virtual machines possible, or use JMS to synchronize caches.

Some application servers require that you flush the content cache after you deploy new content. To do this, you can build a custom Cache Flusher Module and add it to the Processor of the Content Deployer. The Content Delivery Implementation

Manual explains how to do this.

Refer to the Content Delivery Implementation Manual, specifically the Content Broker API reference, for more information about object caching and flushing, and how to configure it.

Metadata D D D

Categories and Keywords U U D

Link information D D D

a.Your Application Server may restrict where the Broker can store the Dynamic Component Presentation. For example, Tomcat demands that you store the Dynamic Component Presentation in a folder that Tomcat can access.

Table 2-2 Types of content and where to store them

Item type In Web Folder In a normal file folder In database

(20)

Chapter 2 Implementing Content Distribution

2.3 Content Distribution implementation plan

To implement Content Distribution, go through the following steps:

Table 2-3 Content Distribution implementation plan Implementation Step Description

1 Set up Presentation Server Choose and install a machine to use as a Presentation Server. This machine must be a Web Application Server. See the Installation Manual for details.

2 Set up data store Choose and, if necessary, install a data store in which the Presentation Server can store its content. See the Installation Manual for details.

3 Configure publishing In the Content Manager, specify where you want to publish content to by defining a

Target Type and a Publication Target for this Presentation Server. See the Content

Delivery Implementation Manual for details.

4 Configure Transport Service In the Content Manager, configure the Transport Service. See the Content Delivery Implementation Manual for details.

5 Configure Deployment On the Presentation Server, configure content deployment, possibly adding customized deployment behavior. See the Content Delivery Implementation Manual for details.

6 Configure Brokerage On the Presentation Server, configure both the storage and caching of content in the Content Broker configuration file. See the Content Delivery Implementation Manual for details.

7 Test Content Distribution Test Content Distribution by publishing content from the Content Manager and verifying that it appears on a Web page on the Presentation Server.

(21)

Chapter 3 Developing the Web

site

This chapter explains how to develop a Web site that is based on content managed in the Content Manager.

SDL Tridion R5 allows for the development of many different types of Web sites, from purely static (HTML only) to purely dynamic (all content assembled from the database). To help you design your Web site, four different Web site models are presented here, with benefits and drawbacks for each model.

Finally, the chapter describes how to integrate common Web development functionality (such as search and navigation) in the Content Manager.

3.1 Web site development concepts

This section presents a number of Content Delivery concepts that are relevant to the development of an SDL Tridion-based Web site.

3.1.a

Content Manager items and Web site items

A Content Manager Publication contains different items than the resulting SDL Tridion-based Web site. When you publish content, items in the Content Manager combine to form the content of the Web site.

Here is an overview of which items exist in the Content Manager and how they produce Web content.

• Components are the basic building blocks of Web content. They represent the content (without look & feel) of a part of a Web page.

• Component Templates visualize (some or all of) the content contained in a Component. Component Templates can also include scripting that adds dynamic behavior to the Component.

(22)

Chapter 3 Developing the Web site

Components and Component Templates combine to form Component

Presentations, fragments of HTML and possibly script code, that can be part of a Web page.

• Pages are used to produce Web page on the Web site. A Page almost always contains one or more Component Presentations.

• Page Templates visualize Pages to produce Web pages. A Page Template may contain a database query that results in a set of Component

Presentations being added to the Page.

• Structure Groups are containers for Pages. They correspond to Web folders on the Web site and may also be used in the automatic generation of menus.

3.1.b

Web site models

When you design your Web site, one of the main questions to consider is how dynamic you want the Web site to be. The answers to that question depends on what you want to do with the content you manage in the Content Manager. This section shows you four increasingly dynamic Web site models:

Note Many sites will combine the Static ASP/JSP and DCP models: all Component Presentations are saved separately in the data store. Some are retrieved directly, while others are collected on the basis of a database query.

The four Web site models are at various points on the static-dynamic spectrum, as Figure 3-1 illustrates.

Figure 3-1 Static-dynamic spectrum Table 3-1 Web site models

Model Description

Static HTML The data store contains fully generated Web pages. All the Web site needs to do is retrieve a Web page from the data store and show it to the Web visitor.

Static ASP/JSP Web pages refer to a specific set of Dynamic Component Presentations. These Component Presentations are stored in the data store and retrieved when a visitor visits the Web page. Dynamic Component

Presentation Model (DCP Model)

Web pages retrieve Dynamic Component Presentations from the data store based on a database query on the Page.

Application Model The entire Web page is assembled by a custom Web Application that you develop. Publishing simply puts pieces of content into the Broker data store, but provides no structure of any kind.

(23)

Chap

ter 3

D

e

v

e

lop

ing

the W

e

b site

3.1.c

Linking

In the Content Manager, authors can create links to Components. You use Linking to transform these Component Links into actual hyperlinks to Web pages. Linking serves two purposes:

• If the target of the Component Link is not present on the Web site, Linking removes the link (and, optionally, also the link text).

• If the Component Link is ambiguous (that is, if the link points to a Component that appears on more than one Web page), Linking chooses which Web page to link to.

Priority

To determine how Linking resolves ambiguous links, you can use priorities. You set priority in a Component Template. The Component Template combines with a Component to create a Component Presentation. Linking always causes a hyperlink to point to the Component Presentation with the highest priority. Linking resolves all internal links within your Web site.

Dynamic Component Linking

If a link points to a Component that is not embedded on any Web page, but only appears as the result of a database query, the Component Link you create will by default always be considered dead.

To resolve these Dynamic Component Links, you must construct a Page that accepts two parameters:

• The URI (unique identifier) of a Component • The URI of a Component Template

The Page combines the Component and the Component Template to produce a Component Presentation, and displays this Component Presentation.

If Linking finds the target Component in the database, you can then pass the URIs of the Component and Component Template to the Page to display the Component you linked to.

3.2 Web site development decisions

Before you start developing your Web site, you must make a number of decisions: • In which scripting language do I develop my Web site?

• Which Web site model or models do I choose to develop? • Do I use static or dynamic navigation?

(24)

Chapter 3 Developing the Web site

3.2.a

Choosing a scripting language

Content Delivery currently supports the following scripting environments for your SDL Tridion-based Web site:

• JSP

• ASP VBScript • ASP JScript • ASP.NET

The choice of scripting language depends on what kind of expertise your Web developers have.

3.2.b

Choosing a Web site model

To decide on a Web site model, consider the following rules of thumb:

• The more you reuse content, the more dynamic your Web site should be. • The more often you update your Web site, the more dynamic your Web site

should be.

• The bigger your Web site, the more dynamic your Web site should be. • The more resources you have at your disposal (both human resources and

hardware resources), the more dynamic your Web site can be.

Static HTML model

In the static HTML model, Web pages containing specific Component Presentations are generated at publish time. The Web pages may contain scripting.

Table 3-2 Benefits and drawbacks of the static HTML model Benefits Drawbacks

• The Web site puts minimal load on the Web server, because the Web server can directly retrieve the entire page in HTML from the Web site itself and present it to the visitor.

• Maintenance is easy because the Web site is ready and assembled. The site is easy to host and can use proxies.

• Updating the Web site can take a long time because one change in the content can mean regenerating enormous amounts of Web pages. The more content you have, the longer it will take.

• While the site is being published, it either has to go offline or be inconsistent (the Web visitor sees updated content on one Web page, and outdated content on another). • The site runs more risk of becoming

inconsistent, especially if you do not republish all the content every time you make a change.

(25)

Chap

ter 3

D

e

v

e

lop

ing

the W

e

b site

Static ASP/JSP model

In the static ASP/JSP model, Web pages containing specific Component

Presentations (known as embedded Component Presentations) are generated at request time. Each Component Presentation is stored individually in the data store and retrieved by a piece of script code on the Web page.

Dynamic Component Presentation model

In the Dynamic Component Presentation model, Web pages assemble Component Presentations from the data store through a process called Dynamic Content

Assembly.

Dynamic Content Assembly means that the Web page queries the metadata of Components and collects the results of that query on the page. For example, the page may query the publishing date of the Components to find the most recently published Components.

Table 3-3 Benefits and drawbacks of the static ASP/JSP model Benefits Drawbacks

• The pieces of content that are most reused on the Web site, such as the navigation, are published only once, and included on every Web page. • A Component always looks the same

on every Web page, because all these pages refer to the one Component Presentation in the data store. • The Web site does not need to go

offline when a Component has changed, because no new Pages need to be generated.

• The model puts a fairly heavy load on the Presentation Server's resources and requires more space in the data store.

• It is not possible to determine dynamically what a Web page will contain.

• More work is involved in maintaining the site.

Table 3-4 Benefits and drawbacks of the Dynamic Component Presentation model

Benefits Drawbacks

• You can create truly dynamic Pages, the content of which is not

predetermined.

• The model puts a heavy load on the Presentation Server's resources, and requires more space in the data store. • It is more difficult to predict which

content a Web page will contain exactly.

• More work is involved in maintaining the site.

(26)

Chapter 3 Developing the Web site

Application model

In the application model, all content is stored in the data store and assembled at request time.

Note Building a dynamic Web site according to the Application model is very much influenced by the specific Web site you are trying to build. Therefore, this Guide cannot explain this model in greater detail.

3.2.c

Dynamic navigation

If your Web site contains a lot of content, your navigation is likely to be

comparably large and can no longer be managed efficiently by hand. If this is the case, you can generate your navigation structure dynamically, based on

information in the Content Manager.

The benefit of dynamic navigation is that your navigation is never inconsistent. The drawback of dynamic navigation is that you must ensure that the organization of your content in the Content Manager corresponds with the navigation you want to display on the Web site.

3.2.d

Integrating search

SDL Tridion R5 does not include search functionality for your Web site. However, you can acquire a third-party search engine and integrate it with your Content Distribution implementation, so that your search index is updated as soon as new content is published to the Web site.

The benefit of integrating search into Content Distribution is that your search index is always up to date. You do not need your search engine to periodically crawl your Web site.

The drawback of integrating search is that it involves a certain development effort.

Table 3-5 Benefits and drawbacks of the Application model Benefits Drawbacks

• Maintenance of the Web site is easy and cost-effective.

• The model implements the "Model View Controller" design pattern, a software design principle that makes the three parts of a Graphical User Interface separate from each other. • You can use your Web Application

server to integrate the SDL Tridion content with other applications and/or systems.

• It is easier to implement profiling and personalization.

• This model requires a relatively high initial investment, in terms of both time and money.

• Developing a Web site according to this model requires more advanced development and design skills. • Editors have virtually no direct control

over the way in which content appears on the Web site.

(27)

Chap

ter 3

D

e

v

e

lop

ing

the W

e

b site

3.3 Web site development implementation plan

To develop a Web site for SDL Tridion R5 content, go through the following steps:

The following subsections provide more detail on the following implementation steps:

• Organizing content for navigation • Integrating search

• Writing queries for Dynamic Content Assembly • Implementing Linking

Table 3-6 Content Distribution implementation plan Implementation Step Description

1 Choose a scripting language Choose the scripting environment in which you want to develop the Web site.

2 Choose a Web site model Decide which Web site model(s) you want to develop.

3 Organize content for navigation (optional)

If you want to generate navigation

automatically, design a content organization that corresponds to the navigation you want to generate.

4 Install, implement and integrate search

Install and configure your third-party search engine.

If you want to integrate search into SDL Tridion R5, you can do so by creating a custom Deployer module.

5 Develop Component Templates and Page Templates

Create Component Templates and Page Templates that present the Components and Pages in the way that you want them to be displayed.

6 Write queries for Dynamic Content Assembly

(optional)

If your Web site model requires queries for Dynamic Content Assembly, create a Page Template that executes such a query and processes the results.

7 Customize Linking (optional)

SDL Tridion R5 ships with a standard implementation of Linking. You may wish to change the default behavior.

8 Publish Dynamic

Component Presentations (optional)

If the Web site model requires it, make Component Templates dynamic in order to create Dynamic Component Presentations.

9 Test the Web site Perform tests to verify that the site itself, as well as the search, hyperlinks and navigation, all work as expected.

(28)

Chapter 3 Developing the Web site

3.3.a

Organizing content for navigation

You can use information in the Content Manager to create a navigation menu on the Web site dynamically. There are several ways in which you can do this. Here is a possible implementation:

3.3.b

Integrating search

To allow Web site visitors to search your SDL Tridion R5-managed Web site, you need:

• third-party search software

• a search index that this search software can use

The best moment to update your search index is when new content enters the system. This saves you the time and effort of building a search index by crawling through the site at regular intervals. You can create an Update Search Index Module and add it to the Processor as the last Module.

The typical procedure for implementing search, then, is:

1 In the Content Manager, you organize your Pages in Structure Groups. Create a hierarchy of Structure Groups that corresponds to the menu hierarchy that you want to show on the Web site. The names of the Structure Groups should be the names of the menu items.

2 Create a metadata schema that contains a number field and use it to add metadata to each Structure Group. The number indicates the position of this menu item in the menu. For example, a Structure Group with metadata set to '400' appears below a Structure Group with metadata set to '300'.

3 Add the same metadata to the Pages of your Web site.

4 Create a "menu Page Template" to generate this menu. The menu Page Template navigates through the Structure Group hierarchy and the Pages in it, and creates a menu structure in the order specified by the metadata.

5 Create an empty Page and associate it with the menu Page Template. Use scripting in each of the various regular Page Templates to include this menu Page on each Page.

6 Use the SDL Tridion Event System to make sure that whenever a Page is (re)published, the menu is also republished.

1 Select and purchase third-party search software.

2 Create a custom Module (Java class) that adds items to the search index based on the content and/or metadata of Pages and/or Components. Most search software includes a Java interface; if yours does not, you can use the Java Native Interface (JNI) to communicate with your search software.

3 Add this Module to the Processor of your Content Deployer that actually deploys the content.

(29)

Chap

ter 3

D

e

v

e

lop

ing

the W

e

b site

Note The above procedure explains how to implement a free-form search interface in which the users enters a string and clicks a search button. For more structured searching (by picking items from a list, checking options and so on), refer to "Writing queries for Dynamic Content

Assembly" on page 21.

3.3.c

Writing queries for Dynamic Content Assembly

Normally, you add specific Component Presentations to a Page in the Content Manager and publish them to the Web site. The resulting Web page always shows the same Component Presentations.

In some cases, however, you may want to determine which Component

Presentations to pick based on dynamic criteria. For example, you may want to display the five most recently published Component Presentations, or all Component Presentations that have been marked 'sports'. This is known as Dynamic Content Assembly.

To implement Dynamic Content Assembly, you do not specify a fixed set of Component Presentations to add to a Page. Rather, you specify a query consisting of content criteria and then include (some or all) Components that meet those criteria. Using queries to select a number of Dynamic Component Presentations is known as filtering.

5 Add a search interface to your Page Template(s) that uses the search software to perform the filtering for you.

6 Test to see if search works to your satisfaction.

Important:

Any query you produce can only examine the metadata of a Component Presentation. It cannot look at the actual content.

To implement Dynamic Content Assembly:

1 Decide what type of filter you want to make. Some typical types of filters are:

• Related Items filter: select Component Presentations based on one or more Keywords.

• Most Visited Components filter: select Component

Presentations based on the number of times they were accessed (this requires implementation of Tracking, see Chapter 5 "Profiling

and personalization" on page 31).

• Most Recently Published Components filter: select

Component Presentations based on their Initial Publication Date. Note Do not use Dynamic Content Assembly to create a search

filter. Use a third-party search application instead, as it is optimized for speed.

(30)

Chapter 3 Developing the Web site

3.3.d

Implementing Linking

Linking resolves all internal links on your Web site.

Linking requires you to obtain and install a Linking license key (see the Installation

Manual for more details).

SDL Tridion R5 ships with a standard Template Building Block that implements a default implementation of Linking, so that your links are resolved without any coding on your part.

The behavior of this default implementation is as follows:

• Dead links: If a hyperlink points to an item that does not exist, the hyperlink itself is removed, but the text of the link is still displayed.

• Ambiguous links: If a link in the Content Manager points to a Component that can be found on more than one Page, the hyperlink on the published Page will point to the Page is that is 'nearest' the referring page. Refer to the

Content Delivery Implementation Manual to learn the details of this

behavior.

You may decide to change this behavior.

As for dead links, you can configure on a per-link basis whether you want the text of the dead link to be displayed on the Page or not. See the Content Delivery

Implementation Manual, specifically the Linking API reference documentation, for

details.

2 If the type of information you are filtering on is not included in the standard metadata of a Component, create custom metadata (for example, Categories and Keywords) for this information.

3 Publish the Component Presentations you want to filter on as Dynamic Component Presentations.

4 Create a Page Template that uses the Query class to create a query, and the SearchFilter class to execute it. Refer to the Broker API

documentation for more information.

The query returns an array of Component URIs. Combine these

Components with a Component Template of your choice to produce the Component Presentations you want to show.

Note Be sure to handle the eventuality that the query returns no results at all.

5 You can configure the results of the query in the following ways: • You can restrict the number of Components to a specific number. • You can sort the result on a specific metadata field.

• You can specify a sort direction (ascending/descending).

6 Create a Page without adding any Component Presentations to it, and associate it with the Page Template you just created.

7 Publish this Page and examine the result on the Web site. To implement Dynamic Content Assembly: (Continued)

(31)

Chap

ter 3

D

e

v

e

lop

ing

the W

e

b site

As for ambiguous links, you can use priorities to determine which Page a link will point to. You set priority in a Component Template. The Component Template combines with a Component to create a Component Presentation. Dynamic Linking always causes a hyperlink to point to the Component Presentation with the highest priority.

The following rule for setting priorities usually produces the best results: The Component Template that displays more Component content has higher priority.

For example, suppose that you have two Component Templates for a news article Component. One Component Template shows only the headline of the news article, and the other Component Template shows the entire article, including images. By giving the 'full content' Component Template a higher priority, links to this Component will now always point to the longer version.

(32)

(33)

Chapter 4 Implementing dynamic

functionality

Depending on the dynamic model you wish to implement (see "Web site

development concepts" on page 13), implementing dynamic functionality involves

one or more of the following tasks: • Implementing search

• Implementing dynamic navigation

• Implementing Dynamic Component Presentations • Implementing Dynamic Linking

• Implementing Dynamic content assembly

The following subsections provide an overview of the implementation of each of these features.

Apart from planning which feature to implement, there is also the technical decision of which scripting environment to use.

4.1 Implementing search

To allow Web site visitors to search your SDL Tridion-managed Web site, you need:

• third-party search software

• a search index that this search software can use

The best moment to update your search index is when new content enters the system. This saves you the time and effort of building a search index by crawling through the site at regular intervals. You can create an Update Search Index Module and add it to the Processor as the last Module.

The typical procedure for implementing search, then, is: 1 Select and purchase third-party search software.

(34)

Chapter 4 Implementing dynamic functionality

Note This procedure explains how to implement a free-form search

interface in which the users enters a string and clicks a search button. For more structured searching (by picking items from a list, checking options and so on), refer to "Dynamic Content Assembly" on page 28.

4.2 Implementing Dynamic Component Presentations

There are various reasons for publishing Dynamic Component Presentations: • To make Dynamic Linking possible (see "Implementing Dynamic Linking" on

page 27).

• To make Dynamic Content Assembly possible (see "Dynamic Content

Assembly" on page 28).

• To speed up the publishing process and improve the Web site consistency (explained in this section).

If one Component Presentation appears on many static Web pages, republishing the Component causes all of these pages to be regenerated and republished. This is a problem for various reasons:

• It slows down the publishing process.

• It creates Web site inconsistency: during publishing, one page may show the updated Component Presentation, while another shows the outdated Component Presentation.

• It takes up disk space: copies of the same Component Presentation occur in multiple Web pages.

To solve this problem, you can implement Dynamic Component Presentations. SDL Tridion R5 publishes Dynamic Component Presentations to the Content Broker data store, but does not embed them on a Web page. If you add a Dynamic Component Presentation to a Page, SDL Tridion R5 does not insert the contents of the Dynamic Component Presentation. Rather, SDL Tridion R5 now inserts a piece of script code to the Page. This script code retrieves the Dynamic Component Presentation from the data store when the Page is visited.

Using benefits of this approach are:

• Publishing is faster, because SDL Tridion R5 does not need to republish Pages when a Dynamic Component Presentation changes.

2 Create a custom Module (Java class) that adds items to the search index based on the content and/or metadata of Pages and/or Components. Most search software includes a Java interface; if yours does not, you can use the Java Native Interface (JNI) to communicate with your search software.

3 Add this Module to the Processor of your Content Deployer that actually deploys the content.

4 Build up a search index by adding content to your Web site’s data store. 5 Add a search interface to your Page Template(s) that uses the search

software to perform the filtering for you. 6 Test to see if search works to your satisfaction.

(35)

Chap

ter 4

Im

plemen

tin

g

dynam

ic fu

nctio

n

alit

y

• The Web site is consistent at all times, because all Pages refer to one and the same Dynamic Component Presentation.

• Less disk space is used, because there is now only one instance of the Dynamic Component Presentation, and it resides in the Content Broker database.

The disadvantage of using Dynamic Component Presentations is that you need a faster Web server and/or faster data store access, because the page is created 'on the fly'.

Refer to the Content Delivery Implementation Manual for details on how to publish Dynamic Component Presentations.

4.3 Implementing Dynamic Linking

In the Content Manager, authors can create links to Pages, Components and Multimedia Components. By implementing Dynamic Linking, you can resolve those links dynamically on the published Web site. Dynamic Linking requires that you store data in a SQL-type database (rather than publish content to a local file system).

Using Dynamic Linking has the following advantages:

• By default, the published Web site does not contain dead links to items within the site, because dead links are not displayed.

• The Content Manager author can create a link to a Component and rest assured that on the published Web site, the link will point to a page that contains the Component.

To learn more about implementing Dynamic Linking, refer to the Content Delivery

Implementation Manual.

4.4 Implementing dynamic navigation

Because your navigation appears on virtually every page of your Web site, changing the navigation in a static Web site model causes every page of the site to be republished. Additionally, if the navigation part of the page contains is scripted (for example, it is a DHTML tree), every page must re-execute the same DHTML code again and again.

A dynamic Web site can solve these problems by allowing you to perform a server-side include of the navigation on every Page.

The most common way of implementing dynamic navigation is to create a special Page Template that collects all the information needed to generate the navigation menus. This usually means copying the tree structure of the Publication's

Structure Groups down to some level.

The Page Template is then applied to an empty Page, so that the result is a 'navigation Page' that can be included in any published Web Page.

(36)

Chapter 4 Implementing dynamic functionality

4.5 Dynamic Content Assembly

Normally, you add specific Component Presentations to a Page in the Content Manager and publish them to the Web site. The resulting Web page always shows the same Component Presentations.

In some cases, however, you may want to determine which Component

Presentations to pick based on dynamic criteria. For example, you may want to display the five most recently published Component Presentations, or all Component Presentations that have a certain Keyword set to 'sports'. This is known as Dynamic Content Assembly.

To implement Dynamic Content Assembly, you do not specify a fixed set of Component Presentations to add to a Page. Rather, you specify a query consisting of content criteria and then include (some or all) Components that meet those criteria. Using queries to select a number of Dynamic Component Presentations is known as filtering.

Important:

Any query you produce can only examine the metadata of a Component Presentation. It cannot look at the actual content.

To implement Dynamic Content Assembly:

1 Decide what type of filter you want to make. Some typical types of filters are:

• Related Items filter: select Component Presentations based on one or more Keywords.

• Most Visited Components filter: select Component

Presentations based on the number of times they were accessed (this requires implementation of Tracking, see Chapter 5 "Profiling

and personalization" on page 31).

• Most Recently Published Components filter: select

Component Presentations based on their Initial Publication Date. Note Do not use Dynamic Content Assembly to create a search

filter. Use a third-party search application instead, as it is optimized for speed.

2 If the type of information you are filtering on is not included in the standard metadata of a Component, create custom metadata (for example, Categories and Keywords) for this information.

3 Publish the Component Presentations you want to filter on in

combination as Dynamic Component Presentations (see "Implementing

(37)

Chap

ter 4

Im

plemen

tin

g

dynam

ic fu

nctio

n

alit

y

4 Create a Page Template that uses the Query class to create a query, and the SearchFilter class to execute it. Refer to the Broker API

documentation for more information.

The query returns an array of Component URIs. Combine these

Components with a Component Template of your choice to produce the Component Presentations you want to show.

Note Be sure to handle the eventuality that the query returns no results at all.

5 You can configure the results of the query in the following ways: • You can restrict the number of Components to a specific number. • You can sort the result on a specific metadata field.

• You can specify a sort direction (ascending/descending).

6 Create a Page without adding any Component Presentations to it, and associate it with the Page Template you just created.

7 Publish this Page and examine the result on the Web site. To implement Dynamic Content Assembly: (Continued)

(38)

(39)

Chapter 5 Profiling and

personalization

As a part of creating your Web site, you may want to find out how your Web site visitors interact with your content. This is known as profiling.

Profiling gives answers to the following questions:

• Which Page or Component is popular with a specific user? • Which type of content is popular among which types of users?

When you have collected this information, you may then want to use these results to show each visitor content that is tailor-made to his or her personal preferences. This is known as personalization.

To improve this personalization, you may also want to include additional information about your visitors. Such additional information may come from a consumer database, for example, or from a form on your Web site.

By offering a Web visitor a more personalized experience, you increase the likelihood of the visitor staying on your Web site longer and of visiting again later.

5.1 Profiling and personalization concepts

To perform profiling, you can use Tracking, Tracking Keys, Categories and Keywords.

Tracking

Tracking measures which content a visitor accesses during a specific period of time.

Tracking Keys, Categories and Keywords

Tracking Keys measure which types of content are accessed; that is, which Components and Pages are requested and which Component links are or are not clicked.

To implement Tracking Keys, you must analyze your (existing and planned) content to determine the types of content you offer. You define these content types in Categories and Keywords, which content authors then use to categorize the content they produce.

(40)

Chapter 5 Profiling and personalization

Target Groups

You can choose to hide or show content for a specific visitor (personalization) based on their membership of a Target Group. Membership of a Target Group depends on a combination of the following criteria:

• Customer Characteristics: these are properties of your customers that you have collected in some way and stored in the Broker database. For example, if your Customer Characteristics include the user’s age, you can specify that this Target Group should only contain users in the 19-to-24 age bracket by saying that the Age property must have a value larger than 18, and lower than 25.

• Tracking Keys: these are the Keywords whose popularity you have been measuring. Tracking Keys have a numerical value that represents how often the user looked at that specific type of content. For example, you might specify that this Target Group should only contain users for whom the value for 'Sports' is higher than 100 (indicated a strong interest in sports).

5.2 Profiling and personalization implementation decisions

To make profiling and personalization work, it is important to first consider what you want to do with the data you collect, and how much additional information you can provide about the people who visit your Web site.

The decisions to make are:

• Do you want to implement Tracking profiling (that is, collect data about which content is accessed by which visitors)?

• Do you want to implement Tracking Keys profiling (that is, collect data about which type of content is accessed by which visitors)?

If you implement Tracking Keys profiling:

Which Categories and Keywords do you want to define to categorize your content?

Which weight do you want to assign to a visitor accessing or not accessing a specific type of content?

• Do you want to implement personalization? If you implement personalization:

Which kinds of Target Groups do you distinguish among your Web site visitors?

When you create Target Groups, do you want to involve external data about the people who will be accessing your Web site?

5.2.a

Choosing to implement Tracking

Tracking gives you basic measurements about which parts of your Web site are popular and which are less popular. You can choose to modify, add or remove content from the Web site based on these measurements, or to make content more prominent (for example, by moving a Component to the Web site's front page).

Content Management Implementation Guide 5.3 SP1

Content Management

Implementation Guide

5.3 SP1

Content Management

Implementation Guide 5.3 SP1

©

Preface

About this Project Planning Guide

How to use this guide

Content Delivery Project Planning Guide 5.3 SP1

Related documents

Version history

Table of contents

Content Delivery Project Planning Guide 5.3 SP1

Chapter 1 Content Delivery

1.1

Content Delivery concepts

Chapter 1 Content Delivery

1.2

Implementation plan

1.3

Licensing

Chap

ter 1

C

o

n

tent Deliv

e

ry

Chapter 2 Implementing Content

Distribution

2.1

Content Distribution concepts

Chapter 2 Implementing Content Distribution

2.2

Content Distribution implementation decisions

Chapter 2 Im

plementi

ng Content D

istributi

on

2.2.a

Choosing the Web Application Server technology

2.2.b

Choosing a type of data store

2.2.c

Choosing a transfer protocol

Chapter 2 Implementing Content Distribution

2.2.d

Customizing content deployment

Chapter 2 Im

plementi

ng Content D

istributi

on

2.2.e

Configuring where to store incoming content

Chapter 2 Implementing Content Distribution

Chapter 2 Im

plementi

ng Content D

istributi

on

2.2.f

Caching incoming content

Chapter 2 Implementing Content Distribution

2.3

Content Distribution implementation plan

Chapter 3 Developing the Web

site

3.1

Web site development concepts

3.1.a

Content Manager items and Web site items

Chapter 3 Developing the Web site

3.1.b

Web site models

Chap