WDK Stack Component Guidelines - Dell EMC are pleased to make this component development guide available to our developer community. Please remember that the goal is to facilitate

Documentum Developer Program

WDK Component Development Guidelines March 2004

Developer Program Component Exchange

1/25

Preface Documentum engineers have gained considerable experience over the years developing reusable components for our client applications. In an effort to capture lessons learned from this experience, several key engineers collaborated to produce a collection of best practices and guidelines for WDK component development. These are now used internally by all Documentum engineers when developing and unit testing components. We are pleased to make this component development guide available to our developer community. Please remember that the goal is to facilitate component reuse, extendibility, and quality; they are not intended to be an exhaustive list of requirements.

Organization of this Guide The guide starts with checklists that you can use for WDK components with links to a more detailed guidelines section later in the guide. There are also supporting sections containing definitions of WDK components and a list of other sources of information.


2/25

Table of Contents Preface .............................................................................................................................2

Organization of this Guide .............................................................................................2 Table of Contents............................................................................................................3 Checklists ........................................................................................................................4

WDK Checklists.............................................................................................................5 WDK Component Checklist .......................................................................................5 WDK Control Checklist ............................................................................................11 WDK Component Unit Testing Checklist .................................................................13

General Guidelines .......................................................................................................14 Audience......................................................................................................................14 How to be used............................................................................................................14

Definitions and Overview of WDK Components ........................................................15 Logical definition:.........................................................................................................15 Physical definition:.......................................................................................................15 Characteristics.............................................................................................................15

WDK Component Guidelines .......................................................................................17 WDK Components.......................................................................................................17

Design......................................................................................................................17 XML Configuration File ............................................................................................17 JSPs.........................................................................................................................19 Behavior Class.........................................................................................................20 NLS Properties Files ................................................................................................22

WDK Controls..............................................................................................................22 [WDK-CTRL-03] Created a new control file for this component ..............................22 [WDK-CTRL-04a] File follows naming conventions ................................................22 [WDK-CTRL-04b] File follows component library location conventions..................23 [WDK-CTRL-06] Used base tag class render helpers to render HTML tags that conform to WDK protocol.........................................................................................23 [WDK-CTRL-08] Control class property getters and setters are type safe ..............23 [WDK-CTRL-10] Formatted and escaped all rendered HTML values to render well-formed HTML...........................................................................................................23 [WDK-CTRL-12] Internationalization........................................................................23

WDK Component Unit Testing ....................................................................................24 [WDK-UT-02] File follows naming conventions.......................................................24 [WDK-UT-03] File follows behavior class library location conventions ...................24 [WDK-UT-04] Test methods in test class................................................................24

Key Documents/References.........................................................................................25 General........................................................................................................................25 WDK-specific ...............................................................................................................25


3/25

Checklists The following checklist tables are intended for use as a development aid. • WDK

o WDK component checklist o WDK control checklist o WDK component unit testing checklist

Each checklist table has the following columns: • Category

This column names the category into which the checklist item fits. The categories correspond to parts of the component (XML configuration, JSP, and so on).

• Checklist item • Impact

This column rates how critical the checklist item is to the success of the component. The ratings are: High – not following this item will lead to lack of reusability, buggy behavior, inability to migrate, failure of the component to run, and so on Medium – not following this item will impact the success of the component but will not cause disastrous consequences Low – this item may be a best practice or may facilitate the reuse of the component but will not affect the success of the component itself

• Significance This column provides a domain for the impact. For example, “Reuse” indicates that not following this checklist item will impact the ability of this component to be reused.

• Followed Y/N This column is the place for you to check off whether you have followed the checklist item or not.

• Justification if ignored This column allows you to write a justification of why a particular checklist item has not been followed.

Note: All checklist items are considered mandatory unless noted as a best practice.


4/25

WDK Checklists See the section “WDK Stack Component Definitions and Overview” for a definition and general information about the guidelines.

WDK Component Checklist The following checklist provides a summary of the guidelines for WDK components and offers a quick test of whether the guidelines have been followed. Follow the link in the Checklist Item column to jump to more detailed information about a specific guideline. Note: All items are required unless labeled “Best Practice.” Follow the hyperlink for certain checklist items to find more information. Category Checklist Item Impact Significance Followed

