Business Component validation follows the JavaBeans PropertyChange mechanism. A change to an attribute leads to a VetoableChange event notification followed by PropertyChange notification. A PropertyChangeEvent object is passed along with the event containing the Entity Object reference to which the attribute belongs and the new value to be set for the attribute that is being validated. The validators implement VetoableChangeListener events and attach themselves to the listeners list in the attribute descriptors and hence get notified of the changes to an attribute. When a setCurrentRow call changes the current row in a View Object, the Business Components for Java framework invokes Entity Object validation.
To validate an Entity, a validator object is created and attached to the Entity as a VetoableChangeListener. When the Entity Object's validate method is called, the listeners are activated, which in turn perform their validate methods and throw VetoableChangeException in case of failures.
An Entity Object has one public validate method that is called both at change of row currency and commit time. The logic of the validate method is:
Call validateEntity. You can override this method, but you should call super.validate before your own code to invoke the framework's validation mechanism.
validateEntity calls validateChildren on the Entity. The Entity traverses each of its ownership associations where it is the source Entity, and examines the Entity on the destination end. If the destination Entity is marked invalid, the traversing Entity calls the validate method on it.
Perform validations on declarative rules attached to this Entity.
Call setValidated(true) to reset the invalid flag and/or remove the Entity from its owner's list of invalid entities. If the Entity is a top-level Entity (a business object), then remove it from the transaction's list of invalid entities.
Figure 1 is a high-level illustration of the sequence of events and method calls that executes when an attribute value is set in the middle tier.
Figure 2 illustrates what happens if the Entity Object is part of a composition relationship. In this case, the framework tries to lock the topmost Entity.
