Content Management Systems

359
CHAPTER 15
Content Management
Systems
O
NE OF THE MOST COMMON
uses of a portal is to provide an interface to content
management systems (CMSs). Some users may need to get information from the
CMS, while others may need to create content. Many portals integrate with a CMS
from the same vendor—sometimes the portal ships with the CMS, and in other
cases it is a separate product. If you do not have a vendor-supplied integrated solu-
tion, you will probably need to develop one using the portlet API and a CMS API.
In this chapter, we discuss the Java Content Repository API (JSR 170), and the
WebDAV protocol. We also build a portlet that uses WebDAV to connect to a content
store—in this case, the open source CMS Apache Slide (
/>slide
). Our portlet should work with any WebDAV server, so you can use your
own CMS if it supports WebDAV.
Overview of Content Management Systems
Content management is a broad field that encompasses a wide range of software
applications. Document management, imaging, product data management, digital
media and asset management, knowledge management, and web content man-
agement are some of the different types of content management systems. Usually,
all of these different systems are grouped together into a field called enterprise
content management.
From a technical perspective, many of these systems share a common base of
functionality and features. All of them have a content repository, where content
is stored on a database or file system. Most systems use some kind of hierarchical
organization for the content, although you will certainly find CMS applications
where all of the content is at the same level. Most CMS packages with a hierarchical
view actually store all of the content in a single database table or directory. The

relationships for the hierarchy are stored in the database. This provides advantages
for access and retrieval, and allows the same piece of content to appear in two or
more different locations.
The next piece of the CMS puzzle is content delivery. Most web content man-
agement packages are optimized for content delivery, and can easily be plugged
2840ch15.qxd 7/13/04 12:44 PM Page 359
Download at Boykma.Com
Chapter 15
360
into a web-based application. In some cases, part of the vendor-provided content
delivery is a display portlet that can save you a lot of development effort. One
disadvantage of CMS tools with content delivery is that they often include page
assembly features, for delivering a web page with navigation, headers, and footers.
This is not very useful from a portal perspective, where the portal page provides
the interface. Usually there is a way to access the raw content directly, without any
of the page assembly.
A common use of content management systems is to introduce workflow
into the content production process. A classic business use case for a CMS proj-
ect involves a content producer creating a Microsoft Word file locally and then
uploading it into the CMS. His manager gets a review notice through e-mail and
logs into the CMS. The manager approves the content inside the CMS, and the
content is ready for delivery. Most enterprise CMS applications will have workflow
or an approval process for publishing built-in. The level of automation and custom
development varies from CMS to CMS. Sometimes it can be very easy to create
a complex content review process that turns out to be unwieldy for the end user
in practice. Bottlenecks will start to appear, especially with different levels of
approval. Creating a “ready for review” portlet for a CMS is usually a straightfor-
ward development project involving a proprietary API.
Content production and authoring is a newer technology that has become
more popular with the availability of rich text or HTML authoring controls for web

pages. These content-creation tools could be Java applets, ActiveX controls, DHTML,
Flash, or any other client-side technology. Some CMS applications come with
these as part of an authoring workspace. The rapid adoption of WebDAV in desk-
top applications means that these controls may not be the best solution for
your users, especially if they are already familiar with tools like Macromedia
Dreamweaver MX. It is easy enough to embed one of the client-side HTML author-
ing tools into a portlet—saving the HTML onto the server will depend on the CMS.
Personalization is a feature that somewhat overlaps with portals. Your content
management system may support varying levels of personalization, some of which
may coincide with your portal vendor’s personalization product. If you have to
choose between the two, the portal’s personalization will work for other applica-
tions running on the portal, but the CMS personalization will be portable across
multiple portals. Ideally, future versions of the portlet API will standardize person-
alization, so this will become less of a problem.
Almost every CMS includes some level of search support, whether it is a simple
SQL query interface or an integrated search engine like Verity or Lucene. The Java
Content Repository API defines a standard for queries and query languages that
should gain support from Java-based CMS vendors. The trickiest part of external
search engine integration with a CMS and a portal will be indexing the CMS prop-
erly. If your site includes multiple user groups with different access to content,
you should consider a federated search approach, as we described in Chapter 10
for Lucene. Commercial search vendors will have their own recommendations, and
will probably offer ready-made JSR 168 portlets either now or in the near future.
2840ch15.qxd 7/13/04 12:44 PM Page 360
Download at Boykma.Com
Content Management Systems
361
Integration with a Content Management System
Most portal deployments require integration with at least one content management
system; often, integration with several different vendors’ systems is necessary. From

a project management perspective, bringing content into a portal requires several
steps. The first is to identify which content should be available and where the
content is coming from. The next step is to determine which sets of users should
see which content. The third step involves identifying which functionality in the
content management system belongs in a portlet. After these business process
steps are completed, you can start planning the technical architecture of the
integration—does the vendor provide a JSR 168 portlet already? Many vendors
write portlets for their content management systems, which can make your job
much easier. Two commercial vendors with JSR 168 portlets at the time of writing
are Stellent and Documentum; other vendors likely have products on the way. If
you do not have a ready-made portlet application to roll into your application, you
are going to need to look into the integration APIs for the content manage-
ment system.
There are two major standards for CMS APIs: WebDAV and the new Java
Content Repository API (JSR 170). WebDAV is a set of extensions to the HTTP
protocol for versioning, accessing metadata, making directories, locking files, and
checking files in and out, among other things. WebDAV is not tied to a single
platform or architecture, although the CMS must specifically implement a WebDAV
layer. The Java Content Repository API (JCR API) is a new standard for Java content
management systems. The JCR API defines a standard set of interfaces and classes
that CMS clients can use to connect to a CMS and access content and metadata.
We discuss both WebDAV and the JCR API in this chapter.
Neither of these APIs covers all of the possible functionality for a CMS. In
addition, not every CMS implements one of these APIs—most will have a separate
proprietary API, which you will have to implement yourself. If there are any
servlet/JSP example applications, they should be easily adapted to a portlet
application.
You can pull content out of almost any content management system through
its database or file system store, but that should be a last-ditch integration step.
Of course, if your CMS is 10 years old, running on a legacy platform, and does

not have an open API, this may be your only choice. It is probably better at that
point to migrate the legacy CMS to something newer, but for lots of reasons that
may not make business sense.
Common Problems with CMS and Portals
Some of the most common technical problems with CMS integration with portals
are authentication, access control, link rewriting, and content delivery. We can
manage authentication with Single Sign-On (SSO) functionality, which we discussed
2840ch15.qxd 7/13/04 12:44 PM Page 361
Download at Boykma.Com
Chapter 15
362
in Chapter 8. If the application is not suitable for SSO, you can collect the correct
CMS credentials from the user once, and then store them in the user’s portlet
preferences.
Access control partly comes from SSO, especially if you have an enterprise-wide
set of permissions for your portal and your CMS. If all of your access control is
maintained in one directory, you can cut down on technical support, but your
software development costs for integration will be huge. If you do not have an
enterprise access control system, most content management systems will only
display content that the user has access to. You will have to manage the permis-
sions yourself, either programmatically or through an administrative GUI.
Link rewriting is another common problem. The links in your CMS content
will not stay in the portal. You could write a set of content display adapters that
rewrites your HTML content with the appropriate portlet URLs for links. Another
approach would be to standardize on an enterprise-wide XML format for content.
Each content delivery or content authoring system would be responsible for ren-
dering the XML correctly for display in that system, but creating the correct links
would be easy.
Any content that relies on JavaScript will probably not work, unless the
JavaScript is completely contained in the piece of content. Because you may

want to use the content in more than one location, you probably do not want
JavaScript embedded in your content. Convince your content producers that
they do not need to use scripts—one way to encourage this is to provide support for
custom HTML or XML tags, such as
<PrinterFriendly>
,
<PopupWindow>
,
<DynamicMenu>
,
or similar tags. Your content delivery applications would render these tags in the
appropriate manner for display, or ignore them altogether. This puts more control
on the systems side, and takes control away from the content creators. Portals
especially need this type of control over content because the content needs to
appear in a portlet.
You will have to determine how content delivery through a portal will work.
You could display all of your content in new browser windows that open up out-
side of the portlet window. If you take this path, your CMS portlets would open
links to web applications that display the content correctly, with working links,
styles, and images. Another approach is to display HTML or XML content inside
the portlet, and rewrite the links to any binary data such as PDF files or images
to use a servlet for access. Your portlet cannot stream binary data to the user’s
web browser directly, so an approach like this is necessary. You could also look
into ActiveX controls for PDF files, Microsoft Office files, and the like.
Java Content Repository API (JSR 170)
The Java Content Repository API (JCR API,
www.jcp.org/en/jsr/detail?id=170
)
is a common interface to content management systems, just like the portlet API is
a common interface for portals. The JCR API is Java Specification Request 170

2840ch15.qxd 7/13/04 12:44 PM Page 362
Download at Boykma.Com
Content Management Systems
363
(JSR 170), and at the time of this writing, it was in public review. Similar to the
portlet API, the motivation for the JSR 170 standard was that each CMS vendor
used a different API. Writing applications on top of these proprietary APIs was
difficult because the application ran only on one CMS or because porting and
maintaining compatibility required lots of development resources. Imagine try-
ing to build an application (for instance, a search engine) that ran on a number
of portals and used several different content management systems. Then imagine
supporting that application for all the combinations of systems your customers
might have.
The advantage of the JCR API is that more applications can take advantage
of content management systems—the barrier to entry is lower, and there is less
worry about proprietary lock-in. A client application does not have to know the
details of how the JSR 170 implementation works on the content management
system. The JCR API does not specify a client/server protocol. Because some CMSs
organize content in a hierarchy of folders and content items, and others organize
content in a flat set, the JCR API can use either type of structure.
The JCR API does not cover all of the possible functions of a content man-
agement system. The standard covers the most common functionality for
a content repository, but does not include such areas as personalization, pub-
lishing, workflow, or taxonomies. There are two levels of the JCR API. The first
level is Level 1, and it includes basic content repository functionality. The main
features it includes are
• Retrieving content
• Writing content
• Removing content
• Serializing content

• Searching content
• Changing and retrieving different content types
The more advanced functionality is grouped into Level 2. Level 2 is not
required because not every CMS needs that level of complexity. The advanced
features in Level 2 are
• Transactions
• Versions
• Observation
2840ch15.qxd 7/13/04 12:44 PM Page 363
Download at Boykma.Com
Chapter 15
364
• Access control
• Locks
JCR API Concepts
The JCR API uses several key classes for access to most of the content repository
functionality. These classes model the content management system’s internal
structure, but building this API on top of a legacy CMS may be difficult. Some of
the JCR API classes may not be a one-to-one match for existing classes, and some
of the APIs and key concepts might be implemented differently in the CMS.
You should understand how the concepts described next map onto your CMS,
especially noting which functionality is unavailable through the JCR API.
Repository
The
javax.jcr.Repository
interface models a Java content repository. The reposi-
tory represents all of the content, relationships, and metadata in the content
management system. The content repository contains content workspaces. Your
portlets will ask this class for a ticket that represents access to a workspace for
an authenticated user. The repository will need a valid set of credentials for the

user.
Ticket
Tickets map authenticated users to workspaces. Ticket objects implement the
javax.jcr.Ticket
interface. A ticket maps to a single workspace. Each ticket pro-
vides access to the repository for the user, but the ticket will keep any changes
queued until the portlet either reverts or saves the changes.
Credentials
The
javax.jcr.Credentials
interface represents the user authentication information
for the user. If the credentials are valid, the repository will return a valid ticket
that grants access to a workspace. Your CMS will implement the interface with
whatever information it needs to grant access—this will usually include a user-
name and password, and could include a group or a domain, or other custom
authentication attributes.
2840ch15.qxd 7/13/04 12:44 PM Page 364
Download at Boykma.Com
Content Management Systems
365
Workspace
Use the
javax.jcr.Workspace
interface to get access to a content workspace. The
repository holds one or more workspaces. Each workspace has a tree of items,
which are organized under a root node.
Each
Workspace
object for an authenticated user maps to a
Ticket

object.
Item
The
javax.jcr.Item
interface is the base class for nodes and properties. The
workspace consists of a tree of items.
Node
Nodes represent individual entities in the content management system, and are
implementations of the
javax.jcr.Node
interface. They could be pieces of content,
folders, documents, products, or anything else. Each node can have zero or more
child nodes. With CMS support, nodes may also have more than one parent node.
Nodes can have zero or more properties.
Each node has one primary node type, but can also have multiple mixin node
types. Mixin types describe additional information about a node, beyond its pri-
mary node type. Each primary node type inherits from the
nt:base
node type,
which must be supported. The CMS may define its own node types below the
hierarchy. Some predefined (but optional) node types are
nt:file
,
nt:folder
,
nt:version
, and
nt:query
. Certain primary node types require mixin types, and
others allow only certain mixin types. Nodes can have versions, although the node

must have the mixin node type
mix:versionable
.
Property
Properties are children of nodes, and have only one parent node. The property
interface is
javax.jcr.Property
. Properties represent pieces of metadata about
nodes. The values of properties must conform to allowed property types, which
include strings, binary data, dates, longs, doubles, and booleans. Properties may
also be soft links or references. Soft links are links to paths in the content repository.
These are soft references; the linked content may be moved, deleted, or may not
even exist. The soft link’s path can be absolute or relative. References are hard links
to nodes. They link by the node ID (UUID), and they must exist. If a reference
2840ch15.qxd 7/13/04 12:44 PM Page 365
Download at Boykma.Com
Chapter 15
366
exists to a node, that reference must be deleted before the node may be moved
or deleted. Some properties may have multiple values.
Path
A path points to an item in the repository. Paths may be either relative or absolute.
/Engineering/Reports/11222.doc is an example of an absolute path in the repos-
itory. ../Reports/11222.doc is a relative path, just like a file system. Your portlet
may get a node through the ticket by its absolute path. If two or more nodes under
the same parent node have the same name, the path can be tricky. You will have
to use array-based notation (starting at 1, not 0) to reference the node you want.
Search
One of the most interesting features of the JCR API is its search support. Because
JCR defines a standard set of query interfaces, it should be possible to create

a search portlet that can execute a search and display search results for any content
management system. Compare that with the Lucene portlet we built in Chapter 10.
The Lucene portlet’s basics are the same for every CMS, especially if you use
a standard set of fields. The difficulty with Lucene is writing classes that synchronize
the contents of the CMS with the Lucene index, especially if you are integrating
multiple systems. We expect that many JCR API implementations will use Lucene
to provide search capabilities.
The JCR API defines two query languages for the search function:
• JCRQL (with SSES): Java Content Repository Query Language (with
Simple Search Engine Syntax) is similar to SQL, but has extensions for the
hierarchical content model and also supports standard search query
terms.
• XPath: XPath 2.0 is an XML technology for searching through a hierarchical
XML document and extracting elements that match an XPath expression.
The JCR API XPath query language supports a subset of the XPath 2.0 func-
tionality plus some extensions needed for the JCR API.
Each content repository has to support at least one of these query languages.
Each CMS can also support additional languages—for instance, a Google-style
query language, or a Lucene query language with named fields. This means your
application will need to know which query language the CMS supports. The
javax.jcr.query.QueryManager
class has a
getSupportedQueryLanguages()
method
2840ch15.qxd 7/13/04 12:44 PM Page 366
Download at Boykma.Com
Content Management Systems
367
that will return the supported languages. If you are building a general-purpose
application, you will probably need to support both of the standard query lan-

