Richard Wallace wrote:
> 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.
Right. And in Qi4j you could even do that more explicitly if you want to:
interface Nameable
{
@NonEmptyString
Property<String> name();
}
can be refactored to:
interface Nameable
{
Name name();
}
and
@NonEmptyString
interface Name extends Property<String>
{}
(Not sure if we actually support this right now, but I think we should)
but Name here is really mostly syntactic sugar, which is important enough.
> 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.
The conclusion that it is a programmer error to set invalid values is a
bit arbitrary, and I could just as arbitrarily say that the client may
try to set any value, and if they are not ok then the set() method will
let you know, with messages that are internationalized and useful in
UI's. Since the latter interpretation makes clients much easier to write
I would go with that :-)
> 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.
That's fine. Just present the field-level errors along with the UoW
completion errors when the form page is returned to allow the user to
fix the errors.
> 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.
Since the semantical validation is done through Validatable it would be
ok to set the values on the object and call checkValidate() continuously
to ensure that no rules are violated while the UoW is in progress.
> 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.
I also think that validation is much more complex than most people
think, and that getting that one right is super-important. Getting
validation right will make everything else soooo much simpler. Not
confusing constraints with the business rule semantical validation is a
good start I think, or else people will try to do funky validations in
constraints which simply shouldn't be there.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
