About This Article

This article describes the use of WebPublisher in creating HTML pages. It describes the basic principles of WebPublisher and the use of stylesheets in transferring the WebPublisher generated XML files into HTML.

This document will prove helpful if:

• You’re just beginning in your configuration of Documentum WebPublisher
  and want to understand where to start.
• You’ve already created some stylesheets, but want more detail and
  examples to help you get more sophisticated web pages out of your source XML.
• You’re an XML/XSL pro, but want to see what’s different about how
  WebPublisher creates XML content, and how that impacts the design
  of your XSL.

To get the most from this article, you should already have:

• A working knowledge of HTML or XHTML.
• An working installation of Documentum WebPublisher
  and a general understanding about how to interact with the
  web based authoring tool.
• A basic understanding of XML and the purpose of XSL.

Overview

Web Publisher is a browser based, customizable tool, that allows you to create XML documents. It has an advantage over raw XML authoring tools by providing the user with a forms based interface for creating the documents. Users are able to enter data into text boxes, fill out tables, or make selections from widgets such as drop down boxes. Web Publisher converts this information into a standard XML file, and stores it in the docbase.

There are four components of Web Publisher that are important for you to understand:

• XML Template – This defines what the final XML document will look like. This includes the tags within the final XML file, and the doc_type that the XML file will be created as.
• Rules Files – This defines what the WebPublisher input form will look like. It defines what labels and widgets will appear on the input form, how each widget maps to tags in the final XML file, and how the widgets are arranged on the form.
• Stylesheet – These are the stylesheets that transform the final XML documents into its view able formats. Each XML template can be associated to multiple stylesheets (this is done by an intermediate “format” attribute). The transformation occur when you wish to preview or publish the XML document. For example, if you choose to preview a document, the system will check and see if multiple stylesheets are associated to the file. If so, it will present you with a list of “formats” that you can view the document in. When you select the format you desire, the system will transform the XML document based on the stylesheet associated with your selected format.
• XML Application – This defines how the XML file you authored is created in the docbase. For example, you may wish to chunk the document into multiple pieces of a virtual document. Or, you may wish to populate meta-data of the document from the content you just authored. This component is what configures these business rules. The remainder of this paper does not address much about the XML application, but you can find out more from the document “Managing XML Content in Documentum”.

About WebPublisher Content

The first thing you do when you use the authoring client, is select an XML template. This template serves as the basis for the content file you will be creating. The user completes the XML file by entering the information into the WebPublisher form provided. The result, is an XML file that serves as the content for the file being authored.

When content is published, the transformation engine built-in to WebPublisher will use an associated XSL file and the XML content file to create an XHTML page.

Templates, Rules, And Their Impact on Content

XML Templates (a.k.a. Content Templates)

These files are the basis
for the content that will be created using WebPublisher. There are a few
things you should be aware of when creating XML templates for content:

• Associations – There should be one associated rules file (explained below),
  and at least one Presentation Template (XSL file) for each
  XML template.
• Object Types & Default Attributes – The object type of the
  XML template file will be the object type of all content created in
  WebPublisher using that template. All object attribute values of a
  template will automatically carry over to any content that is based
  on that template. This is a convenient way to ensure that attributes
  for certain types of content have default values.
• Pre populated XML Values – The content of the template (the XML
  file) can be pre populated with anything you want. These values and
  attributes will automatically be inherited by content created using
  the template.
• Structure – The structure of the XML content of a template
  is partially dependent on which widgets you decide to use (as specified
  in the Rules files). Keep this in mind while putting together your
  XML templates.
• Formatting – The formatting (spacing, indenting, etc) isn’t
  preserved when you create content based on a template.
• Ordering – The order you list the XML elements in, in the template
  file is the order they will be displayed in in the GUI when a user creates
  content.

XML Rules Files

These files define which widgets will come up
in the WebPublisher content editor, and what XML elements from the associated
template will be populated with the user-entered values when content is
created.

