Ticket #1177 (new discussion)

Opened 2 years ago

Last modified 2 years ago

enhance field validation

Reported by: aecker Assigned to: somebody
Priority: minor Milestone: 0.8.3
Component: biz Version: 0.8.4
Keywords: field validation Cc:

Description

I would like to enhance the field validation to reach:

(1) validation on each call to ctrl.flushValue() to prevent invalid data in cursor record (even on checkbox and other ctrls) to be implemented like in dDataControlMixinBase._lostFocus() (maybe redirect to).

(2) change default value of dDataControlMixinBase._inFldValid to True (in init) and also set to True on any change of the field value (and before revalidation) (and maybe rename var into something like _fldInvalid) / if I dont misunderstood the implementation.

(3) provide a stronger, alternativly usable method to notify user (display box instead of statusbar notification). E.g. if the message returned by the overwritten biz.validateField() method contains an exclamation mark then show as message box.

(4) alternativly (dending on Property value) set ctrl value back to the old value on failed field validation or optionally mark ctrl with lightred background color to inform user that there is still a invalid value entered - to allow user to leave the field (lostfocus) with an wrong value entered, maybe to instead correct another value in the same form which is also involved in the validation result.

Any plans, thoughts, hints about this ?

Change History

11/19/08 05:28:15 changed by aecker

  • priority changed from major to minor.

(follow-up: ↓ 3 ) 11/19/08 07:38:14 changed by ed

(1) validation on each call to ctrl.flushValue() to prevent invalid data
in cursor record (even on checkbox and other ctrls) to be implemented
like in dDataControlMixinBase._lostFocus() (maybe redirect to).

Perhaps just change the individual calls to flushValue() to call the _lostFocus() method instead? If we did that, I'd prefer renaming that method, but I can see the value in this.

(2) change default value of dDataControlMixinBase._inFldValid to True
(in init) and also set to True on any change of the field value (and
before revalidation) (and maybe rename var into something like
_fldInvalid) / if I dont misunderstood the implementation.

You misunderstand. The value is a flag that indicates that we are in the middle of validating a field; it says nothing about the validity of the field. It is used to prevent recursive calls that could potentially become infinite loops.

(3) provide a stronger, alternativly usable method to notify user
(display box instead of statusbar notification). E.g. if the message
returned by the overwritten biz.validateField() method contains an
exclamation mark then show as message box.

That's already there. The dForm class implements a method called 'onFieldValidationFailed()' that gets passed all the failure information. By default it just displays in the status bar. You can override that with whatever custom behavior you like.

(4) alternativly (dending on Property value) set ctrl value back to the
old value on failed field validation or optionally mark ctrl with
lightred background color to inform user that there is still a invalid
value entered - to allow user to leave the field (lostfocus) with an
wrong value entered, maybe to instead correct another value in the same
form which is also involved in the validation result.

Again, that would be a particular implementation that may work in your app, but not in someone else's. That's why we designed the response as a hook method for developers to customize as needed.

(in reply to: ↑ 2 ) 11/23/08 06:39:51 changed by aecker

Replying to ed:

Thanks a lot for your answers on (2), (3) and (4)!!

On issue (1) I fully agree with you renaming the method. I will try to come up with an solution.

11/26/08 07:24:49 changed by aecker

Hi Ed,

I just updated the current dabo SVN revision onto my machine and run my application and the validation now works fine for me!! I also checked the change logs and I think you fixed it with the SVN revision 4698, but I don't know how and if I am allowed to close this ticket?

Thanks a lot for your time and help!! Andi

P.S.: Did you read my comment about the _newRecords update, added on ticket 1175 (after closing)?

P.P.S.: In ticket 1175 you also mentioned that dabo supports multiple primary key fields, but I find still some places with expressions like "col == self.KeyField?", e.g. in dBizObj.appendDataSet() - recently added by you with SVN revision 4687, which will not work with multiple field PKs. Do you want that I compile a list of places, their solutions and add this as a new ticket?