Y/N Justification if ignored

Design [WDK-D-01]

Component is designed to run within a container (unless it is a container itself)

H Reuse

Category Checklist Item Impact Significance Followed


XML Configuration File [WDK-XML-01]

Created a new XML configuration file for this component (didn’t modify existing file)

H Migration

[WDK-XML-02a]

File follows naming conventions

M Reuse

[WDK-XML-02b]

File follows library location conventions

H Reuse

[WDK-XML-03]

Extends rather than copies original component definition

M Reuse Extendibility

[WDK-XML-04]

Contains functional component description (<desc> value) (describes why component is being extended or created)

M Reuse

[WDK-XML-05]

Component is configurable Contains values that can be configured to change behavior of components, rather than requiring customization Includes comments explaining what is configurable and possible values.

H Reuse Extendibility

[WDK-XML-06]

Required parameters are marked <required>true</required>

H Reuse


5/25

[WDK-XML-07]

Has help ID defined. M Standard

[WDK-XML-08]

Backwards-compatibility: Did not add or remove required <params> Did not remove structural elements from configuration data

H Migration


6/25



JSPs [WDK-JSP-01]

Created a new JSP file if page modifications were needed

H Migration

[WDK- JSP-02a]


M Reuse

[WDK- JSP-02b]

File follows component library location conventions

H Reuse

[WDK- JSP-03]

No Java code in JSP: Used existing controls or new custom controls rather than code in JSP

H Maintainability

[WDK- JSP-04]

If using JavaScript: Page is loaded and initialized Used safeCall(…) and isWindowInitialised() helpers

H Quality

[WDK- JSP-05]

Used HTML element ID rather than referencing Form[0]

H Reuse

[WDK- JSP-06]

Used WDK (dmf) controls, not HTML input controls

M Quality

[WDK- JSP-07]

Used 5.2.5 WDK layout tags (such as body, header) in place of HTML layout tags

H Reuse

[WDK- JSP-08]

Used a background style such as contentBackground on a body tag

H Reuse

[WDK- JSP-09]

Complied with Section 508 standards

H Standard

[WDK- JSP-10]

Used UTF-8 encoding on JSP

H I18N

[WDK- JSP-11]

Had WDK 5 error directive on JSP pages.

H Reuse

[WDK- JSP-12]

Used WDK theme styles Tested that component works with all themes (component is ‘skin worthy’)

H Reuse

[WDK- JSP-13]

Layout is consistent with other components in library Layout (wireframes) was provided by and reviewed by UI group

H Reuse

[WDK-JSP-14]

All JSPs are compilable: a tag library is defined for the JSP

H Quality; reuse


7/25



Behavior Class WDK- BC-01

Created a new behavior class file if modifications necessary

H Migration

WDK-BC-02a

Behavior class file follows naming conventions

M Reuse

WDK-BC-02b

Behavior class file follows component library location conventions

H Reuse

WDK-BC-03

Extended component rather than duplicated

H Migration Extendibility

WDK-BC-04

Did not hard code context-sensitive behavior in the class (instead, used WDK “filter” to configure component behavior in XML definition)

H Reuse Extendibility

WDK- BC-05

Used component arguments and return values to pass data to or between components, not global caching facility

H Reuse

WDK- BC-06

Designed for subclassing Applied “template method” pattern Provided hooks as component configuration (where developer would specify class that implements “hook” interface”) for complicated application logic

H Extendibility

WDK- BC-07

Code contains no business logic (invokes encapsulated business logic)

H Extendibility Interoperability

WDK-BC-08

Invoked Business Logic through the job execution framework (5.2.5 onward) if the business logic can make use of those features.

H Extendibility Performance

WDK- BC-09

Bound datagrids with a session on every render (session is only valid for one request)

H Quality

WDK- BC-10

Best practice: Used getControl instead of caching/holding control instances as member variables

L Quality Extendibility

WDK- BC-11

Called super.xxx on all component lifecycle events (onInit, onRender…)

H Quality


8/25

WDK- BC-12

