Skip to end of metadata
Go to start of metadata

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.

Pros:

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

Cons:

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

Pros:

Cons:

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

Pros:

  • 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

Cons:

  • 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 

Tooling Configuration

  • No labels