Difference between revisions of "ESAPI Validation"

From OWASP
Jump to: navigation, search
(New page: == Possible Enhancements == * Make more utility methods that have less parameters * ...)
 
(Possible Enhancements)
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
 
== Possible Enhancements ==
 
== Possible Enhancements ==
  
* Make more utility methods that have less parameters
+
* Reduce the number of required parameters to validation methods by creating new methods signatures that use default parameters.
  
* ...
+
* Change the Validation methods to Validation classes that can be applied in a [http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern]. This means that rather than having specific methods such as validateCreditCard and validateEmailAddress there would be a Validator interface which would be implemented by classes like CreditCardValidator and EmailAddressValidator. This is analogous to the Encoding classes in ESAPI. This offers the benefit that new Validation classes can be created and current Validation classes can be modified without changing the interface. Additionally, Validators can be stacked to provide multiple forms of validation

Latest revision as of 09:32, 11 December 2008

Possible Enhancements

  • Reduce the number of required parameters to validation methods by creating new methods signatures that use default parameters.
  • Change the Validation methods to Validation classes that can be applied in a Strategy Pattern. This means that rather than having specific methods such as validateCreditCard and validateEmailAddress there would be a Validator interface which would be implemented by classes like CreditCardValidator and EmailAddressValidator. This is analogous to the Encoding classes in ESAPI. This offers the benefit that new Validation classes can be created and current Validation classes can be modified without changing the interface. Additionally, Validators can be stacked to provide multiple forms of validation