A user posted a question like this recently on the OTN forum:
Let's say I have an employee entity with an attribute "HairColor". In my application HairColor is optional for male employees, but required for female employees. Can I leave the mandatory flag off on "HairColor" at the entity level, but enforce the mandatoryness in a View Object that I create which only queries the women employees?" I've modified the JClient bindings in a generic way to display required fields in a different color.
The simplest way to model this situation would be to create a sub-entity WomanEmployee that extends the Employee entity. In the base Employee entity, the "HairColor" would be not-mandatory. In the subclassed WomanEmployee it could be marked as mandatory. When the "AllWomanEmployees" view object gets created, it can be associated to the WomanEmployee entity usage instead of with the base entity. This approach has the benefit that the customized bindings that read the value of the isMandatory() flag on the attribute definition will appropriate see that it is mandatory for a WomanEmployee and show the field in a different color.
Alternatively, you could implement the conditionally-mandatory attribute using a validation rule. For example, on a Department employee, you could write a validation rule that enforces that "Loc" is mandatory when "Dname" has a value that begins with an "X" by writing a method like:
public boolean validateLocMandatoryIfDnameStartsWithX() {
if (getDname() != null && getDname().toUpperCase().startsWith("X")) {
if (getLoc() == null || getLoc().equals("")) {
throw new AttrValException(CSMessageBundle.class,
CSMessageBundle.EXC_VAL_ATTR_MANDATORY,
getDefinitionObject().getFullName(),
"Loc",null,null);
}
}
return true;
}
Then you associate a method validator with your Department entity, tied to the validateLocMandatoryIfDnameStartsWithX method. Of course, instead of throwing the built-in error message from the oracle.jbo.CSMessageBundle, you could use your own message bundle class, or could thrown your own custom subclass of AttrValidationException, if it's more appropriate. The drawback to this approach (given the requirements in the question) would be that the isMandatory() flag on the attribute definition would reflect that it's non-mandatory, so the field would not be automatically colored to show that it's mandatory to the user.
9:51:56 AM 
|
