Order of property validation

[01es]

Description

Entity validation happens property by property in the order of properties, returned by AbstractEntity.fieldsForProperties(). This method in turn is based on Finder.streamRealProperties(...) that uses the order of field declarations (this is factually, but not guaranteed by the JVM specification), which effectively defines the order of validation.

Generally speaking this approach works well as validation of properties in any order should lead to the same result. However, when it comes to UI, aligning the order of property editors in Entity Masters and the declaration of the underpinning entity properties becomes required to guarantee that validation errors would be reported in the order that is natural from the user's perspective as observed in the UI -- from top to bottom and from left to right. Also, in future, UI layouts may support a right-to-left direction.

Even if we consider the order of property declaration to be guaranteed by the JVM (it is not), changing the order of declarations each time a layout needs to be changed, or when extending entity definitions based on some abstract entity, is less than ideal, violating, for example, the single responsibility principle and, generally speaking, coupling the order of property definition with the order of their UI representation in Entity Masters.

To improve this situation, it is proposed to provide an API that could accept the order for property validation. The working proposal is to overload method AbstractEntity.isValid that would accept an instance of java.util.Comparator<MetaProperty> that would be used to define the order for property validation. Such alternative isValid(comparator) could then be used by entity companion's method save by passing in a comparator that could be constructed automatically based on the order of property declarations in the companion's default fetch model (i.e., a model returned by IEntityReader.getFetchProvider()). So, effectively the order of properties in the default fetch model, which is defined specifically for the purpose of Entity Masters, would define the order of property validation.

It would be up to application developers to either use the existing .isValid or the proposed .isValid(comparator) API in the save methods.

Remarks

The proposed approach would provide the desired outcome - ability to specify alternative order of property validation and close, at least semantically, relationships between the order of properties in the Entity Master layouts and the order of their validation. However, even with this change, a bit of inconsistency would still remain. More specifically, because the UI layout is specified at the level of definitions for Entity Masters, fetch models and the UI layouts need to be kept in sync. This is not as bad as having to sync the UI layouts with the property declarations, but it is definitely not ideal. Right now, we do need to make sure that all properties used in an Entity Master are added to the default fetch model. With the proposed change, we would also need to ensure that the order of properties declared in a default fetch model matches that of properties in a corresponding Entity Master.

Unfortunately, it is not possible to derive the default fetch model from an Entity Master declaration. Default companions' fetch models as returned by IEntityReader.getFetchProvider(), are often deeper than the first level of entity properties displayed by Entity Masters. Subproperties are often and mainly required by pre- and post-conditions for validation purposes. This is why, it is not sufficient to simply derive a default fetch model from a corresponding Entity Master definition.

Expected outcome

Ability to specify alternative order of property validation and close, at least semantically, relationships between the order of properties in Entity Master UI layouts and the order of their validation.