Difference between revisions of "ESAPI Validation"

From OWASP
Jump to: navigation, search
(Possible Enhancements)
 
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.
  
* Follow service pattern to make it more extensible
+
* 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
 
+
* Chain validators together to allow more complex rules
+
 
+
*
+

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