- Parameter Classes
- Parameter Data Model
- KFS Parameter Conventions
- KFS Parameter Service
- KFS Parameter Namespace and Component Resolution
- KFS Parameter Naming Conventions
KFS provides an abstraction layer over Rice's parameter system to make it easier to use. This page will describe KFS's parameter system and parameter naming conventions within KFS.
How a parameter is used depends on the code is implemented, which will be discussed below.
There are various data validation mechanisms in Rice/KFS:
Data dictionary-based (see
Document/business rules are full-fledged java classes that allow for very flexible validation rule logic. Rules have access to all Spring services, giving them a wide range of computational power. In fact, document/business rules use parameters to perform some of its validation.
Parameters are ideal when functional specifications require that a value be in a list of allowed values (or not on a list of denied values). That is, parameters work extremely well for straightforward matching. However, institutions may desire to do the matching logic, but use a different list of values. Parameter-based validation allows them to change the list of values without revising code.
Parameters in a compound parameter have the same namespace and detail type and have very similar names (see naming conventions).
How a class is resolved into a namespace and detail type will be discussed below. For the purposes of discussion about how to use the parameter service, it is sufficient to understand that a class object is mapped to a namespace and detail type in a one-to-one mapping.
- componentClass: the class that maps to a namespace and detail type
- parameterName: the name of the parameter
- constrainedValue: the value to validate (e.g. a value coming from a form).
- allowParameterName: the name of the allow parameter in a compound parameter.
- denyParameterName: the name of the deny parameter in a compound parameter.