Used request scope instead of component scope as parameter for component.getSession rather than DFC sessionmanager.getSession Did not cache/hold session as member variable

H Performance (scalability)

WDK- BC-13

Backwards-compatibility: Did not remove anything non-private (methods, constants, members variables) Did not change signature Did not change behavior of methods or interface Made sure previous unit tests run

H Migration

WDK- BC-14

Implemented one or more custom attribute data handlers (WDK 5.2.5)

H Performance

WDK-BC-15

Used getters and setters for accessing and setting properties.

H Extendibility, reuse

WDK-BC-16

Instances of action and precondition classes do not have any state associated with them.

H Quality


9/25



NLS Properties Files WDK-NLS-01

Created a new NLS Properties file for any new strings

H I18N

WDK-NLS-02a


H I18N

WDK-NLS-02b


H I18N

WDK-NLS-03

Used NLSINCLUDE rather than duplicating strings

M Localization cost

WDK-NLS-04

Best practice: Used “MSG_xxx” as naming convention for resource strings

L Standard

WDK-NLS-05

Escaped non-Latin characters

H Quality

WDK-NLS-06

Didn’t use sentence/text fragments as values for resource strings

H Quality

WDK-NLS-07

Tested for internationalization: Used Preferences debug settings to run NLS checks to make sure strings are externalized. Used Preferences debug settings to check for German (long) and Asian strings

M I18N Quality


10/25

WDK Control Checklist The following checklist provides a summary of the guidelines for WDK controls and offers a quick test of whether the guidelines have been followed. Follow the link in the Checklist Item column to jump to more detailed information about a specific guideline. Note: All items are required unless labeled “Best Practice.” Category Item Impact Significance Followed


Design (general) WDK-CTRL-01

Best practice: Control is defined at design time to answer following questions: What does it look like in the UI? What is its state? What are its properties? What events does it fire?

H Standard



Specific WDK-CTRL-02

Best practice: Named control using constant defined in behavior class

L Reuse

WDK-CTRL-03

Created a new control file for this control (rather than modifying existing files)

H Migration

WDK-CTRL-04a


M Reuse

WDK-CTRL-04b


H Reuse

WDK-CTRL-05

The namespace for the control should clearly classify the control into an appropriate functional area/application: Core WDK control, not Documentum-specific (dmf) Core WDK control, Documentum-specific (dmfx) Related to specific functional area/application, placed in appropriate control library

H Reuse

WDK-CTRL-06

Used base tag class render helpers to render HTML tags that conform to WDK protocol

H Quality

WDK-CTRL-07

Implemented the tag class release method

H Quality


11/25

Called super.release WDK-CTRL-08

Control class property getters and setters are type safe

H Extendibility Usability

WDK-CTRL-09

Used WDK theme styles (skinnable). Tested against several themes

H Reuse

WDK-CTRL-10

Formatted and escaped all values to render well formed HTML

H Security Quality

WDK-CTRL-11

Used formatValue method to render control value so control is formattable.

H Reuse

WDK-CTRL-12

Internationalization: Externalized strings Ensured caching scheme is internationalized

H I18N

WDK-CTRL-13

If using JavaScript: Page is loaded and initialized Used safeCall(…) and isWindowInitialised() helpers

H Quality

WDK-CTRL-14

Created a control pen and tested flavors of the control

H Quality


12/25

WDK Component Unit Testing Checklist Note: All items are required unless labeled “Best Practice.”

Category Item Impact Significance Followed Y/N

Justification if ignored

Behavior Class Unit Tests1 WDK-UT-01

Created a new test behavior class file.

H Standard

WDK-UT-02

Behavior class file follows naming conventions

L Quality

WDK-UT-03

Behavior class file follows component library location conventions

L Quality

WDK-UT-04

For each public method in the behavior class, a corresponding test method exists in the test class.

H Quality

WDK-UT-05

Optional: For each protected method in the behavior class, a corresponding test method exists in the test class. See WDK-UT-04.

L Quality

WDK-UT-06

Where feasible, a test should exist to exercise all branches of code in behavior class methods.

M Quality

WDK-UT-07

Valid parameter values should be passed to behavior class methods and no errors should occur.

H Quality