guages. This way, your application will run on any JCR API–compliant CMS. Your
support may just be limited to different help files for the search engine because
the
QueryManager
class also parses the query from the user’s statement.
Development with the JCR API
The JCR API classes belong to the
javax.jcr
package and its subpackages. To start
developing with the JCR API, you will need to select and install a server that
implements the standard. The standard is still quite new, so we expect that a ref-
erence implementation of the JCR API will be released around the time that this
book is published. Some of the details of the API may have changed since the pub-
lic review, but all of the major concepts should be the same.
The first step with the JCR API is to obtain a
javax.jcr.Repository
object. Your
content management system should include directions for getting an instance of
Repository
, because this is one area of the API that is not standardized. The authors
of the specification expect that a JNDI lookup will be a common approach.
Repository
is an interface with one method,
login()
:
public Ticket login(Credentials credentials, String workspaceName)
throws LoginException, NoSuchWorkspaceException
The
login()
method takes a set of credentials and a workspace name. The

javax.jcr.Credentials
interface consists of a
getUserId()
method; a
getPassword()
method; and several methods for storing, setting, and removing attributes on the
credentials. The JCR API provides a basic implementation of the
Credentials
inter-
face with the
javax.jcr.SimpleCredentials
class. You can create a new instance of
SimpleCredentials
by calling its constructor and passing a user ID and password
as arguments. Upon successful authentication, the
login()
method returns a
Ticket
object.
The
javax.jcr.Ticket
class is the main gateway for your client to access the
content repository. From the ticket, you can get the root node of the workspace,
or you can get a node by its absolute path. You can also import an XML document
that represents new items.
Once you have a node, you can continue traversing the tree by relative paths.
The
Node
class has methods for retrieving and setting the node’s properties. You
can also create new nodes or add existing nodes as children. After you make any

changes, you will have commit your changes by saving the node. You can also save
all of your changes for the workspace by calling the
save()
method on the ticket.
2840ch15.qxd 7/13/04 12:44 PM Page 367
Download at Boykma.Com
Chapter 15
368
Retrieving a document out of a content repository with the JCR API is simple.
When you have a node with the primary type
nt:file
, that node will have a child
node called
jcr:content
. The
jcr:content
node holds the content in one of its
properties, which could be called
data
. You could get the value of the
data
property,
and then pass it back through to the portlet.
WebDAV
WebDAV (
www.webdav.org
) is a commonly implemented protocol for connecting to
content management systems and other content stores. The WebDAV specification
(RFC 2518) can be found at
www.webdav.org/specs/rfc2518.htm

. Many applications
and operating systems are WebDAV compatible. A non-exhaustive list of compati-
ble client applications follows:
• Microsoft Word
• Microsoft Excel
• Adobe Photoshop
• Macromedia Dreamweaver
• Apple Mac OS X
• Microsoft Windows XP
• Altova XML Spy 2004
All of these applications are able to connect to a WebDAV-compatible server.
Apache Tomcat comes with a WebDAV servlet that provides WebDAV access to files
on the file system. Apache Slide (
/>) is an open
source content management system that has a WebDAV server and a command-
line WebDAV client. Slide also has a WebDAV client library for Java, which we will
use to build a WebDAV client portlet.
WebDAV is an extension of the HTTP 1.1 protocol, so it is relatively easy to
implement.
WebDAV Methods
If you are already familiar with the GET and POST HTTP methods, the WebDAV
methods will look very similar. WebDAV adds many new methods beyond GET,
2840ch15.qxd 7/13/04 12:44 PM Page 368
Download at Boykma.Com
Content Management Systems
369
POST, HEAD, and the other standard HTTP methods. The biggest difference is
that WebDAV supports, and for some methods, requires, an XML message body
for the WebDAV methods.
We explain some of the most commonly used WEBDAV methods in this sec-

