Unset - Configuration Editor

Stefan Negrea snegrea at redhat.com
Tue Sep 11 15:39:41 UTC 2012


Just to clarify my previous email...

----- Original Message -----
> From: "Stefan Negrea" <snegrea at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Tuesday, September 11, 2012 10:37:49 AM
> Subject: Re: Unset - Configuration Editor
> 
> 
> 
> ----- Original Message -----
> > From: "Jiri Kremser" <jkremser at redhat.com>
> > To: rhq-devel at 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 your BZ separately.

> 
> 
> Thank you,
> Stefan Negrea
> 
> 
> > 
> > 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
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> _______________________________________________
> 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