WDK-UT-08

Invalid parameter values should be passed to behavior class methods and exceptions should be gracefully handled.

H Quality

WDK-UT-09

All test classes compile with no errors or warnings.

H Quality

WDK-UT-10

All JUnit tests should pass and there should be no errors in the app server console window.

H Quality


13/25

1 This section assumes the unit test harness is JUnit with the Cactus extension (used for testing server-side java code), and a test infrastructure has been established for creating Docbase sessions, creating Docbase objects, data driving tests , etc.



Component Functional Tests WDK-FT-01

The component can be launched stand-alone in a browser.

H Quality

WDK-FT-02

The component can be launched from within the parent application in a browser (e.g. from within Webtop).

H Quality

WDK-FT-03

When launched with invalid parameters, the component gracefully handles the exception.

H Quality

WDK-FT-04

The core behavior of the component works correctly and is in accordance with the functional specification.

H Quality

WDK-FT-05

Core behavior of the component works correctly against the current version of the docbase as well as the last version of the docbase.

H Quality

General Guidelines

Audience This document is initially targeted at all internal Documentum engineering teams that use WDK for the development of their respective products and applications. The guidelines are also expected to be used by the external development community including customers and partners.

How to be used This document is intended to be a tool for use by developers to design and develop WDK-based components to optimize the quality, reusability and extendibility of their code. A decision may be made by the developer(s) of a given component to not follow specific checklist items. In these cases, a justification should be documented such that the trade-offs can be proactively evaluated.


14/25

Definitions and Overview of WDK Components

Logical definition: An encapsulated, reusable piece of Web browser-based user interface. There are already several presentation technologies that allow this (such as JSP, XSLT) but a component hides the actual user interface implementation from the caller by providing a Component Contract and a Component Dispatcher to call it.

Physical definition: Each WDK component is defined by an XML resource file that contains pointers to the following: • A Java class • One or more JSP files • A resource string file

Characteristics Context Sensitivity A component can provide a user interface that is sensitive to the context within which the component is called. For example, a “Properties” component may have any number of user interface representations and behaviors based on the type of object viewed. The specific user interface representation is driven by parameters (the context) passed to the component such as "object Id". Context sensitivity allows for the extension of a component (e.g. to support the introduction of new types) without affecting the caller. This feature was influenced by the configuration/customization model of Documentum Smartspace. Presentation Technology Independence A component may be implemented using one of many presentation technologies such as JSP, XSLT, WDK 4.2 and WDK 5 (Web Forms). This allows for the most appropriate user interface presentation technology to be chosen for the component or application (or portal) at hand. A side effect of this functionality is that a component implementation may be migrated or updated from one presentation technology to another with minimal impact to the caller of the component, for example, JSP to WDK 4.2 or WDK 4.2 to WDK 5. Context sensitivity may be applied to any component regardless of presentation technology employed. Reuse Each component supports a contract (its public interface) that all other components and containers (application or portal) communicate through. The contract consists of Parameters (for initializing the component), events (for responding to interactions made by the user) and properties (for interrogating the state of a component at any given time). The contract discourages access to the internals of a component, thus allowing the implementation to change over time without impact to the caller. Also, brittle dependencies between components are broken, therefore allowing individual components to be reused in multiple containers without the need to pull in a tangled web of dependent components.


15/25

Configuration Components, by their virtue of being re-usable, exhibit configurable aspects of their user interface. Configuration in this context means that both the layout and behavior of the component may be declaratively modified without rebuilding the component. However, as the component is initially developed, the configuration points have to be taken into account and built into the Component. Generally, each configuration of a component is tied to a different calling context. Customization To achieve ultimate reuse, a Component may be extended and customized (through code development). This allows for a Component to provide additional or alternative behavior based on the calling context. Loose Coupling with Component Caller Typically, in a Web-based Application, the Container (such as an Application or Portal) issues a direct reference to a re-usable page via a URL. In this situation, the URL points to a specific user interface implementation, therefore restricting the configuration and extendibility of the Container. In effect, the Container and Component are early bound, that is, tied together at development time. However, in order to support the Component characteristics listed above, the Component infrastructure provides a method for calling Components indirectly. In effect, late binding is provided where the user interface implementation is derived and the appropriate URL generated at run-time.


