System ParametersUnofficial Content

Almost all applications have some kind of configuration values or parameters. Some examples are:

  • Default Currency (in multicurrency application)
  • GXchart server URL
  • Customer Name and Image (in case of a software package)

The intention of a system parameter is to improve the application customization in the sense that it can be adapted to new customers (or new functionality in the same customer) without the need to change the system's code.

A system parameter differentiates from a system constant due a system parameter can be changed at run-time and a system constant can only be changed modifying the code itself. It's a good practice to set the default value of a system parameter with a system constant, in order to assure the system parameter always have a meaningful value (for example the default value of GXchart server URL be setted to '').

In traditional applications these parameters are stored in config or XML files, but this isn't a good solution due have same problems:

  • text files are more fragile than a DBMS.
  • no referential integrity between some parameters and the data base. Ex: in gxwiki itself one of the parameter is who's the Anonymous User (which is a user).
  • no type checking

So a better solution is to store the Parameters in the DBMS itself but there are at least two ways to do it:

Solution I: One Record Transactions#

In this case a One Record Transaction is used for each set of parameters, where each parameter corresponds to an attribute in the Transaction. 


In gxwiki the parameter transaction is:

gxwiki parameters structure

gxwiki parameters rules

gxwiki parameters udp

  • Referential integrity
  • Type checking
  • Cross Reference (What objects use this parameter?)
  • To create a new parameter a reorg is needed. (Anyway this is not very painful in GeneXus).

Solution II: OAV Pattern#

In this case a OAV Pattern is used to store the parameters. The only change needed is the O (object) isn't necessary, it's just a Attribute/Value pairs.

  • No reorg needed
  • Programs can detect the parameter absence (in Solution I, the program cancel).
  • No type checking or referential integrity