High Level Design Options
Option 1 - Visitor Pattern
After dictionary has been loaded we invoke top level beans to validate (by calling a validate method), they then make calls to validate their children.
- can leverage similar tool for KNS
- Spring will provide some level of validation just by trying to create the beans.
- Easy for new widgets and those developed outside of KRAD to conform to tool
- Approach makes it easier to keep validation rules current.
- Specific Error reporting is difficult
- Validation done at run time (not development time)
Option 2 - Standalone Validator - Validate Objects
Validation is written outside of the bean classes (components) and invoked after dictionary is loaded or standalone. The validator validates against the objects created by Spring.
- has many of cons of both option 1 and option 2 combined
Option 3 - Standalone Validator - Validate Source
Validation is written outside of the bean classes (components) but validates against the XML source.
- Better Error Reporting: can show filename, line, column or property name
- Validation done during development of bean
- Could possibly be leveraged to use in a IDE plugin, or future visual development tool
- Probably much larger development time
- More development unknowns
- more difficult to keep current with code
- harder for outside implementors
Technical Issues / Details
- Where to hold and how to represent validation rules?
- In Java class for bean
- In bean XML Def
- In tool