I actually went ahead and removed IValidationRule (swt/swing
code has been updated).
Kind regards,
Elias.
Von: riena-dev-bounces@xxxxxxxxxxx
[mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Volanakis, Elias
Gesendet: Wednesday, July 09, 2008 15:59
An: Riena Developers list
Betreff: AW: AW: [riena-dev] Comments regarding Validation
Hi Christian,
your changes look good.
+1 for removing the IValidationRule
However there is a small issue with the semantics of the
ValueBindingSupport#removeValidationRule method:
ValueBindingSupport vbs;
vbs.addValidationRule(ruleX, false);
vbs.addValidationRule(ruleX, true);
vbs.removeValidationRule(ruleX); // ???
From my POV this should remove both rules. I've added a
(currently failing) test case to ValueBindingSupportTest that assumes this.
Regards,
Elias.
Von:
riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Christian Campo
Gesendet: Wednesday, July 09, 2008 07:16
An: Riena Developers list
Betreff: Re: AW: [riena-dev] Comments regarding Validation
Ok so I did a little bit of testing and made some changes.
(ME the non-UI guy :-) )
I changed the method addValidationRule(IValidator) to
addValidationRule(IValidator,boolean validateOnEdit) (actually deprecated the
first and did a new method)
So now for every IEditableRidget you can specify when the
rule should be checked (rather than let the rule decide). Still the rule
decides whether a violation is a block or not.
txtDate.addValidationRule(new
ValidIntermediateDate(DATE_PATTERN), true); // does a loose check for date
ON_EDIT (thats what the true is for)
txtDate.addValidationRule(new ValidDate(DATE_PATTERN),
false); does a strict check on date (different rule) but not on edit but when
the focus is lost (false)
So maybe Elias you can look at what I did and tell me what
you think.
If you like it (and I hope you do), I think we can get rid off
IValidationRule and stick to IValidator.
I also changed AbstractValidDate our DateValidator to use a
different implementation. In the previous version it used a
GenericValidator.isDate and that reported a date of "25.12.200x" as
valid. So now I use the SimpleDateFormat itself and check on the parsePosition
and compare it to the length. If not everything was parsed then the field is
invalid. That seems to work a lot better.
Any feedback welcome. I've checked the implementation in and
modified the example.client to use the new methods. If everybody likes it, I
can remove the deprecated stuff and remove IValidationRule tomorrow.
Also modified our swing version so that it compiles.
Am 09.07.2008 um 11:13 schrieb Christian Campo:
comments below
Am 09.07.2008 um 10:48 schrieb Gayk Wanja:
Hi Elias,
> you were right; I've fixed this:
> - ValidEmail and ValidExpression changed to be non-blocking. This fixed
some issues with the example.
Something I messed up, thanks for fixing.
> Note that the point discussing some limitations of the current validation
APIs still apply. In particular we should think about:
> - if validation time is decided by the rule implementer or the rule user
I'd vote for rule user (see my past comments on why I think this is the way to
go).
I am still also undecided here.
(see below)
> - if validation response (block, dialog, message, xyz) is decided by the
rule implementer or the rule user
I'd vote for rule user, keeps rules more versatile.
I am not sure if that is true
though. How versatile can a DateValidator get. It will validate a date and
nothing else. Same as EmailValidator. Even a Validator for regex only does just
that. I am currently undecided on this. Putting it on the rule user must mean
that it is sensible to have different values for different usecases.
> - how to react when invalid values are introduced programmatically via
ridget.setText() / ridget.updateFromModel()
I'd vote for throwing an IllegalArgumentException, so the programmer can take
action on this kind of problem, for example converting old data from the
database to a new format. It also provides a stacktrace to fix the bug where it
happens. I personally prefer not to have an issue ripple through the whole
applicaton and see the bomb explode in some entirely other location, just
because some other bug prevented this problem to be seen immediately in the
ridget.
In the end ridgets can also be uneditable, so the user may see there's
something wrong but not have any possibility to fix it manually, so we'd get
bug reports like: "There's a questionmark in my date field and the
application won't save any data, telling me it's broken", instead of a
proper stacktrace.
+1 for the
IllegalArgumentException
> - if we want to update validation status
when rules are added removed
That would be nice, wouldn't it? Alas "nice" does not necessarily
mean "implemented in half an hour"..
So I guess I wouldn't vote for anything here :-).
+1
I'd like to add the question
- do we really need "direct writing" in our ridgets?
Updating the model could happen on enter, on focus transfer, on closing
the form (which included closing the application), on navigation and on manual
updates. I see that "direct writing" causes some problems, like
either you must block temporarily incorrect input (which is frustrating to the
user and may not work at all for regex-rules for example) or write to a buffer
and only write the last valid buffer to the model on keypress (leaving values
in the model, which are correct, but not the ones seen in the user interface).
I guess not having something as "direct writing" would get rid of
those problems. Is the benefit of direct writing worth the issues it raises?
I think that direct writing is not a nice to have feature
but a requirements from our users. Direct writing means that correct data can
be directly written to the model and through a property change listener you can
(it what ever way) react to these changes i.e. suggesting completion, filter result
sets. Some rules also work a lot better if you use direct writing, because the
rule is only checked when data is about to be written to the model.
removing direct writing would at least currently also allow
all sorts of letters in number fields for example.
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev