From: "Jiri Kremser" <jkremser(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Tuesday, September 11, 2012 10:52:22 AM
Subject: Re: Unset - Configuration Editor
It wasn't disabled. I've added the screenshot (1.5MB png grr) to the
bug (
https://bugzilla.redhat.com/attachment.cgi?id=611837)
JK
Ohh now I see ... That is a completely different issue and I would say to fix the plugin
itself. The UI code worked well and will continue to work the same way after my update.
For BZ 847301, the field has a default value in the descriptor. The UI will load the
default value. The field is required and the default value is loaded, so it will pass
validation since a value is in the field at save time. Now, that default value is
blatantly wrong for obvious reasons. My updates do not address this complicated case, I
only fixed functionality around unset checkbox.
Thank you,
Stefan
----- Original Message -----
From: "Stefan Negrea" <snegrea(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Tuesday, September 11, 2012 5:37:49 PM
Subject: Re: Unset - Configuration Editor
----- Original Message -----
> 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
>
_______________________________________________
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