Within rules files, you can define tabledefs or repeatdefs
that allow the user to make multiple selections. The resulting XML is
referred to as Complex Elements in this document. All other types
of widgets you use in rules files will cause WebPublisher to create single
XML elements in the content files (referred to here as Simple Elements)

The following is a segment of resulting content XML that is created
as a result of the user entering the values “Thomas”, and “Jefferson”
in simple widgets within WebPublisher.

<first_name>Thomas</first_name>
<last_name>Jefferson</last_name>

The complex element here is “presidents”. The contained element type is “full_name”.

<presidents>
<full_name>Bill Clinton</full_name>
<full_name>George Bush</full_name>
<full_name>Ronald Regan</full_name>
. . . (etc)
</presidents>

The complex element here is “presidents”. The contained elements are “first_name”
and “last_name”. Using a repeatdef with more than one contained elements isn’t
recommended because it ends up creating unstructured XML, which as a result
can be very difficult to address in a stylesheet.

<presidents>
<first_name>Bill</first_name>
<last_name>Clinton</last_name>
<first_name>George</first_name>
<last_name>Bush</last_name>
<first_name>Ronald</first_name>
<last_name>Regan</last_name>
. . . (etc)
</presidents>

The complex element here is “presidents”. The contained elements are “first_name”
and “last_name”.

<presidents>
<row>
<cell>
<first_name>Bill</first_name>
</cell>
<cell>
<last_name>Clinton</first_name>
</cell>
</row>
<row>
<cell>
<first_name>George</first_name>
</cell>
<cell>
<last_name>Bush</first_name>
</cell>
</row>
<row>
<cell>
<first_name>Ronald</first_name>
</cell>
<cell>
<last_name>Regan</first_name>
</cell>
</row>
. . . (etc)
</presidents>

WebPublisher groups entries within the “row” tags and individual entities within the “cell” tags.

Using a tabledef is recommended if you have multiple types of data
(above, “first_name” and “last_name”) and you need those to be
repeated. This is better than using a repeatdef because the
resulting XML can be better structured, and thus is more straightforward to
address in a stylesheet.

Addressing Simple Elements In XSL

Suppose your content file resulted in a set of simple, repeating entities like the following:

<application_list>
<application>Business/Financial</application>
<application>Consolidation</application>
<application>Electronic Commerce</application>
</application_list>

This situation is very straight forward situation for an XSL. The following extract shows how this would typically be handled in your XSL file:

<TABLE>
<TBODY>
<xsl:for-each select="//document_root/application_list/application">
<TR>
<TD>Application</TD>
<TD><B><xsl:value-of select="." /></B></TD>
</TR>
</xsl:for-each>
</TBODY>
</TABLE>

This would result in the following html:

<TABLE>
<TBODY>
<TR>
<TD>Application</TD>
<TD><B>Business/Financial</B></TD>
</TR>
<TR>
<TD>Application</TD>
<TD><B>Consolidation</B></TD>
</TR>
<TR>
<TD>Application</TD>
<TD><B>Electronic Commerce</B></TD>
</TR>
</TBODY>
</TABLE>

WebPublisher also supports rich text widgets. These widgets will result in XML that contains HTML type tags. For example, you may wish to allow users to enter <B> or <a href…> tags into the widgets that make up the main content sections of the final HTML page. This can pose a problem for some stylesheets, as they would treat each HTML tag as the start of a new XML entity. In these instances, modify your stylesheet by replacing the command “xsl:value-of select….” with “xsl:copy-of…”. The copy-of command instructs the translation engine to copy the current node and all of its children.

Addressing Complex Elements In XSL

For instances that make use of complex elements, you will need to make sure your stylesheet takes into account the “row” and “cell” tags that WebPublisher add to the XML content. The following excerpt provides and example of how an XSL would display the “presidents” example from above.

<TABLE>
<TBODY>
<xsl:for-each select="//presidents/row">
<TR>
<TD>Name</TD>
<TD><xsl:value-of select="cell/first_name" /></TD>
<TD><xsl:value-of select="cell/last_name" /></TD>
</TR>
</xsl:for-each>
</TBODY>
</TABLE>