Rickard Öberg wrote:
> Richard Wallace wrote:
>
>> Is that the way that it is intended to work? I thought I read
>> somewhere, though I can't find it now, that the constraints would be
>> checked at the end of the unit of work. I thought this would be a nice
>> way to allow my validation to happen in the domain layer and propagate
>> the violation messages to the application for them to be displayed to
>> the user.
>>
>
> Right, the idea was initially to allow it to happen "late", but it just
> became a wee bit too complex.
>
>
>> The way it is currently implemented only the first constraint violation
>> would be reported to the user, making it unusable as a general way of
>> doing validation as it would require the user to submit the form, fix
>> the first validation error, submit the form, fix the next validation
>> error, ad nauseum as opposed to having all the constraint violations
>> checked at the end of the unit of work and reporting all violations at
>> once.
>>
>
> My current thinking is that when a form is submitted all properties will
> be set *regardless of whether any of them causes constraint errors*.
> I.e. set a property and if it causes an exception then simply continue
> to the next and do that too, and in the end if there were 1 or more
> execptions, present these to the user. That should solve it I think, but
> it requires the UI layer to be aware of this semantics, which I think is
> fine.
>
>
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.
>> The other problem with this mechanism is that it requires a setter to be
>> called for any validation to be performed. The problem with this is
>> that it could allow invalid data to pass. For instance, in the Nameable
>> example that I've used elsewhere we have
>>
>> public interface Nameable {
>> @NonEmptyString Property<String> name();
>> }
>>
>> That non-empty string constraint is only ever going to be checked when
>> nameable.name().set(something) is called. If someone where to simply
>> create the entity and never call that setter, we'd wind up with an
>> invalid object in our entity store.
>>
>
> I have now implemented support for UnitOfWorkSynchronization callbacks
> which allow you to register validation rules that are called before
> complete() is done. Things like the above should be checked during this
> phase, which will solve it I hope. Try it out and see how it goes.
>
>
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?
Thanks,
Rich
> /Rickard
>
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
