Recommendations when writing a grammar

eTo avoid common mistakes when writing a grammar to interpret a configuration file, use the following recommendations:

• Values and keys must include delimiters. For example, if you are parsing /etc/group with the format A:B:Con each line, any token representing A, B, or C must not include a colon. The following are examples:

  [^:]*
  
  [^:]+
  

  Following delimiters are supported for custom configuration files:

  • Comma (,)

  • Space

  • Equal (=)

  • Colon (:)

• If rule A references rule B, rule B must be defined before rule A. For example, the following syntax is incorrect:

  RULE_B KEY COLON VAL %RULE_A
  RULE_A VAL %RULE_A
  

  In this example, RULE_B is using RULE_A, but RULE_A is not yet defined. If the two lines were inverted, this example would be correct.
  
  A rule can always reference itself.

• You cannot save a child record to a parent that does not yet exist. If you are attempting to create a hierarchy from one line in a configuration file, you must save the parent record before you can save any child records.

• Do not reference an item in a rule that does not exist. Doing so can cause serious problems. For example, the following rule references the fourth argument in the rule by calling $3, but the rule only has three arguments. This is incorrect.

  RULE_A VALA VALB VALC $new_field $3
  

• For changes to a grammar file to take effect, you must:
  • Restart the Application Server
  • Recreate any BLPackages that reference this grammar
  • In multi-Application Server environments, load the revised grammar file to the file server