As more and more of our clients are upgrading to Documentum 6/6.5, we’ve encountered many significant changes between development methods in 5.3 WDK and 6.5 WDK. The good news is they are changes for the better, allowing for more efficient and streamlined development of Webtop customizations. One of the big changes is the ability to modify a Webtop component rather than having to extend it.
For those of us that have developed Webtop customizations on Documentum 5.3, we are all too familiar with the extend function when customizing a Webtop component. Extending a component is in essence creating a subtype of that component, and allows that subtype to inherit attributes of the out-of-the box (OOTB) component, unless otherwise overwritten by the subtype. However, extending a component can be cumbersome. In the past, we’ve had to customize components by copying the entire Webtop component xml over to the custom component xml in order to add only one or two new nodes to the xml. For example, in this scenario, we are trying to implement a customization to display a text area for some custom attributes. The following is what the custom component xml would look like using extends:

You can see that most of this xml is just out-of-the-box Webtop. With 6.5, you can use modifies instead of extends and slim down your custom component xml. The following is what the custom component would look like using modifies:
By using the modifies function, you have access to tags such as <insertbefore>, <insertafter>, <replace>, and <remove>, that take in an XPath query to locate the node that needs to be modified. This removes the need to copy over the OOTB Webtop component xml. This, in turn, allows for easier maintenance of customizations when upgrading to new Documentum versions. You no longer have to make the changes that were made to the out-of-the-box component xml when it was upgraded, to your custom component as well. This would only be necessary now if the part changed during the upgrade ended up being the part that was customized.
Most of the time, modifying a component is preferred over extending, however there are cases where extending a component is actually necessary rather than modifying. One such scenario is when you are creating new Webtop functionality that is based on, or needs to replicate, OOTB functionality. For example, a recent client asked for a customization that, upon importing a document, would promote the document to the final state of its lifecycle. They wanted to keep the original Import option, but wanted to provide users with an additional Import to Final option. In order to implement this, a new component was created that extended the OOTB import component so that the same import logic would be used regardless of what import option was chosen. However, for Import to Final, a custom processor was created to run after the import logic and promote the document.
There are also other ways of using modifies and extends depending on the functionality you’re looking for. For example, you can add modifications to a component that’s already been modified at a previous level, or you can modify a component inside of an extension. The one thing to remember when using them together is that when customizations are loaded, extensions are always applied after all modifications have been applied to the component.
Please feel free to contact us if you have any additional questions about WDK development.
[…] throughout blog.tsgrp.com for many posts including upgrade alternatives, extends versus modifies in 6.5, understanding the impact of WDK development, migration, clone or in-place upgrade, high volume […]