Agree with Harlan. It seems like a short phone meeting will be helpful. Let us know if you
want us to set it up or feel free to set it up. OUr calendars are up to date.
----- Original Message -----
From: "Harlan Douglas" <hdouglas(a)redhat.com>
To: "Stefan Negrea" <snegrea(a)redhat.com>
Cc: "Malini Rao" <mrao(a)redhat.com>, rhq-devel(a)lists.fedorahosted.org
Sent: Tuesday, September 11, 2012 4:06:19 PM
Subject: Re: Unset - Configuration Editor
Hi Everyone,
It seems that this issue has evolved since the first correspondence. I have been busy most
of the day but want to make sure this gets addressed. Lets sync up after tomorrows 9:30
scrum call do dive into this in more detail.
If this time doesn't work please propose a new one as I am not sure who needs to be
apart of this conversation.
-Harlan
----- Original Message -----
From: "Stefan Negrea" <snegrea(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Cc: "Malini Rao" <mrao(a)redhat.com>, "Harlan Douglas"
<hdouglas(a)redhat.com>
Sent: Tuesday, September 11, 2012 3:31:58 PM
Subject: Re: Unset - Configuration Editor
----- Original Message -----
From: "Charles Crouch" <ccrouch(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Cc: "Malini Rao" <mrao(a)redhat.com>, "Harlan Douglas"
<hdouglas(a)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/gu...
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(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
>
>
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel