Radio option has Selected/Not Selected

[natestone]

Why is this necessary? If a selection is no longer "selected", it just needs to be deleted. There is no value in having "un-selected" selections in my opinion.

Perhaps, I'm forgetting a reason for this. If so, please elaborate.

I am changing the code to allow "unselected" options - meaning the user has said that this option is specifically unselected.

However, we have no way to indicate this state on the edit interface. How does the user differentiate between not selected and specifically unselected on the UI? Needs a 4 state selection (disabled, checked, not-selected, un-selected).

Please discuss and we'll create a task/enhancement from here.

[ajpires]

...not 100% certain what you're referring to here. If you're asking why the database table odr_radio_selection still has "unselected" options in it...if I'm remembering correctly from years ago, I didn't want to completely delete them from the table when the user could later select that option again, and also didn't see the point of soft-deleting them.

It made sense to me at the time, but we really need to make a concrete plan for how to deal with soft-deletion and the ability to view a Datarecord at any point in time...from my understanding, the database isn't really correctly set up for either of those two things right now, so the sooner that gets dealt with the better...

I am changing the code to allow "unselected" options - meaning the user has said that this option is specifically unselected.

I'm also not certain what you mean by that. I'm having difficulty thinking of a situation where you would need to store a difference between "not selected" and "specifically unselected" in a dropdown/checkbox-type situation, and even more trouble trying to think of a use for the 4-state construct you described...or more specifically, I can't think of a situation where a 2-state construct is insufficient, and a 3 or 4-state construct is necessary.

[natestone]

The database is 100% set up for soft deleting - has been from day one. We
are just using it incorrectly. My only doubt might be to do with
migrations of data from one type to another. However, if they were
soft-deleted, the old version would still exist.

My entire intention was to use the database this way from the day of
creation. It's possible we have some flaws in it, but I'm sure it will
work for almost everything.

4 States:

1 - disabled (ie: state is locked, whatever data is there can not be
changed - frozen)
2 - checked
3 - not checked
4 - not checked intentionally

For instance, my machine has the following options:

aux power yes/no

some other gizmo yes/no

Leaving them "unchecked" or "no" is a valid state and is different from not
having entered a value. I'm not sure that's a great example, but it's
along the lines of what I'm thinking.

--Nate

On Thu, Mar 17, 2016 at 10:41 AM Alex Pires [email protected]
wrote:

...not 100% certain what you're referring to here. If you're asking why
the database table odr_radio_selection still has "unselected" options
in it...if I'm remembering correctly from years ago, I didn't want to
completely delete them from the table when the user could later select that
option again, and also didn't see the point of soft-deleting them.

It made sense to me at the time, but we really need to make a concrete
plan for how to deal with soft-deletion and the ability to view a
Datarecord at any point in time...from my understanding, the database isn't
really correctly set up for either of those two things right now, so the
sooner that gets dealt with the better...

I am changing the code to allow "unselected" options - meaning the user
has said that this option is specifically unselected.

I'm also not certain what you mean by that. I'm having difficulty thinking
of a situation where you would need to store a difference between "not
selected" and "specifically unselected" in a dropdown/checkbox-type
situation, and even more trouble trying to think of a use for the 4-state
construct you described...or more specifically, I can't think of a
situation where a 2-state construct is insufficient, and a 3 or 4-state
construct is necessary.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#176 (comment)