List parameter type

[FRosner]

Problem

Sometimes you want to predefine which values a user can select for a parameter.

Solution

Introduce a list parameter type which holds predefined values the user can select. The front-end should then render a drop down / option select box. Any value that is not in the list will not be accepted from the back-end.

[sohaibiftikhar]

Possible design:
Currently, we have the following structure for describing a parameter.

"secret" = {
     default = <somevalue|dataType depends on type>
     name = <somename|string>
     type = <sometype|string>
     secret = <issecret|boolean>
}

The problem can be seen as that between native types (int, string etc.) and complex types (list, set etc.). For complex types such as lists, we can make the key type to be complex (we can still support legacy simple strings). This can have a structure like:

type = {
    name = <somecomplextype|string>
    # metadata can be specific to each complex type. This example is for lists.
    # metadata can be optional or mandatory based on the type. For example we don't
    # need it for native types.
    metadata = {
        # I was thinking of keeping types to a single level for now. 
        # Do we also need to support list of lists? 
        # I think we can do that as well (recursively). Writing adaptors (see below) might get harder.
        type = <somenativetype|string>
        adaptor = {
            # dynamic adaptors can specify the name of a class 
            type = <dynamic or static|string>
            # we can implement different adaptors like LDAPListAdaptor and StaticListAdaptor
            # that parse the values based on this. For the frontend the values will always be static.
            provider = <fqdn of class|String> or <list of values|List[type]>
            config = { # can be optional
                // some config that the class may need
            }
        }
    }
}

Does this look too complex? Suggestions?

[FRosner]

I like it. I would prefer however, to just have a provider and not a type. Then we can have LDAP providers, static providers, etc.

Here's how we could define a drop down single element selection list:

"secret" = {
  default = 10
  name = numbers
  type = {
    class = set
    innerType = integer
  }
  provider = {
    class = StaticSetProvider
    config = {
      values = [1,10,100]
    }
  secret = false
}

I still don't like that type can be either a string or an object and I also don't like the name class for the type of the type.