Implementing Validation Filters

Action Customization > UI Validation > Procedure – Pre-Validation > Implementing Validation Filters

Assuming the solution-based and role-based checks pass, the next thing the validation service will do when performing a pre-validation activity is to determine which filters apply to the UI component. As previously mentioned, a typical validation filter will contain pre-validation logic that applies to multiple UI components. So rather than duplicating this logic in multiple validators, a single filter can be created and the logic can be selectively applied to UI components or applied to all UI components.

If your filter logic only applies to a small subset of actions, you would create a simple filter. In this case, you would need to individually configure actions where you want this filter applied.

One additional consideration is that there is currently no support for applying a simple filter to attributes.

Implementing a Simple Filter

When implementing a simple filter, you’ll need to create a class that extends com.ptc.core.ui.validation.DefaultSimpleValidationFilter. Then simply override the preValidateAction() method to contain your validation logic and return a validation status.

The following class skeleton is an example of a simple filter that would hide an action if the context object is marked for delete.

public class MarkedForDeleteFilter extends
DefaultSimpleValidationFilter{
@Override
public UIValidationStatus preValidateAction(UIValidationKey key,
UIValidationCriteria criteria){
// ENABLE by default
UIValidationStatus status = UIValidationStatus.ENABLED;
WTReference contextObj = criteria.getContextObject();
if (/*contextObj.isMarkedForDelete() == */ true){
status = UIValidationStatus.HIDDEN;
}
return status;
)
)

Registering Filters

Once you've created a filter, the next step is to register it.

When providing a selector in your registry, the convention is to use the filter class name with replacing the first letter with a lower-case letter, and eliminating the "filter" suffix (e.g., "MarkedForDeleteFilter" would have a selector of "markedForDelete"). The following details should clarify:

To register a simple filter, in *service.properties.xconf, create an entry like this:

Associating Actions with a Filter

Once you've created and registered your filter, the last thing to do is to associate actions with your Simple Filter. This is done in *actions.xml.

Associating Actions with a Simple Filter

Suppose (hypothetically) you created and registered a simple filter called ProblemReportStatusFilter (and registered it with a selector of "problemReportStatus") that disabled actions if a problem report had a certain status. And suppose you wanted to apply it to a few actions. You would find the actions you want to apply your Filter to in *actions.xml and modify them to include includeFilter elements like this:

<objecttype name="problemReport" class="wt.change2.WTChangeIssue"

resourceBundle="com.ptc.windchill.enterprise.change2.changeManagem
entActionsRB">
<action name="create" >
<command class=…/>
<includeFilter name="problemReportStatus" />
</action>
<action name="edit" >
<command class=…/>
<includeFilter name="problemReportStatus" />
</action>
<action name="editModifyContentOnly"
id="editModifyContentOnly">
<command class="…/>
<includeFilter name="problemReportStatus" />
</action>
...

Again, the name attribute of the includeFilter element should correspond to the selector used to register the filter in *service.properties.xconf.

Multiple Filter Inclusions for the Same Action

In theory, an action can have any number of simple filters associated with it. You would just add as many includeFilter elements as you need in *actions.xml.

For example:

The order of the includeFilter elements does not matter, nor does it have any bearing on the order in which the filters are called.

Associating Action Models with a Filter

Once you've created and registered your filter, you can also associate action models with your Simple Filter. This is done in *actionModels.xml.

Associating Action Models with a Simple Filter

Suppose (hypothetically) you created and registered a simple filter called ProblemReportStatusFilter (and registered it with a selector of "problemReportStatus") and you wanted to apply it to a few action models. You would find the action models you want to apply your Filter to in *actionModels.xml and modify them to include includeFilter elements like this:

The name attribute of the includeFilter element should correspond to the selector used to register the filter in *service.properties.xconf.

Multiple Filter Inclusions for the Same Action Model

In theory, an action can have any number of simple filters associated with it. You would just add as many includeFilter elements as you need in *actionModels.xml.

For example:

The order of the includeFilter elements does not matter, nor does it have any bearing on the order in which the filters are called.

You cannot use universal filters and excludeFilter element to exclude OOTB universal filters in Windchill+.

Modular Structure for Customization

<customizationRootDirectory>
├── configurations
│ ├── deploy.xml
│ └── xconf
│ └── custom.site.xconf
└── New-UI
├── descriptor.xml
└── main
├── resources
│ └── Acme-actions
│ ├── AcmePartClient-actionmodels.xml
│ └── AcmePartClient-actions.xml
├── src
│ └── com
│ └── acme
│ └── filter
│ └── HideOrgAdminFilter.java
└── xconf
└── acme.service.properties.xconf

Solution Elements

Element	Type	Description
AcmePartClient-actions.xml	XML	Default system XML file for defining actions in the system. Configure filters for the actions using the includeFilter tag.
AcmePartClient-actionmodels.xml	XML	Default system XML file for defining action models or incremental action models in the system. Configure filters for the action models using the includeFilter tag.
acme.service.properties.xconf	XCONF	Custom service.properties.xconf file to register the newly created filter.Provide the selector in your registry and use the same selector with actions configuration.
custom.site.xconf	XCONF	XCONF file to configure properties for enabling configurable links example in this file.
HideOrgAdminFilter.java	Java	Custom filter to control the visibility of new custom action and action model based on business logic.

Parent topic

Procedure – Pre-Validation

這是否有幫助?