tion. Other methods in the WebDAV specification are MOVE, COPY, LOCK, and
UNLOCK. The versioning extensions to WebDAV (RFC 3253) also define the
VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, and UNCHECKOUT
methods. Other related specifications are WebDAV Ordered Collections (RFC 3648)
and WebDAV Access Control (RFC 3744).
PROPFIND
Use the PROPFIND method to access the properties of a resource. The client will
ask for a set of properties by name for a given WebDAV resource. The server can
also return all of the properties for the resource.
The client may also ask for all of the resource’s properties along with all of its
children’s properties up to a given depth. The depth may be 0, 1, or infinity. An
infinity depth returns the properties of all resources under the named resource.
If your WebDAV client needs to browse through content in the server’s reposi-
tory, the PROPFIND method is useful for determining what the current resource’s
properties are and the names and types of resources under the current resource. You
can easily create a directory listing style interface. If you use a depth of 1 or infin-
ity, your application could cache the properties to improve performance.
PROPPATCH
Client applications use the PROPPATCH method to create, modify, or remove
properties on a resource. You can both set and remove one or more properties in
a single request. The PROPPATCH method is an all or nothing proposition—if any
of the requests to set or modify a property fail, none of the requests will be per-
manent. Any changes before the failed request will be set back to the way they
were. If a PROPPATCH call fails, you will get an error message back explaining
what the problem was.
MKCOL
The MKCOL method creates a new collection resource. The request’s path should
not already exist. If the path does exist, the MKCOL method will not work. Another
condition to consider is that the specified path’s parent collections must already
exist—only one collection will be created.

2840ch15.qxd 7/13/04 12:44 PM Page 369
Download at Boykma.Com
Chapter 15
370
DELETE
The DELETE method removes the non-collection resource at the specified path.
If the resource is a collection, the DELETE method will remove the collection and
all resources under the collection. This is a very powerful method.
PUT
The PUT method creates a new resource at the given path, or it replaces the con-
tents of the existing resource. The PUT method works only for non-collections. If
you need to create a new collection, use the MKCOL method.
Slide WebDAV Client Library
The client distribution for Apache Slide includes a command-line client and
a WebDAV client library. We will use both to build a portlet that communicates
with a WebDAV server. Both the WebDAV client library and the command-line
client are open source projects licensed with the Apache Software License. The
Java WebDAV client API is straightforward, once you understand the basics of the
WebDAV protocol.
The WebDAV client library is in the jakarta-slide-webdavlib-2.0.jar file. You
need to copy that file into your WEB-INF/lib folder. The source distribution
of the Slide client includes the source code of the command-line client. The
command-line client is the best source for information on how to use the WebDAV
client library, so we used its source code as a model for our portlet.
The WebDAV client library classes are in the
org.apache.webdav.lib
,
org.apache.webdav.lib.methods
, and
org.apache.webdav.lib.properties

pack-
ages. Your application will create an
org.apache.webdav.lib.WebdavResource
object
that represents a resource on the remote server. You will need the URL of the remote
resource, along with the username and password (if necessary). If the resource does
not exist, you can create it once you have the object.
Once you have an object that represents a resource, you can execute the
WebDAV methods we discussed in the previous section. The WebDAV methods
are available directly on the
WebdavResource
object (
mkcolMethod()
,
moveMethod()
,
deleteMethod()
, etc.). Other methods on the WebdavResource object use WebDAV
indirectly, or return information that already exists on the object. These include
list()
,
listBasic()
, and
listWebdavResources()
. Each of these methods returns
information about the child resources of the current resource if the current resource
is a collection. The
list()
method returns a
String

