On 02/12/2013 11:15 PM, Endi Sukma Dewata wrote:
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
You missed one option: nothing selected. It can be solved by adding '(
) Inherited' radio.
Anyway, this design seems more user friendly for more general audience
than mine so I will implement it. The only problem with it is that one
have to come with new label for each group and empty value - can't be
inferred from metadata.
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',
Not sure if it should be radio, more like something new.
label: ...,
options: [
{
label: ...,
value: 'NONE'
},
{
label: ...,
type: 'checkboxes',
Do you expect to be there something different than checkboxes, or do you
want it to do it this way for possible future customization.
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']
}
]
}
+1 for classic checkboxes or radios. Problem with this example is that,
it is missing label for the checkbox group which can't be inferred from
anything.
--
Petr Vobornik
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