16/25

WDK Component Guidelines Because the WDK component checklist is very specific, guidelines in this section only appear where they are necessary to provide clarification or examples.

WDK Components Design WDK-01 Component is designed to run within a container (or is a container itself) Components that are not containers should not contain controls that are provided by containers, such as a title or OK/Cancel/Help buttons. The first choice is to use an existing container. If a new container is required, document the new functionality provided by the container.

XML Configuration File [WDK-XML-02a] File follows naming conventions Note: for naming conventions, italics are used for variables and [] are used for optional elements. Actions: Actions definition file names should be structured as:

object type_actions.xml For example:

“dm_folder_actions.xml”, “dm_queued_actions.xml”, etc.

Action names must be all lowercase, and where practicable, the first word of any action name should be a verb, the second a noun. For example:

“importrendition”, “subscribe”.

All actions that are pertinent to a type should be defined in one actions definition file. Components: Component definition file names should structured as:

operation_[object type]_component.. For example:

“delete_notification_component.xml”, “edit_component.xml”, etc.

Component names must be all lowercase; and where practicable, the first word of any component name should be a verb, the second a noun. For example:

“checkin” “sendlocator”.

For those Components that are containers, “container” should be appended to the name. For example:

“checkincontainer”, “newcabinetcontainer”.


17/25

Only one component should be defined in one component definition file.

[WDK-XML-02b] File follows component library location conventions Actions: Action definition files should reside in an “actions” folder. For example:

“T:\app\webcomponent\config\actions”, “T:\app\webcomponent\config\admin\actions”, etc.

Components: Component definition files should reside in a component folder under the “library” folder. For example:

“library/checkin”, “library/search”

[WDK-XML-04] Contains functional component description The <desc> tag in the XML configuration file should contain a summary of what the component. It should NOT be a restatement of the component name. While the description does not affect the functionality of the component itself, it is extremely important for reuse, in that it should provide enough information to help a developer decide whether the component is a candidate for reuse when scanning a list of descriptions, such as those generated by the componentlist component. The following are bad and good examples of the description for a component called checkin_component.xml: Poor: <desc>Component to check in objects. </desc> Much better: <desc>You can use the checkin component to allow users to do the following: 1. Check in previously checked-out components. 2. Set various properties, such as version numbering, locking, and format.</desc>

[WDK-XML-05] Component is configurable: Contains values that can be configured to change behavior of components, rather than requiring customization. Example: Allows configuration of whether major and/or minor versioning is allowed for checkin, which columns are visible, and so on) Comments should be included to explain what is configurable and the associated possible values.

[WDK-XML-07] Has Help ID defined Best practice: Make help ID = component ID.

[WDK-XML-08] Backwards-compatibility Did not add or remove required <params>. Adding or removing “required” params of extended components with new names will affect backward compatibility. Adding or removing optional params will not affect backward compatibility.


18/25

JSPs [WDK- JSP-02a] File follows naming conventions JSP file names should be naturally descriptive, contain no spaces, and use mixed case with each word capitalized except the first letter of the first word. For example:

“cancelCheckoutClientCheck.jsp”, “deleteDocument.jsp”

[WDK- JSP-02b] File follows component library location conventions JSP files should reside in a component folder under the “library” folder. For example:

“library/checkin”, “library/search”.

All JSP files that are pertinent to a component should reside in the same component folder.

[WDK- JSP-03] No Java code in JSP Used existing controls or new custom controls rather than code in JSP Using Java code in a JSP goes against the principle of separating application/business logic from the presentation.

[WDK- JSP-05] Used HTML element ID rather than referencing Form[0] Even when there is only one form on a page, you should not reference a control with Form[0], because this will not work in a portal environment. Instead, define an HTML element ID and use that to reference the control.

[WDK- JSP-07] Used WDK 5.2.5 layout tags in place of HTML layout tags WDK layout tags (such as body, header) are new in 5.2.5. (No need to retrofit previous versions.) This allows the component to run on a portal as well as an application server).