array of pathnames to the
children. The
listBasic()
method returns the child resources’ path names, content
2840ch15.qxd 7/13/04 12:44 PM Page 370
Download at Boykma.Com
Content Management Systems
371
length, either collection or a content type, and the last modified date. This infor-
mation is stored in an array for each resource, and then each array is stored in
a
Vector
. If you would like to get an array of
WebdavResource
objects that represents
each of the child resources in the collection, use the
listWebdavResources()
method.
WebDAV Portlet
We are going to build a portlet that connects to a WebDAV server. You will need to
install a CMS that supports WebDAV. We used the open source Apache Slide server.
The easiest way to get started is to download the Slide binary distribution that
bundles the compiled version of Slide with an installation of Apache Tomcat. You
will need to edit the port numbers for Slide’s Tomcat if you run Slide side by side
with Pluto on the same computer, so they do not conflict. Another option is to
install the Slide web application on an external installation of Tomcat. We used
Slide 2.0, running on port 9080.
Use your operating system’s built-in WebDAV support to add some files and
folders to the Slide content repository. Documentation for both Windows and Mac
OS X is available on the Slide web site. You can also use the command-line Slide

WebDAV client. Our portlet only allows content browsing and viewing, although
we could certainly add more file management support.
We are using several open source libraries for our WebDAV portlet. The first
is the WebDAV client library we discussed previously. That library is packaged in
the jakarta-slide-webdavlib-2.0.jar file. It also requires the Jakarta Commons HTTP
client library and the Jakarta Commons logging libraries. The correct versions are
in the Slide client binary distribution. The other libraries we will use are the JSP
Standard Tag libraries, for our JSP files. We use the Jakarta Commons Standard
Tag Library, version 1.0.4 (the same as Chapter 5). We will need the jstl.jar
and the standard.jar files. All of these libraries should go in your WEB-INF/lib
directory.
Our portlet will display the available resources for a collection, or it will display
the contents of a noncollection resource. If you select a collection, the portlet
will update its internal pointer to a WebDAV resource, and then display the resources
in the collection. If you select a file, the portlet will retrieve its contents as a string,
and then display them in the portlet window. You may also navigate back up the
hierarchy with the parent folder link at the bottom of the page.
We created one portlet class,
CMSPortlet.java
. It responds to action requests
and render requests. The
WebDAVHelper
class encapsulates the WebDAV functionality.
WebDAVHelper
is a bridge between the portlet and the client library, and it includes
some utility methods. Our JSP file, ListFiles.jsp, uses the portlet and standard JSP
tag libraries to display the resources for a collection.
2840ch15.qxd 7/13/04 12:44 PM Page 371
Download at Boykma.Com
Chapter 15

372
CMSPortlet.java
The
CMSPortlet
class initializes itself from the initialization parameters on the port-
let deployment descriptor. Three parameters, URL, username, and password,
contain the connection information for the WebDAV server.
The
doView()
method looks at the current WebDAV resource to determine if
it is a collection. If it is a collection, it dispatches the request to the ListFiles.jsp
page. If it is not a collection, it asks for the contents of the resources as a
String
,
and displays them in the portlet output. We could also have created links in the
JSP file that would show the contents of the resources in a new window if the
resource was an image, PDF file, or another binary file.
The
processAction()
method looks at the COMMAND parameter and then
performs an action based on the command. All of our commands change the
current WebDAV resource.
package com.portalbook.portlets;
import java.io.*;
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletConfig;
import javax.portlet.PortletContext;
import javax.portlet.PortletException;

import javax.portlet.PortletRequestDispatcher;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.UnavailableException;
import org.apache.webdav.lib.WebdavException;
import org.apache.webdav.lib.WebdavResource;
public class CMSPortlet extends GenericPortlet
{
public static final String COMMAND = "COMMAND";
public static final String CHANGE_COLL = "CHANGE_COLLECTION";
public static final String DISPLAY_CONTENT = "DISPLAY_CONTENT";
public static final String DISPLAY_PARENT = "DISPLAY_PARENT";
public static final String PATH = "PATH";
WebDAVHelper helper;
2840ch15.qxd 7/13/04 12:44 PM Page 372
Download at Boykma.Com