On 2/12/2013 10:56 AM, Petr Vobornik wrote:
We were discussing to NACK this approach.

The implementation should be improved because of the mutually exclusive
nature of NONE option with [MS-PAC, PAD] options.

I think we should add spec definition (to Web UI only, or into server
plugin as well) of mutex options. Something like:

     mutex_groups: [[['NONE'],['MS-PAC', 'PAD']], [/*another array of
groups*/]];

basically an array of group arrays where group array would contain
arrays of mutually exclusive option. Is it over-complicated? Would one
array or a pair of groups be enough?

That way we can disable and uncheck(should not happen, but to keep data
consistency) checkboxes of options from other groups when user selects a
value of some group.

If they are mutually exclusive, they probably should be separated using radio buttons like this:

  PAC: ( ) None
       (o) Type:
           [x] MS-PAC
           [ ] PAD

It might be better to use a composite widget of radio buttons and checkboxes so we can reuse the code. Probably the definition will look something like this:

{
    name: 'ipakrbauthzdata',
    type: 'radio',
    label: ...,
    options: [
        {
            label: ...,
            value: 'NONE'
        },
        {
            label: ...,
            type: 'checkboxes',
            options: [
                {
                    label: ...,
                    value: 'MS-PAC'
                },
                {
                    label: ...,
                    value: 'PAD'
                }
            ]
        }
    ]
}

The composite widget will handle setting the appropriate widgets when the value of the field on load. It will handle enabling/disabling the checkboxes when the radio button is selected. It will also compute the final value of the field from selected radio button/checkboxes on save.

Or just dim (no disable) and uncheck. That way there would still be
visual distinction and one don't have to uncheck all the options from
one group when he wants to select options of mutex group.

That is also possible, but it changes the normal behavior of checkboxes, so probably users would have to play around with it to understand the grouping. They could also get confused, e.g. is dimmed checkbox disabled?

As a separate issue, we might want to fetch the options from metadata,
when we want to show the values and don't care about creating different
labels.

If we use radio buttons like above, new labels are necessary to describe the different groups of checkboxes. For all radio buttons & checkboxes in general, if we don't want to use labels we probably could simplify the definition such that we can specify the string values directly (without nested object):

{
    name: 'ipakrbauthzdata',
    type: 'radio',
    options: [
        'NONE',
        {
            type: 'checkboxes',
            options: ['MS-PAC', 'PAD']
        }
    ]
}

--
Endi S. Dewata

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to