[WDK- JSP-08] Used a background style such as contentBackground on a body tag If you use a style on a body tag, make sure it is a background style such as contentBackground. Other styles can bleed through components.

[WDK- JSP-09] Complied with Section 508 Guidelines There are general guidelines for complying with Section 508 requirements, and guidelines specific to the WDK platform, such as the following:

• Used <th> tags for header cells rather than <td> • Used dmf:image control, not <img> tags • Provided <alt> text for all images

For more specific WDK guidelines on 508 compliance, see the Web Development Kit and Client Applications Development Guide, and for general requirements see the United States Government Section 508 standards at http://www.section508.gov/index.cfm?FuseAction=Content&ID=12.


19/25

http://www.section508.gov/index.cfm?FuseAction=Content&ID=12

[WDK- JSP-12] Used WDK theme styles Purpose: To provide a consistent look and feel across all components To facilitate configuration of theme or branding

Behavior Class [WDK-BC-02a] Behavior class file follows naming conventions Component class name should resemble the component name; and use mixed case with the first and each subsequent word capitalized. For example:

“NewCabinet.java”, “NewCabinetContainer.java”

All component package names must be entirely lowercase and should follow the location of the component definition file. For example:

“com.documentum.webcomponent.library.subscription”, “com.documentum.webcomponent.library.attributes”.

The first word of any event handler method should be ‘on’. For example: “onShowOptions”, “onLogin“, etc.

Actions class names should use mixed case with the first and each subsequent word capitalized and be structured as:

[Verb][Noun]Action.java For example:

“DeleteQueueItemAction.java”, “CheckoutAction.java”.

Precondition class name should use mixed case with the first and each subsequent word capitalized and be structured as:

[Verb][Noun]Precondition.java For example:

“DeleteDocPrecondition.java” All action package names must be entirely lowercase and should follow the location of the action definition file. For example:

“com.documentum.webcomponent.library.actions”

[WDK-BC-02b] Behavior class file follows component library location conventions Java class packages will dictate where source codes and compiled classes will reside.

[WDK-BC-03] Extended component rather than duplicated Exceptions to this guideline should be reviewed for appropriateness with the WDK team and/or owner of the original component.


20/25

[WDK- BC-04] Did not have context-sensitive behavior (used WDK “filter” to configure component behavior in XML definition) For example, use ‘filter’ to scope the configuration option ‘enableShowAll’: <filter role='administrator'> <enableshowall>true</enableshowall> </filter> And in the behavior class:

boolean bEnableShowAll = false; Boolean enableOption = lookupBoolean(“enableshowall”); If (enableOption!= null && enableOption.booleanValue == true) { bEnableShowAll = true; } Note that the boolean variable ‘bEnableShowAll’ will be set to true only if the user is of role 'administrator'

[WDK- BC-05] Used component arguments and return values to pass data to or between components, not global caching facility Example: Avoid using HTTP sessions or static variables as data passing medium However, if passing an object between components is necessary then follow these guidelines: The caller component should generate a unique variable name (within the current user session) and store the object with “SessionState” under this unique name. Add a “required” argument to the calling component that is used to specify the variable name that holds the object in the “SessionState” The caller component should remove the object from the “SessionState” upon return from the calling component

[WDK- BC-07] Code contains no business logic (invokes encapsulated business logic) Use SBOs or TBOs as much as possible for business logic; when this is not possible, at least make sure that the business logic is encapsulated in the behavior class.

[WDK-BC-08] If applicable, invoked business logic through the job execution framework (5.2.5 onward) The job execution framework will be available in 5.2.5. It enables pre- and post-processing of business logic and allows business logic to run asynchronously.

[WDK- BC-14] Implemented one or more custom attribute data handlers WDK 5.2.5 introduced a new interface, IcustomAttributeDataHandler, to facilitate more efficient queries for custom data for most, if not all, listing pages in WDK. Please refer to Web Development Kit and Client Applications Development Guide and the WDK JavaDocs for more information.


21/25

NLS Properties Files [WDK-NLS-02a] File follows naming conventions NLS properties file names should use mixed case with the first and each subsequent word capitalized, and have the following structure:

ActionNameNlsProp.properties, or ComponentNameNlsProp.properties

