Priority: Urgent
Current State: Closed
Released In: 1.1.6
Target Release: patch
Applies To: Engine
Component: DataForms
Branches: Release01x01 trunk
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