Rickard Öberg wrote:
> 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.
>
Ok, I can follow that argument. In other words, you would likely use
Constraints in Qi4j where you, in a more strongly typed language like
Ada, you would define a type of integer that can only have a value in
the range 1 through 10 or something like that. But then, if that's the
case, having a constraint violation is a programming error and shouldn't
be used for doing user entered data validation in any way. It becomes
incumbent on the caller of the method to make sure that the constraints
will always be met such that if a value is ever being set that results
in a constraint violation the caller is missing checks to ensure that
the constraint won't be violated. In other words, if the client is
being written properly, there won't ever be constraint violations. But
then that still leaves it up to the caller to validate the input.
> 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?
>
I think it's reasonable for Swing or other desktop based clients or even
web clients with heavy ajax usage. I just happen to be one of those
that believes in creating web applications by progressively enhancing
them. That means you create the plain web app without any css or
javascript, make sure it works and then add the css and javascript
later. This process means that your app is sure to look reasonable and
work regardless of the capabilities of the browser the user is using.
So, in a plain web form you can't do the kind of field level
validation/constraint checking you're talking about. You'd have to wait
until the dialog is "ok"'ed to do it all. But this would be equally
true if it were a web service that was being used, not just a primitive
web form.
On the other hand, in a more advanced AJAX form you might want to be
able to instantly show the user that the name they've entered is
invalid. Google does this with their sign up forms I believe. So
uniqueness is not necessarily something that you would only want to
check when "complete"ing a unit of work.
Plus, I really do think the uniqueness of a name is an important
constraint. That way it could be effectively enforced by the
persistence mechanism as well (such as marking it unique in a RDBM).
In the end I think validation is a much more complex topic than most
people are willing to give it credit for. I certainly don't have all
the answers. Though I'm starting to think that what you said about the
constraints being used as "types on steriods" is the best. Constraints
should probably remain simple and not involve anything beyond the actual
value being set. For rules that involve that value as it relates to the
rest of the system, you should leave that to be checked elsewhere.
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
