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