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