For example: “CancelCheckoutNlsProp.properties”, “CheckoutNlsProp.properties”.

Note that one should follow Java’s “ResourceBundle” naming convention in order to generate localized versions of the properties files.

[WDK-NLS-02b] File follows component library location conventions NLS properties file location should resemble the associated component or action location. For example:

“T:\app\webcomponent\strings\com\documentum\webcomponent\library \checkout”, which matches “T:\app\webcomponent\ config\library\checkout\” “T:\app\webcomponent\strings\com\documentum\webcomponent\library \actions”, which matches “T:\app\webcomponent\ config\actions”

[WDK-NLS-07]Tested for internationalization For information on internationalization and localization practices, see the Web Development Kit and Client Applications Development Guide.

WDK Controls [WDK-CTRL-03] Created a new control file for this component Don’t use codes to generate HTML controls; instead leverage existing controls or construct new custom controls based on WDK control framework. This aligns with the WDK programming model of handling controls, such as rendering, event handling, state management.

[WDK-CTRL-04a] File follows naming conventions Control class name should be naturally descriptive, contain no spaces, use mixed case with the first and each subsequent word capitalized. For example:

“Image.java”, “Label.java”

The corresponding Tag class should start with the control name and end with “Tag”. For example:

“ImageTag.java”, “LabelTag.java”

All control package names must be entirely lowercase and end with “control”. For example:.

“com.documentum.webtop.control”, “com.documentum.web.form.control”


22/25

All tag and attribute names must be entirely lowercase All namespaces for Documentum controls should start “dm”; for e.g. “dmf”, “dmfx”, “dmwt”, etc.

[WDK-CTRL-04b] File follows component library location conventions Controls do not have a set location.

[WDK-CTRL-06] Used base tag class render helpers to render HTML tags that conform to WDK protocol renderEventHREF(…) & renderEventCall(…) renderNameAndId(…) renderStartToolTip() & renderEndToolTip() Warning: Don’t render HREFs directly. Doing so can cause servlet write connection exceptions in BEA.

[WDK-CTRL-08] Control class property getters and setters are type safe Example: Boolean values are passed/returned for Boolean properties

[WDK-CTRL-10] Formatted and escaped all rendered HTML values to render well-formed HTML This prevents a security risk by allowing JavaScript to be entered as a value. Example: out.write(Util.encode(formatValue(control.getValue())));

[WDK-CTRL-12] Internationalization For information on internationalization and localization practices, see the Web Development Kit and Client Applications Development Guide.


23/25

WDK Component Unit Testing [WDK-UT-02] File follows naming conventions Test class name should be the same as the behavior class name and be prefixed with “Test”. For example:

“NewCabinet.java”, behavior class “TestNewCabinet.java” test class

All component package names must be entirely lowercase and should follow the location of the behavior class file. For example:

“com.documentum.webcomponent.library.subscription”, “com.documentum.webcomponent.library.attributes”.

[WDK-UT-03] File follows behavior class library location conventions Java class packages will dictate where source codes and compiled classes will reside. NOTE: If test classes require access to protected methods, place them in a separate parallel directory structure with package alignment (this is actually recommended for all test assets): src com documentum webcomponent library attributes Attributes.java test com documentum webcomponent library attributes TestAttributes.java

[WDK-UT-04] Test methods in test class For each public method in the behavior class, a corresponding test method exists in the test class and is prefixed with “test”. The first letter after “test” should be changed from lowercase to uppercase. For example:

“onInit()”, behavior class method “testOnInit()” corresponding test class method


24/25


25/25

Key Documents/References The following sections contain general requirements and best practices that apply to the design of good components.

General Overview of Development and Customization Options (Documentum Developer Site, http://www.documentum.com/developer/Roadmap5/index.htm )

WDK-specific Web Development Kit Development Guide (Documentation Library cabinet in dm_notes) Web Development Kit and Applications Reference Guide (Documentation Library cabinet in dm_notes) Documentum Component Exchange (Documentum Developer Site, http://www.documentum.com/developer/componentexchange.htm )

http://www.documentum.com/developer/Roadmap5/index.htm

http://www.documentum.com/developer/componentexchange.htm