Item11928: default values in radio and select formfields are a bad idea

Since foswiki 1.1.5 we have a new behavior for select and radio formfields as part of Item11666 and distro:b7c67e39a42a

This change introduced default values for these list formfields returning the first value in the field definition as per values column in the DataForm.

That's actually a bad idea. Consider a form like

Name	Type	Values	Description	Attributes
Invoiced	radio	yes, no		M

Now creating a new Invoice topic on this base will flag the thing as being invoiced already because the first value is yes and the edit screen will happily select it by default. That's probably not what you want by default. It even won't force the user to review this value.

The pre 1.1.5 behavior was better, because it did not return any default value at all. So there was no value set automatically.

I'd like to vote to revert the related changeset as well as the unit tests and fix the docu accordingly.

Opinions?

-- MichaelDaum - 06 Jun 2012

Would it make sense to add an "Attribute" for the field, that indicates whether or not a default should apply, default not-set would be the pre-1.1.5 behavior of no default? H - Hidden, M - Mandatory, D - Apply default?

-- GeorgeClark - 07 Jun 2012

It would have been better to define what the default value actually is and not be forced to make it the first value of some list. But that needs a feature proposal of its own.

-- MichaelDaum - 07 Jun 2012

We fixed it back to what it originally was in twiki, matching the docco. Not sure when it was broken, but I suspect it was in twiki 4-ish.

• I am in favour of an explicit default feature request.
• I am not in favour of reverting the bugfix changeset.
• I am not in favour of an obscure attribute.

-- CrawfordCurrie - 07 Jun 2012

The documentation is pretty clear that the first value will be assigned as the default.

The field value will be used to initialize a field when a form is created, unless specific values are given by the topic template or query parameters. The first item in the list for a select or radio type is the default item.

In the provided example, what's the problem with changing the order to "No, Yes" which leaves the default as No. That seems to provide a simple solution without needing code changes and feature proposals.

If the field needs to be un-set so that an explicit choice is required, the following also works (Although it is a bit confusing with an unlabeled radio button selected, the save is rejected and the user is required to choose a different value.) Would it be possible to just not render the unassigned button?

Name	Type	Size	Values	Description	Attributes
Invoiced	radio	5	, yes, no		M

---

Whoops... distro:b7c67e39a42a changed the documentation. So my statement above is incorrect. No, it did not. The documentation has stated that since the initial import. However the solution still appears valid to me.

Referring back to the TWiki documentation, it also states: "The first item in the list for a select or radio type is the default item."

We should add a note to the Foswiki 1.1.5 release guide warning of this change however. It certainly is surprising for existing applications that depended upon the broken implementation.

-- GeorgeClark - 07 Jun 2012

The Download.FoswikiRelease01x01x05 page has been updated with a description of the changed behavior, and recommendation that existing forms be reviewed for appropriate defaults prior to upgrade.

-- GeorgeClark - 07 Jun 2012

But I want the interface to display the choice in the order "yes, no" not the other way around. Similarly "on, off" is the right order of a choice like this. Putting them the other way around is odd. Adding a third radio box for the empty value isn't an option either as the thing needs to be either "yes" or "no" ("on" or "off"). That's an application need.

Sometimes a value in the middle is the logical default value like in "tomorrow, today, yesterday" defaulting to "today" ... or any other range spanning around a center default.

Baseline is: using the first value in the list as a default value isn't cutting it. It is a severe shortcut. FORCING a default value to be the first makes it EVEN WORSE. That's what this bug report is about.

Some docu frankly doesn't justify this oddness.

-- MichaelDaum - 07 Jun 2012

I agree with Michael that this need fixing and docu isn't enough. Alas a fix requires a design change and therefore a feature request.

I get the impression that a number of us see a need for an all new SuperDataForm to address various shortcomings and provide a better platform for the future. However, that will be need quite some brainstorming and not happen for some time.

We need a reasonably simple way to extend the existing radio fields. My first thought is +default and then & as the first character of the value to indicate that's the default.

In Michael's example:

Name	Type	Values	Description	Attributes
Invoiced	radio+default	yes, &no		M

In the hope to prevent an impasse I quickly put this together: AddDefaultsToFields

-- JulianLevens - 08 Jun 2012

AddDefaultsToFields accepted - waiting for MichaelDaum.

-- SvenDowideit - 26 Sep 2012 - 05:39

Does this need to block 1.1.6?

-- GeorgeClark - 17 Oct 2012

Yes.

-- MichaelDaum - 17 Oct 2012

Its been almost 5 months since this rather major change was noted in 1.1.5, and the only mooted resolution has been a new feature, which should also not go into a real patch release.

so I am going to revert the Tasks.Item11666 changes from the 1.1. branch, so we can release 1.1.6 without more risks, and then look hard at implementing this feature in 1.2.0

this is the 1.1.6 reversion task, see Item for the 1.2.0 AddDefaultsToFields feature

-- SvenDowideit - 22 Oct 2012

This item is actually about a bug introduced by the new getDefaults() in 1.1.5 added to some formfield classes. This resulted in undesirable defaults in lots of cases. This has to be reverted. As part of the discussion AddDefaultsToFields was created as the real thing to do. Never the less, those undesirable defaults as reported here are new to 1.1.5 and should be fixed ... on stable and on trunk.

-- MichaelDaum - 22 Oct 2012

the reversion is the 1.1.6 fix - we do not believe that the new feature should be added to the 1.1.6 patch release. perhaps you should talk to the release manager for 1.1.6?

-- SvenDowideit - 22 Oct 2012

Why? Everything is fine.

-- MichaelDaum - 25 Oct 2012

Commenting is disabled while not logged in