Till now we have seen how to create Docbase objects and manage them via the user-friendly interface provided by default Web Publisher screens. We have seen how content files are created through the New Content screen in Web Publisher and how properties of existing objects are modified through the Properties (attributes) screen. In fact all other screens that we have seen in Web Publisher such as the Categories page displaying existing Web Publisher categories, the Inbox screen displaying workflow tasks, and other server notifications, etc. are all default screens provided by the Web Publisher application. Webtop, Digital Asset Manager, and Documentum Administrator are examples of some other web-based applications in Documentum that have their own specific user interfaces.
What if you need to modify the look-and-feel of these default screens or alter some basic functionality associated with these screens? Welcome to the world of Documentum WDK (short for Web Development Kit)!
WDK (as we discussed in Chapter 3) is a framework that Documentum has provided to build and deploy J2EE web applications for connecting with Documentum Content Server. WDK consists of a set of reusable and extensible server-side Java components that interact with Content Server via DFC calls.
Webtop is a reference implementation provided by Documentum using the WDK framework for basic content management functionalities. Web Publisher and the Documentum Administrator tools that we have covered in this book have been built over Webtop. Using WDK, you can alter the user interface of Web Publisher/Documentum Administrator screens and even extend and modify their functionalities via customizations. The WDK framework has been written well and provides flexibility to override default functionality and add your own custom components as well!
Using WDK, you can primarily perform two kinds of tasks:
Figure 24.1 shows the nature of work (configurations and customizations) that can be performed using the WDK framework.
Documentum WDK 5.3 Update:
Before we begin discussing WDK configurations and customizations through examples, let's first go through the WDK directory structure and its contained folders and files. The root of the WDK application has the following directories and files:
config.xml
): Starting page for WDK application (index.html/default.html
) and unstripped.jar
containing the WDK application files with embedded comments for debugging purposes. web.xml
file (for J2EE web applications), WDK web application Java classes, and classes for other application layers such as wdk, webcomponent
, and jars
required by the WDK framework and JSP tag libraries.wdk, webcomponent, webtop, dam, wp
, and custom):
Application layer directories contain an application's configuration file (app.xml), configuration files for application components, externalized strings, themes, component JSPs, and JavaScript files required by applications.Do not be intimidated by the number of terminologies we are discussing—WDK, Webcomponent, Webtop, and many more. These are simply the various WDK application layers and each of these extends the layer below it in the hierarchy. Look at figure 24.2 to understand the WDK application layer hierarchy chain.
If you open the application configuration file app.xml
for each of the WDK intermediate layers, you will notice that it extends from the layer shown just below it in figure 24.2.
For example, the app.xml
for Webtop would extend the app.xml
for the webcomponent
layer. WDK is the base layer in the hierarchy and does not extend any other layer.
A snippet from the Webtop app.xml
file: <application extends="webcomponent/app.xml">
.
Note that each WDK component has an associated XML configuration file defining it, a behavior Java class, at least one JSP page for defining its layout, and an NLS properties file for externalizing strings.
The Custom layer is a very interesting concept and would have definitely caught your attention if you are new to Documentum WDK. The Custom layer sits at the top of the hierarchy chain and is provided by Documentum for you to house all your customizations. It contains any customized configuration XML files, JSP pages, branding themes, and externalized strings. If you place customized component definition configuration and other files in the custom
directory, the WDK framework will load it first before it loads the files in the layers below the custom layer.
During WDK application upgrades from one version to another, you need to take a backup of your custom
folder before performing the upgrade and later restore it after the upgrade completes. This ensures that your customized files are stored in a centralized location and can be restored easily as required.
18.224.57.231