In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

View Revisions: Issue #271		[ All Revisions ] [ Back to Issue ]
Summary	0000271: Redesign "Data Validation" Engine

Revision	2009-09-04 17:13:48 by Dmitry
Description	Here is form data processing cycle from user to database: 1. user opens editing template and inputs form data into form fields; 2. user presses save button to place it's changes to database; 3. form data is passed to kDBItem (or it's descendant) class for processing; 4. class kDBItem (or it's descendant) uses kDBItem::Validate method to validate data before saving to database; 5. internally validation is performed using options defined for each field in it's declaration (all fields are validated, no matter what fields were submitted from form); 6. based on validation results user is either returned to form with validation errors displayed or editing window is successfully closed. This approach has several not obvious weaknesses: 1. all fields are validated, instead of submitted only fields - this takes time, when not all possible fields are displayed on form; 2. validation rules are defined directly in field declaration in unit config - this doesn't allow form-based validation rules on base level (but can be done inside event handler as usual). Idea is to move all validation-related field options to form declaration (see task 0000270) and submit used form name along with form fields to kDBItem class, that will use it to perform form-based validation. How to do this: 1. create kValidator class (with one public method named ValidateField) and move all validation-related code to it from kDBItem class; 2. add $form_name parameter to kDBItem::Validate and to kDBItem::ValidateField methods; 3. when $form_name parameter is not passed, then create (and cache) instance of kValidator class and use validation-related options from field declaration in unit config; 4. when $form_name parameter is passed, then create (and cache) instance of validator class, specified in form declaration and use validation-related options for given field from form declaration; 5. validate form fields using appropriate validator class and validation-related options. 4. create ValidatorClass unit config option (like ListClass option), that will allow to define custom validator class for given unit config and use it later in forms declared inside that unit config. This way compatibility with unit configs, that don't use forms, layouts will be preserved. Also side effect is, that less memory will be used, when data from several tables in displayed on same screen (front-end mostly).

Revision	2009-09-04 15:28:45 by Dmitry
Description	Here is form data processing cycle from user to database: 1. user opens editing template and inputs form data into form fields; 2. user presses save button to place it's changes to database; 3. form data is passed to kDBItem (or it's descendant) class for processing; 4. class kDBItem (or it's descendant) uses kDBItem::Validate method to validate data before saving to database; 5. internally validation is performed using options defined for each field in it's declaration (all fields are validated, no matter what fields were submitted from form); 6. based on validation results user is either returned to form with validation errors displayed or editing window is successfully closed. This approach has several not obvious weaknesses: 1. all fields are validated, instead of submitted only fields - this takes time, when not all possible fields are displayed on form; 2. validation rules are defined directly in field declaration in unit config - this doesn't allow form-based validation rules on base level (but can be done inside event handler as usual). Idea is to move all validation-related field options to form declaration (see task 0000270) and submit used form name along with form fields to kDBItem class, that will use it to perform form-based validation. How to do this: 1. create kValidator class (with one public method named ValidateField) and move all validation-related code to it from kDBItem class; 2. add $form_name parameter to kDBItem::Validate and to kDBItem::ValidateField methods; 3. when $form_name parameter is not passed, then create (and cache) instance of kValidator class and use validation-related options from field declaration in unit config; 4. when $form_name parameter is passed, then create (and cache) instance of validator class, specified in form declaration and use validation-related options for given field from form declaration; 5. validate form fields using appropriate validator class and validation-related options. 4. create ValidatorClass unit config option (like ListClass option), that will allow to define custom validator class for given unit config and use it later in forms declared inside that unit config. This way compatibility with unit configs, that don't use forms, layouts will be preserved. Also side effect is, that less memory will be used, when data from several tables in displayed on same screen (front-end mostly).

Web Development by Intechnic

In-Portal Open Source CMS