Basic Customization > User Interface Customization > Adding Actions and Hooking Them Up in the UI > Action Framework for Windchill Client Architecture > Defining a New Action > Adding Validation Logic for Your Actions
  
Adding Validation Logic for Your Actions
When creating a new action, there might be logic that you want executed to determine if that action should be enabled, disabled, or hidden in the user interface. You can write this logic in a class called a validator. See UI Validation for details about the validation service, writing a validator, and registering the validator for your action.
nonSupportedTypes and supportedTypes Attributes
By specifying supportedTypes or nonSupportedTypes, the action framework either enables or disables the action depending on the object types mentioned. This filtering is applied only for a customized menu.
The supportedTypes or nonSupportedTypes filtering is applied before any other validation service class defined by application developers. In other words, it is a universal filter.
• If an action is disabled using the nonSupportedTypes attribute, then any custom validators that have been written are not executed.
• If an action is enabled through the supportedTypes attribute, then any custom validators that have been written are invoked.
For example:
<objecttype name="object" class="java.lang.Object" >
<action name="reports" enabledwhensuspended="true">
<command
url="netmarkets/jsp/carambola/customization/reports/base.jsp"/>
<nonSupportedTypes
value="wt.doc.WTDocument,wt.part.WTPart"/>
</action>
</objecttype>
Alternatively you can also use:
<objecttype name="object" class="java.lang.Object" >
<action name="reports" enabledwhensuspended="true">
<command
url="netmarkets/jsp/carambola/customization/reports/base.jsp"/>
<nonSupportedTypes>
<type value="wt.doc.WTDocument" />
<type value=" wt.part.WTPart " />
</nonSupportedTypes>
</action>
</objecttype>
You can specify whether this filtering is applied to subtypes of an object. By default, subtypes inherit this attribute. You can control this functionality by adding the additional attribute applyToDescendants:
<supportedTypes>
<type value="wt.foo.Bar" applyToDescendants=”false” />
</supportedTypes>
* 
Supported and non-supported types can also be added using xconf properties See Defining Supported and NonSupport Types in XConf for more information.
Parameter
Default Value
Possible Values
Req?
Description
value
Any object types. Separate using commas.
Yes
Enables or disables the action for the listed object types.
Actions are enabled or disabled for third level navigation and row level actions. No filtering is done for menu bar and toolbar actions.
applyToDescendants
true
true
false
No
Whether you want the type to apply to inherited subtypes. If true, then all subtypes are supported or non-supported as well. If false, then only the types specified are supported or non-supported.
Defining Non-Supported and Support Types in XConf
The nonSupportedTypes and supportedTypes filtering can also be added using xconf properties. There is a type-based xconf action filter that looks through the typeBasedActionFilter.properties file.
Specify the property in the following format:
<Property name="<action object>.<action name>.
<supportedTypes or nonSupportedTypes>" value="com.foo.Bar" />
For example:
<Property name="annotation.annotationSets.nonSupportedTypes"
value="wt.part.WTPart" target="codebase/typeBasedActionFilter.properties"/>