Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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.

titleRole of parameters for validation

There are various data validation mechanisms in Rice/KFS:

  • Data dictionary-based validation
  • Document/business rules
  • Parameters

Data dictionary-based (see DictionaryValidationService) validation uses attribute metadata specified in the data dictionary file to perform elementary validations of a business object/document prior to persistence. For example, it is able to determine which attributes are required and whether they conform to a necessary format (e.g. all numbers), and to display error messages if they do not conform.

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

KFS Parameter Service


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.
Parameter Evaluators