Community
Participate
Working Groups
More info please.
Partial validation seems to work OK, except for the case where we have TIME_LATE. In this case the isPartialValid(...) message is not called per keystroke. Is the behavior we expect that isPartialValid(...) is called per keystroke with TIME_LATE and isValid(...) is only called just prior to the actual model being updated from the target ? TextControlScenario.testScenario07() is commented d out right now (so we don't break the JUnits) but if you comment it in it shows that TIME_LATE does not call isPartialValid(...) per keystroke
Folks, Does anyone care to comment on whether partial validation should occur per keystroke with TIME_LATE ? At the moment it doesn't, however my understanding is that partial validation should occur per keystroke irrespective of the update policy ? I can implement it to do so, however in the current spirit of lots of bugzilla talk taking preference over writing code I'd like to get input before I fix it.
Joe, Your original comments were right on the mark. If we do partial validation at the same time as full validation (ie: on focus lost), there is no longer any need for partial validation. But things like social security numbers and localized dates can benefit from keystroke-level validation even when the data isn't being committed until focus lost.
> If we do partial validation at the same time as full validation (ie: on focus > lost), there is no longer any need for partial validation So what is SWTUpdatablePolicy.setValidatePolicy(...) for ? If IValidator can do partial and full validation and we call partial per keystroke and full when the change event is fired (per keystroke on TIME_EARLY and focus on TIME_LATE) why do we have another switch ? I can't see why validatePolicy(...) would ever be used. At the moment we don't actually use the field - it is passed into the constructor of TextUpdatablePolicy but never referenced after that. Are you OK if I just delete the concept of validate policy being a switch and we just keep updatePolicy ?
(In reply to comment #5) > Are you OK if I just delete the concept of validate policy being a switch and > we just keep updatePolicy ? Yes.
Partial validation is not implemented - our plan is to add direct support for masked editing instead.
I need Partial Validation and have just had to replace it's functionality with a few VerifyListeners. I agree however given the positive refactoring that has taken place in the last few months that it should not/can not be implemented in Data Binding as "Partial Validation". Masked editing sounds good. My use case is simple: I don't want users to be able to enter non-numeric characters into Text controls bound to Numeric values. I had previously implemented this by setting non-primitive StringToXXValidators in the bindspec as a Partial Validator for numeric types. I want this to be automatically handled by JFace Data Binding. It could perhaps be made optional behaviour for when it is not desired. I have looked at where "Edit Masks" can be logically added in the latest Data Binding without breaking Realms or the current API cleanliness. As an alternative I have looked at adding at least the facility to veto changes in Text controls using a Validator (to prevent entry of invalid values). One attempt I made was through introducing a vetoValidator to ValueChangeStrategy to allow veto of TextObservableValue changes before afterGetValidator. I stopped working down this path however due to the required Realm.exec() calls in ValueBinding.doUpdate() making it difficult/impossible to return a veto result to the change listener handleValueChange() methods to prevent the edit. I wanted to confine this work to TextObservableValue, but that would involve queries of the type of the model observable type from the target which seems wrong (and also probably this information is inaccessible). I still would like us to write a clean replacement for the relevant use cases behind "Partial Validation", such as mask editing. Any ideas anyone as to how/where this should be implemented and to the extent of the proposed feature?
Have you looked at Nebula's masked editing widget [1] yet? [1] http://www.eclipse.org/nebula/widgets/formattedtext/formattedtext.php
Hmm, attractive controls. I had not come across these, thanks. If I set about writing an Observable for FormattedText and some form of automatic masking support (and possibly for binding some other Nebula widgets) would I be able to contribute it into Data Binding or would the code have to remain outside of the project?
(In reply to comment #10) > would I be able to contribute it into Data Binding or would the code have to > remain outside of the project? We cannot make the existing data binding plug-ins depend on Nebula, but how about contributing to the Nebula project? You could file an enhancement request against Nebula to start a discussion about this. (Please add me to the cc list.)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
