Overview of the Data Validation Framework: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
(Created page with '==Motivation== * Currently there are ''different ways of handling'' data verification errors. * Currently there are ''different ways of showing'' data verification errors to user…')
 
No edit summary
Line 1: Line 1:
==Motivation==
==DOCUMENTATION IS WORK IN PROGRESS==
* Currently there are ''different ways of handling'' data verification errors.
'''This wiki page is currently being overhauled to reflect the implementation of the Data Validation Framework.'''
* Currently there are ''different ways of showing'' data verification errors to users.
* Currently there is ''little documentation'' in the openPETRA wiki on the topic of data verification.
All of these should change!


==What the Data Validation Framework Provides==
* ''A common model'' in which data validation is done in OpenPetra.
** Although the way how data validation is done differs on server and client side due to the different nature of these sides, there is still a common model (the Validation Framework) behind it.
* It supports a variety of situations in the most effective manner.
* It makes the raising of data validation errors and the handling of those as painless and easy for the software engineers as possible.
* It ensures that data validation  errors are brought to the attention of the users in a standardised way.
* All data validation warning/error messages can be translated.
** All data validation warnings/errors have a unique 'Error Code' that makes it possible to identify what warning/error the user is faced with. This is especially important for support staff as they will be able to identify the warning/error even if they aren't able to read the warning/error message (as it might be displayed in a language that they don't understand).


==Goals==
==Client Side==
* There needs to be ''one single way'' in which data validation is done in openPETRA - the Validation Framework.
===Validation Scope===
** Although things will look and work somewhat different on server and client side, there should still be a the common model (the Validation Framework) behind it.
====Field-level Validation====
** The Validation Framework should support a variety of situations in the most effective manner.
Data Validation runs when user leaves a Control that has associated data validation code.
** The Validation Framework should make the raising of data validation errors and the handling of those as painless and easy for the software engineers as possible.
* Manual Code performs the validation of the data that the Control is bound to.
** The Validation Framework should ensure that data verification errors are brought to the attention of the users in a standardised way.
** In case the data validation of a Control fails...
* Documentation should be placed in the wiki that guides the software engineers on how to do data validation correctly and in an unified way.
*** a ToolTip is displayed near that control. The ToolTip text explains what is wrong.  
*** the validation error is added to a Collection of validation errors of the Form that hosts the Control (FPetraUtilsObject.VerificationResultCollection).


====Record-level Validation====
Data Validation runs when user changes to a different record in a Grid.
* Manual Code performs the validation of the data of the record. All DataColumns may be checked for data validation errors.
** In case the data validation of a record fails...
*** a MessageBox is displayed, potentially listing ''several'' validation errors of the one record. The text of the MessageBox explains what is wrong.
*** the user is prevented from navigating to another record in that Grid.
*** the validation error is added to a Collection of validation errors of the Form that hosts the Control (FPetraUtilsObject.VerificationResultCollection).


