Use Log4J extensions for debug and error Logging
WDK uses a DFC “Log4J” extension for logging. The configuration of log4j is held in “$Documentum/Config/log4j.properties”.
Define a “logs” directory and modify log4j.properties to use that path, not the Documentum default.
Ensure you include your log4j.properties file in any deployment process (see later).
Create your own project log4j appenders and files and add them to the log4j.properties. Use “debug”, “error” and “fatal” to categorize the error.
On development or problem determination run at “debug”; for production run at “error”.
Define Coding Standards
For multi developer teams, define coding standards to cover:
• package naming
• error handling
• logging (using the log4j process described above).
Pay attention to the use of local and resource bundling (strings) to support internationalization.
Always extend when possible
It can be tempting to copy component definition and behaviour classes. Always extend unless this proves impossible.
Always remove unchanged XML elements from component definitions.
Use BOF for business logic where possible
• Enables same business logic to be “shared” by multiple applications
• Reduces the changes needed when upgrading
Use WDK Folder paths
Although it is not required, it makes navigation easier to replicate the WDK folder structure in an application’s folders.
This is helpful as WDK developers become familiar with the default WDK folder structure and can then readily navigate all custom application structures.
Use a Source Control Repository
There are many good source control repositories, most of which integrate to common IDEs.
Use source control to hold Java classes, JSP pages, XML component definitions, log4j.properties, dbor.properties etc. This will also ease deployment problems (see later).
Select an IDE for productivity
There are many good free IDEs including Netbeans and Eclipse. These greatly increase the productivity of developers. In particular they allow developers to link to 3rd party source control systems, automate the build and deployment process using Ant and offer the ability to debug WDK code at runtime.
Use Ant to build, package and deploy
Use Ant scripts to ensure that the application build and deploy process is automated and consistent.
Use Ant to package classes into JARS and to deploy all parts of a WDK application (including JARs, JSP pages, XML configuration files, dbor and log4j properties, NLS strings) to both application and content servers.
Control Documentum configuration by using available Ant extensions to install docapps and run DQL and API scripts.
Consider Development, Integration and Test Environments
For a team of developers, it is advantageous to have individual application servers for each developer. This allows application servers to be started and stopped without disturbing other developers.
Having a Development Integration environment will allow regular builds to be made from the latest code from the source control repository. Controlling the build via Ant scripts make this quick and repeatable.
The test environment can be built after successful verification of a build on the development integration environment.
Use WDK component definition XML to hold configuration and default values
The WDK XML component definitions allow new XML elements to be added. The behaviour class can access this information. This provides a good way to provide configuration and default values that give components extra flexibility.
Simplify upgrades and document modified WDK XML, JAVA classes and JSP Pages
When developing applications document all components that are extended or modified. Then when upgrading to a new version of WDK or WebTop use this information to access the impact of the upgrade.