Unset - Configuration Editor

Stefan Negrea snegrea at redhat.com
Tue Sep 11 19:31:58 UTC 2012



----- Original Message -----
> From: "Charles Crouch" <ccrouch at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Cc: "Malini Rao" <mrao at redhat.com>, "Harlan Douglas" <hdouglas at redhat.com>
> Sent: Tuesday, September 11, 2012 12:32:01 PM
> Subject: Re: Unset - Configuration Editor
> 
> 
> 
> ----- Original Message -----
> > The unset also has a valid use-case when there is no default value.
> > For
> > example, some properties that are set for a plug-in can either be
> > empty
> > strings or simply undefined. If undefined, the default value is
> > used
> > in
> > the managed resource. If defined (even if empty string) the value
> > gets
> > set in the managed resource to an empty string. For example, the
> > as5
> > plug-in provides a configuration property
> > check-valid-connection-sql
> > which by default is unset. In this case, unset means that this
> > datasource XML element will not appear in the datasource
> > definition.
> > However, if you were to set unset to false and leave the value
> > blank,
> > the value becomes defined in the datasource's definition as an
> > empty
> > string which is needed for some datasources.
> > 
> 
> The above was the exact use case which originally prompted the
> creation of "unset", except I think it was the password field on the
> AS4 datasource, i.e. for a datasource there was a difference between
> sending an empty string for the password and not sending any
> password at all.

This is getting very interesting .... I do not think the editor works like this anymore. An empty text field is null by default; there is no concept of empty today. 

This commit from 10/2011 actually checks the unset box if the value is null. From my testing it is triggered every time I empty a text field. This change was introduced prior to RHQ 4.3 so it has been there for at least two releases. The question now becomes, is that correct behaviour?
http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/modules/enterprise/gui/coregui/src/main/java/org/rhq/enterprise/gui/coregui/client/components/configuration/ConfigurationEditor.java?id=9181a2efb6f1888e4531a19017ec7420831b3331


My work is completely separate from this as it only corrects the behaviour of the unset check box itself.


> 
> My question now is:
> 1) Is there a better way to handle the above use case than the unset
> column?

The only place where I see the unset option to make a lot of sense is for fields with options. Today (see above) text fields empty or unset are identical; and lists and maps do not get the unset checkbox at all.


> 2) How common are properties which differentiate between null and
> empty string? Perhaps we could have a special widget type for them,
> rather than adding "unset" as an option for all properties?
> 
> > So, not only do we need the notion of `Default` but we also need
> > `Null`.
> > 
> > On Tue, 2012-09-11 at 12:47 -0400, John Sanda wrote:
> > > I agree and understand that we need a way to reset a value back
> > > to
> > > its default. I think we should explore whether or not there is a
> > > better way, especially if there is a general consensus that the
> > > unset checkbox is confusing.
> > > 
> > > On Sep 11, 2012, at 12:18 PM, John Mazzitelli <mazz at redhat.com>
> > > wrote:
> > > 
> > > >> I have a question. Do we need the unset column at all?
> > > > 
> > > > The unset checkbox has always been a problem since it can be
> > > > confusing what it means.
> > > > 
> > > > However, we need a way to support being able to unset a value
> > > > so
> > > > it falls back to its default value (which most times is not an
> > > > empty value). This unset checkbox was the way we implemented
> > > > that requirement.
> > > > 
> > > > For example, how do you distinguish a property value that is
> > > > set,
> > > > but is an empty string versus a value that is not set and whose
> > > > value therefore becomes a non-empty default value (an internal
> > > > default value that the code would use if the property is not
> > > > set)?
> > > 
> > > Not sure I understand. The editor renders a text field with a
> > > non-empty default value. I edit the field, changing it to an
> > > empty
> > > string. So is the problem knowing/remembering that I have
> > > actually
> > > edited that text field?
> > > > 
> > > > This is the problem the unset checkbox attempted to solve.
> > 
> > 
> > _______________________________________________
> > 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