==Considerations==
====Form-level Validation====
===Client Side===
Data Validation runs when the user presses the 'Save' button or chooses Menu 'File' -> 'Save'.'''
====Field Level Validation====
* Code in the 'SaveChanges' Method causes data validation to be run on all parts of the Form that the user has been to (e.g. various UserControls that got delay-loaded by switching to various TabPages).
Data Validation runs when user leaves a Control or even while he/she is changing data in a Control.
** In case the Collection of validation errors of the Form (FPetraUtilsObject.VerificationResultCollection) contains errors or warnings, ''all'' validation messages are shown in a MessageBox to the user and the saving operation is cancelled. Exception: if there were only validation messages that are warnings and not errors, the saving is allowed to go ahead after the user chooses 'OK' in the MessageBox.


'''TODO'''
====Tab-level Validation (On Screens with Tabs)====
====Record Level Validation====
Data Validation needs to be done by the programmer (manually) when the user switches to another Tab. ** In case the Collection of validation errors of the Form (FPetraUtilsObject.VerificationResultCollection) contains errors or warnings ''for the UserControl that holds all the content of the TabPage'', ''all'' validation messages that pertain to that UserControl need to be shown in a MessageBox to the user and the Tab-switching operation is to be cancelled. Exception: if there were only validation messages that are warnings and not errors, the Tab-switching is allowed to go ahead after the user chooses 'OK' in the MessageBox.
Data Validation runs when user changes to a different record in a Grid.


'''TODO'''
====Form Level Validation====
Data Validation runs when user presses the 'Save' button or chooses Menu 'File' -> 'Save'.


'''TODO'''
===Data Validation Error Notifications to the User===
====Data Validation Error Notifications to the User====
====Intrusive Notifications====
=====Intrusive Notifications=====
These kind of notifications take the input focus away from the Controls in which the user is changing data. They should be used only when the user tries to save data in a form, or when trying to switch to a different TabPage, and data validation errors are present.
These kind of notifications take the input focus away from the Controls in which the user is changing data. We would prefer to replace those in most data entry situations with 'less intrusive notifications', as these won't take away the input focus.


======MessageBoxes======
=====MessageBoxes=====
* Display 1..n TVerificationResults in a meaningful manner in ''a single'' MessageBox (rather than in a series of MessageBoxes).
* Display 1..n TVerificationResults in a meaningful manner in ''a single'' MessageBox (rather than in a series of MessageBoxes).
** '''TODO''': look at existing implementation and see if it could be improved.
** In the future we would like to replace the use of MessageBoxes for that purpose with a standard dialog that would contains a Grid. 1..n TVerificationResults would be displayed in that Grid in a nicer way than is currently possible with pure text (e.g. showing an error or warning icon for each TVerificationResult line in the grid, providing hyperlinks to a help topic for certain TVerificationResults, ...).


=====Less Intrusive Notifications=====
====Less Intrusive Notifications====
These kind of notifications should not take the input focus away from the Controls in which the user is changing data! ''We don't have such notifications yet, but they would be very nice!!!''
These kind of notifications do not take the input focus away from the Controls in which the user is changing data.


====== Using and customising the .NET WinForms ErrorProvider======
=====ToolTips=====
* We don't have always space for a 'red explamation mark icon' to the right of a Control (this is the default thing the ErrorProvider does), so we might want to look into using a 'Bubble Help'-kind-of-notification.
* We use ToolTips to notify the user of Data Validation errors. One ToolTip at any given time is shown for a Control on the Form if the user leaves a Control that has associated data validation and that data validation fails.
** The ToolTip is shown next to the Control that failed its data validation.


======Bottom-Docked Panel in Which Error Messages Would be Displayed======
=====''Idea for the future:'' Bottom-Docked Panel in Which Error Messages Would be Displayed=====
* This Panel would only be shown when data verification errors would be raised and would be hidden again once the data verification error(s) is/are resolved.
* This Panel would only be shown when data verification errors would be raised and would be hidden again once the data verification error(s) is/are resolved.
* Individual data verification errors should be LinkLabels on which the user can click. Clicking those would set the input focus to the offending Control.
* Individual data verification errors could be LinkLabels on which the user can click. Clicking those would set the input focus to the offending Control.




===Help File Integration===
====WinForms Generator Support for Data Validation====
'''TODO'''
The WinForms Generator creates all the standard program code that is necessary to automatically and consistently deal with the handling of the TVerificationResults stored in a TVerifcationResultCollection on the client side (especially in the SaveChanges Method). It also makes the Controls that are to be validated and the translated Labels of those Controls accessible to the validation code. The latter is important as it allows the validation messages to contain the Text of the Labels of Controls as they appear to the user in their selected language.




===WinForms Generator===
==Server Side==
The WinForms Generator should create all the standard program code that is necessary to automatically and consistently deal with the handling of the TVerificationResults stored in a TVerifcationResultCollection on the client side (especially in the SaveChanges Method).
===Datastore 'SubmitChanges' Methods===
 
 
===Server Side===
====Datastore 'SubmitChanges' Methods====
At the moment our auto-generated '...SubmitChanges' Methods in the openPETRA Datastore return a TVerificationResultCollection, but that should be changed to Exceptions being thrown instead - see [[DB Discussions: Transaction Model, Savepoints, Locking; Exception Handling; Caching#SubmitChanges_Methods | DB Discussions]]!
At the moment our auto-generated '...SubmitChanges' Methods in the openPETRA Datastore return a TVerificationResultCollection, but that should be changed to Exceptions being thrown instead - see [[DB Discussions: Transaction Model, Savepoints, Locking; Exception Handling; Caching#SubmitChanges_Methods | DB Discussions]]!


==General==
====Use of Centralised Error Code System====
See [[Error and Exception Handling Policy#Central_Place_for_Maintenance_of_Unique_Error_Codes | Central Place for Maintenance of Unique Error Codes]].


===Use of Centralised Error Code System===
===Help File Integration===
See [[Error and Exception Handling Policy#Central_Place_for_Maintenance_of_Unique_Error_Codes | Central Place for Maintenance of Unique Error Codes]].
'''TODO'''

Revision as of 13:38, 4 April 2012

DOCUMENTATION IS WORK IN PROGRESS

This wiki page is currently being overhauled to reflect the implementation of the Data Validation Framework.

What the Data Validation Framework Provides

  • A common model in which data validation is done in OpenPetra.
    • Although the way how data validation is done differs on server and client side due to the different nature of these sides, there is still a common model (the Validation Framework) behind it.
  • It supports a variety of situations in the most effective manner.
  • It makes the raising of data validation errors and the handling of those as painless and easy for the software engineers as possible.
  • It ensures that data validation errors are brought to the attention of the users in a standardised way.
  • All data validation warning/error messages can be translated.
    • All data validation warnings/errors have a unique 'Error Code' that makes it possible to identify what warning/error the user is faced with. This is especially important for support staff as they will be able to identify the warning/error even if they aren't able to read the warning/error message (as it might be displayed in a language that they don't understand).

Client Side

Validation Scope

Field-level Validation

Data Validation runs when user leaves a Control that has associated data validation code.

  • Manual Code performs the validation of the data that the Control is bound to.
    • In case the data validation of a Control fails...
      • a ToolTip is displayed near that control. The ToolTip text explains what is wrong.
      • the validation error is added to a Collection of validation errors of the Form that hosts the Control (FPetraUtilsObject.VerificationResultCollection).

Record-level Validation

Data Validation runs when user changes to a different record in a Grid.

  • Manual Code performs the validation of the data of the record. All DataColumns may be checked for data validation errors.
    • In case the data validation of a record fails...
      • a MessageBox is displayed, potentially listing several validation errors of the one record. The text of the MessageBox explains what is wrong.
      • the user is prevented from navigating to another record in that Grid.
      • the validation error is added to a Collection of validation errors of the Form that hosts the Control (FPetraUtilsObject.VerificationResultCollection).

Form-level Validation

Data Validation runs when the user presses the 'Save' button or chooses Menu 'File' -> 'Save'.

  • Code in the 'SaveChanges' Method causes data validation to be run on all parts of the Form that the user has been to (e.g. various UserControls that got delay-loaded by switching to various TabPages).
    • In case the Collection of validation errors of the Form (FPetraUtilsObject.VerificationResultCollection) contains errors or warnings, all validation messages are shown in a MessageBox to the user and the saving operation is cancelled. Exception: if there were only validation messages that are warnings and not errors, the saving is allowed to go ahead after the user chooses 'OK' in the MessageBox.

Tab-level Validation (On Screens with Tabs)

Data Validation needs to be done by the programmer (manually) when the user switches to another Tab. ** In case the Collection of validation errors of the Form (FPetraUtilsObject.VerificationResultCollection) contains errors or warnings for the UserControl that holds all the content of the TabPage, all validation messages that pertain to that UserControl need to be shown in a MessageBox to the user and the Tab-switching operation is to be cancelled. Exception: if there were only validation messages that are warnings and not errors, the Tab-switching is allowed to go ahead after the user chooses 'OK' in the MessageBox.


Data Validation Error Notifications to the User

Intrusive Notifications

These kind of notifications take the input focus away from the Controls in which the user is changing data. They should be used only when the user tries to save data in a form, or when trying to switch to a different TabPage, and data validation errors are present.

MessageBoxes
  • Display 1..n TVerificationResults in a meaningful manner in a single MessageBox (rather than in a series of MessageBoxes).
    • In the future we would like to replace the use of MessageBoxes for that purpose with a standard dialog that would contains a Grid. 1..n TVerificationResults would be displayed in that Grid in a nicer way than is currently possible with pure text (e.g. showing an error or warning icon for each TVerificationResult line in the grid, providing hyperlinks to a help topic for certain TVerificationResults, ...).

Less Intrusive Notifications

These kind of notifications do not take the input focus away from the Controls in which the user is changing data.

ToolTips
  • We use ToolTips to notify the user of Data Validation errors. One ToolTip at any given time is shown for a Control on the Form if the user leaves a Control that has associated data validation and that data validation fails.
    • The ToolTip is shown next to the Control that failed its data validation.
Idea for the future: Bottom-Docked Panel in Which Error Messages Would be Displayed
  • This Panel would only be shown when data verification errors would be raised and would be hidden again once the data verification error(s) is/are resolved.
  • Individual data verification errors could be LinkLabels on which the user can click. Clicking those would set the input focus to the offending Control.


WinForms Generator Support for Data Validation

The WinForms Generator creates all the standard program code that is necessary to automatically and consistently deal with the handling of the TVerificationResults stored in a TVerifcationResultCollection on the client side (especially in the SaveChanges Method). It also makes the Controls that are to be validated and the translated Labels of those Controls accessible to the validation code. The latter is important as it allows the validation messages to contain the Text of the Labels of Controls as they appear to the user in their selected language.


Server Side

Datastore 'SubmitChanges' Methods

At the moment our auto-generated '...SubmitChanges' Methods in the openPETRA Datastore return a TVerificationResultCollection, but that should be changed to Exceptions being thrown instead - see DB Discussions!

General

Use of Centralised Error Code System

See Central Place for Maintenance of Unique Error Codes.

Help File Integration

TODO