From: "Jiri Kremser" <jkremser(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Tuesday, September 11, 2012 10:27:26 AM
Subject: Re: Unset - Configuration Editor
Hi Stefan,
Isn't it the duplicate of
https://bugzilla.redhat.com/show_bug.cgi?id=847301 ?
Might be ... in your case, was the text box pre-filled with the default value but the
field itself was disabled? If not, then we will probably need to hunt that case too.
Thank you,
Stefan Negrea
JK
----- Original Message -----
From: "Stefan Negrea" <snegrea(a)redhat.com>
To: "rhq-devel" <rhq-devel(a)lists.fedorahosted.org>
Sent: Tuesday, September 11, 2012 2:58:36 PM
Subject: Unset - Configuration Editor
Hello Everybody,
Yesterday I applied a fix to the configuration editor that on the
surface looks harmless but changes across the board the way default
values are applied to fields on unset updates.
The original behaviour was very confusing and unintuitive. Here is
the behaviour and what was confusing to me:
1) On initial configuration editor load
a) if a field was unset, then the default value was loaded the form
field but the actual field was disabled.
The problem: the field was disabled and unset checked, however there
is a value in thr form field that cannot edited or cleared. This can
give the wrong impression that unset fields automatically get the
default value when saved. If a user really gets confused about that
value being there but greyed out then there is no way for a user
clear that value without changing the value of unset twice, see 3)
and 4) below.
2) When the user changes the unset state from true to false for the
first time:
a) the form field was enabled for editing
b) since the default value was already there from the initial load,
that default value would still be selected
c) the form could not be saved because the changed event was not
fired by the code
The problem: the default value is there (and selected for properties
with options) but the user will need to update the field before the
configuration can be saved. As an example, for fields with options,
the user will have to select another value and then reselect the
default value before they can save the configuration with the
default value for property with options. This is all because
internally the code does not fire the event that the form changed.
3) When the user changed the unset state from false to true:
a) the value of the field was cleared
b) the field was disabled
No problem! This is the only case where the behaviour is intuitive.
4) When the user changed the unset state from true to false for
third, fourth, fifth, ... time on the same field:
a) the form field was enabled for editing
b) the form field would be empty or no value selected for fields
with options, since the value was cleared in 3)
c) the user would need to read the field description and type or
select the default value, if the default value is even mentioned
in the field description.
The problem: This contradicts 2) where the default value was in the
field. So, the user will see the default value for the first time
but not for subsequent times. If the default value is set for the
field but not in the description, the user will have absolutely no
way to find that out after the initial unset change since the
default value is not displayed in the UI.
To fix this, I changed the way default values are applied to
properties to give a natural user experience. As you can see even
explaining this new behaviour is more concise. Here is how this
works after the update:
1) On load, if the field is unset then disable field and set value to
null.
2) On load, if the field is set then enable field and load saved
value.
3) On unset change from true to false, enable field and load default
value if not null. Enable save button.
4) On unset change from false to true, disable field and set value to
null. Enable save button.
All this work was triggered by BZ 851186 which was reported against
the AS7 plugin. However this problem was applicable to every single
screen with a configuration editor. As you can see from the bug
description, the original behaviour was very confusing even to the
reporter. Here is the BZ for reference:
https://bugzilla.redhat.com/show_bug.cgi?id=851186
Any thoughts? Is the new behaviour intuitive enough?
Thank you,
Stefan Negrea
Software Engineer
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel