Hello,
from other frameworks I know validation like this:

• bind property values
• validate the state of the underlying object (view model) and get a list of violations
• display violations and react otherwise like: disable the save button if !violations.isEmpty()

ZK, on the other hand

• misuses exceptions to signal violations.
• does not set the property on the view model in case of violations
• renders the form view inconsistent with the underlying view model

ZK just makes IMO too many assumptions what the developer wants to do with violations. This makes it hard to impossible to react differently from ZK's assumptions. Some caveats:

• exceptions have the purpose to signal exceptional conditions (hence, the name). It is not all exceptional that the user enters invalid data into a form. Using exceptions to realize normal system behavior leads to problems (see below).

• because the property is not set by ZK if there is a violation, the form view is afterwards inconsistent with the view model.
  -> Consequently, an initially correct view model is always correct and can always be saved even if the form shows invalid values. That is very strange.
  -> It is not possible to validate the view model to determine whether submitting the form is a legal operation because the form view has nothing to do with the actual view model, they are inconsistent.

• because the property is not set by ZK, it is almost impossible to validate the view model as an object, i.e., to check class-level constraints which require traversal of the object graph.
  • For example, in our application you can enter a key for a new object. The key must match the key type defined for the container of the new object (e.g., [numeric]*). So, a JSR 303 constraint could do this easily. However, this cannot be interpreted by ZK unless I set the property in my Jsr303Validator (implements ZK Validator) before I perform validation.

In our application we have the special case that we support undo / redo:
Every time a setter is called on the view model an UndoableCommand is added to the command queue.

• The exception makes it impossible to do this, because the setter is not even called in case of violations. So it is impossible to undo invalid changes.
• One remedy would be to set the property in the validator (an ugly workaround). However, in this case the setter is called twice in case of valid changes. So, I get two undo steps for the same change.
  -> The misuse of exceptions seems to make it impossible to implement our requirements with ZK.

It would be really nice, if there were a simple API that allows just to

• collect all JSR 303 violations
• display them in the form

Nothing more is needed, no exceptions, nor ZK preventing properties from being set.

Maybe there is such an API, and I just haven't found it yet?

Cheers,
David