naparuba/shinken — pull request #984 by geektophe (2013-08-23 18:49:48+00:00)
Title: Added multi valued attributes support

This patch adds support for multi valued attributes by defining several times the same attribute name, rather than using `,` character as delimiter.

It allows to write clearer configuration, but its main purpose is to let the user write attribute values containing arbitrary strings: values are represented by the different instances of the same attribute name, and are not splitted afterward (they may contain the split delimiter, spaces, or any other character).

**Limitations**
- This only applies to attributes with properties using the `ListProp` class. For any other property type, the default behavior remains the same: the lastly defined value set wins.
- As mentioned above, multi valued and single line valued using `,` delimiter syntaxes are mutually exclusive. Once a second attribute instance is added, we are considered in mult value mode, and no split on `,` is done.
- We have to be able to tell which type the attribute is to decide if it may be multi valued. This excludes custom attributes (which name start with `_`). A multi valued custom attribute will raise an error.
- As there is no way to decide how to handle `+` values in multi value mode, values with leading `+` are forbidden, and will raise en error.

**Examples**

define service{
use generic-service
...
notification_options w
notification_options u
notification_options c
notification_options r
notification_options f
notification_options s
...
}

Is exactly equivalent to

define service{
use generic-service
...
notification_options w,u,c,r,f,s
...
}

But

define service{
use generic-service
...
notification_options w,u,c
notification_options r,f,s
...
}

Is not.

The `notification_options` attribute will contain two values, respectively `w,u,c` and `r,f,s`.