Richard Wallace wrote:
> At first I thought this would be more troublesome, but I suppose you can
> use a utility setter method so you don't have to wrap all your set()
> calls in try/catch blocks. Something like
>
> void <T> set(Property<T> property, T value) {
> try {
> property.set(value);
> } catch (ConstraintViolationException e) {
> // accumulate or add to some error list
> }
> }
>
> would make it nice I think.
Exactly. This way it is entirely up to the client to choose whether to
deal with the problems one at a time, or in bulk.
> Before now I hadn't looked too much at the Validatable interface and
> what not. But is this going to require me to replicate my constraints
> in my validatable concern? Or could there be a way to have a
> ConstraintsMetValidableConcern that will ensure the constraints are all met?
Well, since it will be impossible for incorrect values to be set it
should be fine I think. Even on construction the constraints should be
checked, e.g. invalid defaults should not be allowed (and if they are
today, that's a bug).
In general, I think it is not a good idea to think of Constraints as
Validation. Constraints are more like "type checking on steroids", i.e.
more related to the type of the input value rather than the meaning.
E.g. it is important that the "name" is a non-empty-string, and it is
absolutely not allowed to have any other values. But, the rule that the
"name" must be unique within a collection of entities may be temporarily
broken within a UnitOfWork, and is more of an Invariant to be checked as
the UoW is completed. Syntax vs semantics.
In UI terms, especially dialogs, I think a form field should never be
allowed to have an invalid input value, so immediately when the user
tries to enter an invalid value there should be a popup about it, and
the user must fix it in order to continue. However, the semantical
checks are only done when the dialog is "ok"'ed, i.e. "complete" is done
in the UnitOfWork, at which point error messages about semantical
problems like duplicate names may be presented.
Does this sound reasonable?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
