Overview of the Data Validation Framework

From OpenPetra Wiki
Revision as of 10:53, 15 March 2011 by Christiankatict (talk | contribs) (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…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Motivation

  • Currently there are different ways of handling data verification errors.
  • 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!


Goals

  • There needs to be one single way in which data validation is done in openPETRA - the Validation Framework.
    • 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.
    • The Validation Framework should support a variety of situations in the most effective manner.
    • 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.
    • The Validation Framework should ensure that data verification errors are brought to the attention of the users in a standardised way.
  • Documentation should be placed in the wiki that guides the software engineers on how to do data validation correctly and in an unified way.


Considerations

Client Side

Field Level Validation

Data Validation runs when user leaves a Control or even while he/she is changing data in a Control.

TODO

Record Level Validation

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

Intrusive Notifications

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
  • 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.
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!!!

Using and customising the .NET WinForms ErrorProvider
  • 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.
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 should be LinkLabels on which the user can click. Clicking those would set the input focus to the offending Control.


Help File Integration

TODO


WinForms Generator

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).


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!


Use of Centralised Error Code System

See Central Place for Maintenance of Unique Error Codes.