Hi,
I’ve got impression that NULL value validation is not working correct since build 514.
See the topic Validation and null values - Classic Servoy - Servoy Community also (my posting is the last one until now).
I have an existing record with null value not allowed. The field in the existing record has a valid value. When I clean the field, then build 513 is reacting different compared to build 514. My AutoSave is OFF. I have 2 buttons on my form. One button for ‘Save’ and one button for ‘Cancel’.
In build 513 (3.5) when I make the field empty, I can press the ‘Cancel’ button. Good behavior! Transaction is rollbacked.
In build 514 (3.5.1) when I make the field empty, I can’t press any button. The focus remains in this field until some value is entered.
In my opinion the NULL-value check must be done on saveData() method when autoSave is off (like when using newRecord() ). As long as I don’t have a saveData(), then no NULL-value check must be done. It gives me the possibility to check before the saveData() all fields that are required and give these fields a background color.
When autoSave is ON, then the behavior should be like it is now
Its a bit strange if we have that completely different behavior when auto save is on or off. Also column validators are immediate they work when you leave the field. If this isn’t the case then how is that feedback going to work?
If you have auto save off. then you could make 100 new records over 10 foundsets. Where you could have all kinds of validations errors.
Also column validators work now that there can NEVER be invalid data inside a record, but if we change that then records can have invalid data again that aren’t validated correctly. Or are you saying that only the null validator shouldn’t work in autosave is off? What so special about that one then compared to another?
Then null validator doesn’t do anything when the field isn’t really changed so if it is null (the default value) you can still tab through it or what ever. Only if you change it it is a problem.
Hmmm. See your point.
I am used to validate the data in a pre-save method and use the validation as a kind of extra security.
I probably should not do that.
The reason I liked that idea is because then i could give the user an appropriate error message saying : " Field xxxxx must be entered"
and then give him/her the option of retyping or restoring the previous value. Same thing when validation of non-empty fields fail, then the message would be " Field xxxxx is invalid because …" and i could give the user the same two options.
Now when the user makes a required field empty the solutions on-error method is triggered and in there i do not know which field caused the error
or what the previous value of the field was.
I could try to see if i can get this by using getChangedRecordData or
getEditedRecords.
By the way, i already created a case ( 97229 ) on the behaviour of restoring previous values. I will add a request for the option: retype or restore previous value.
Regards
maybe in a next version we can streamline it a bit by having validations on specific scopes/events and better handling of the feedback to the customer, like being able to set the message that the user should get directly at the validator. So the developer doesn’t have to handle anything anymore after that.
That would be splendid !!
Regards
jcompagner:
Also column validators work now that there can NEVER be invalid data inside a record, but if we change that then records can have invalid data again that aren’t validated correctly. Or are you saying that only the null validator shouldn’t work in autosave is off? What so special about that one then compared to another?
As far as I have noticed, there situation only occurs on NULL-value validation. I’ll try to make a small solution and hope I can reproduce it.