Unset - Configuration Editor

Jiri Kremser jkremser at redhat.com
Tue Sep 11 15:27:26 UTC 2012


Hi Stefan, 
  Isn't it the duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=847301 ?

JK

----- Original Message -----
From: "Stefan Negrea" <snegrea at redhat.com>
To: "rhq-devel" <rhq-devel at 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 at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list