You can still model the types you want in Java even integers restricted
to a range. I'd rather prefer concrete types for concrete business
values, where you have:
* validation
* formatting
* hints
* factory methods
* other business methods with business value
even on small types like an ISBN or ILN or ZIP code.
So perhaps abstaining from primitive types in your entities at all would
be a possible solutions.
Regarding validation:
we once wrote a bean based ui-framework that validated state of a java
bean in 4 phases where all the attributes where evaluated within a phase
(and all error reported that failed not just the first) and only if the
phase completed the next phase was run.
The phases were:
1) syntax check (i.e. input formats)
2) mandatory checks (not null)
3) property check (business validation per property)
4) entity checks for depenedend property for the whole entity or even
encompassing related entities
we used an reflection based mechanism to provide the validation code per
property or bean having the property name in the method name and giving
enough context needed for the validation.
what is very important is that the validation rules are mostly not
static but depend on the state of the entity, so if you have an order in
a certain state it has different validation rules than in a previous or
latter state. switching the validation or having dynamic state dependend
mixins dealing with this validation is the key so the Validatable stuff
seems to me more important than the constraints as these would be
handled by the concrete types themselves.
As I'm also very new to Qi4j I still have to get through all the stuff
thats available here. By now the work you've done is very impressive.
Thanks.
Michael
Richard Wallace schrieb:
> 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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
