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:
- Configuration: This includes simple operations such as introducing new menu options, modifying labels and texts in screens, altering look-and-feel such as images associated with button controls, and hiding/displaying attributes/fields in various screens. Using XML configuration files and JSPs (Java Server Pages) provided in the WDK, you can achieve simple configurations of web applications.
- Customization: This involves comparatively more effort than simple configurations and includes tasks such as adding new actions and components in the WDK framework. Also, this includes extending framework behavior classes to override default functionality and introduce custom logic and functionality. Using behavior Java classes in WDK, you can customize web applications.
Figure 24.1 shows the nature of work (configurations and customizations) that can be performed using the WDK framework.
Figure 24.1: Configuring and customizing with WDK
Tip
Documentum WDK 5.3 Update:
- Three modes of content transfer supported by WDK: HTTP, Unified Client Facilities (UCF), and Content Transfer Applets
- Support for session failover to other servers running the same WDK-based application in a clustered environment
- Support for multiple Docbase repository searching
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:
- WDK application configuration file (
config.xml): Starting page for WDK application (index.html/default.html) andunstripped.jarcontaining the WDK application files with embedded comments for debugging purposes. - WEB-INF: Contains
web.xmlfile (for J2EE web applications), WDK web application Java classes, and classes for other application layers such aswdk, webcomponent, andjarsrequired by the WDK framework and JSP tag libraries. - help: Contains WDK client application help files.
- plugins: Contains the JRE plug-in for the WDK client application.
- Application layer directories (
wdk, webcomponent, webtop, dam, wp, andcustom):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">.
Figure 24.2: WDK application hierarchy
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.
Tip
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.