----- 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.
My question now is:
1) Is there a better way to handle the above use case than the unset column?
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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel