JavaFX Form Validation
tbee at tbee.org
Tue Jun 12 10:44:56 PDT 2012
Point being that the validators should be pluggable and customizable, so use an annotation approach as the basis would be bad. The other way around, validators that take their cues from annotations, would be good.
On 2012-06-12 19:35, Werner Lehmann wrote:
> Hi Will,
> On 12.06.2012 17:50, Will Hoover wrote:
>> Although, IMHO, the use of validation that doesn't pertain to domain
>> models is more of an exception to the rule versus the rule itself...
> I suppose most people tend to think that other usecases are the special
> cases while the own usecase is the common one. There is probably no way
> to know for sure what the exception is and what it is not. In the end it
> makes sense to have a framework with as few limitations as possible.
> Your suggestion assumes that a domain bean backs most UIs (at least when
> validation is required). I don't think that is true, and I don't like to
> create a domain bean for the sake of validation.
> Furthermore, not every domain bean property translates to exactly one
> control. And typically, domain beans do not have JavaFX style properties.
>> The problem with this approach is that it's very redundant. If you
>> use the same entity/domain model fields in multiple controls (which
>> happens more frequently than one would think- different forms) then
>> the developer is left with the responsibility of ensuring the
>> consistency of the validations across different UI controls.
> Redundancy is bad but: if your validation patterns etc can be discovered
> automatically (e.g. with your pattern annotation) it should be possible
> to connect your validation with whatever JavaFX validation we will end
> up with. Sounds like a form of the mediator pattern. Surely this can be
> made in a generic way.
More information about the openjfx-dev