Item10071: select+values formfield doesn't display its mapped value

Given this DataForm definition

Name	Type	Size	Values	Tooltip message	Attributes
Test	select+values	1	one=1, two=2, three=3

When editing this field a proper select box is rendered, more or less like this:

one two three

Here, the user only gets to see the display labels of the data model underneath.

However, after saving his work the field is not rendered as "one", "two" or "three". Instead the raw data underneath is displayed.

That's bad actually. Not sure for how long this stuff behaves like this.

Fixing this bares the risk of breaking some wiki apps, though I can't think of any that would use select+values and then not expect the mapped display labels to show up in the DataForm at the bottom of the topic.

Basically, anything calling renderForDisplay() should get the mapped values, not the raw data.

Adding this to Select.pm would fix it:

sub renderForDisplay {
    my ( $this, $format, $value, $attrs ) = @_;

    $this->getOptions();

    if ( defined( $this->{valueMap}{$value} ) ) {
        $value = $this->{valueMap}{$value};
    }
    return $this->SUPER::renderForDisplay( $format, $value, $attrs );
}

-- MichaelDaum - 24 Nov 2010

To the best of my knowledge it has always worked this way, and as long as we insist that data forms can be rendered without reference to the form definition topic (which contains the mapping) it has to continue to work this way. Your proposed change does not change the display of values, just their editable representation.

If you want the displayed value and stored value to be the same, then don't use edit labels.

No action.

-- CrawfordCurrie - 26 Nov 2010

Re-opened. This at least needs documentation in the System.DataForms topic.

-- PaulHarvey - 26 Nov 2010

Crawford, not sure I have understood why this must not change. What I refer to is the way the formfield value is displayed in the display at the bottom of the page ... as being created by renderForDisplay(). My proposal does indeed change the display only. Not their editable representation. This is about fixing renderForDisplay() ... not renderForEdit(). The latter does just fine - the first does not. For the user both should view the same, independent of how this is stored. That's why we have this +values feature. For now the separation between model and view is half broken.

And agreed: it always was broken. Doesn't mean we can't fix it now, does it?

All I want is to display it the very same way it is edited ... independent of how it is stored.

That's why I would call this a bug: they do not display the same way in edit and in view. This is most irritating for users.

-- MichaelDaum - 26 Nov 2010

Paul, fair enough.However this is not urgent, regrading to Normal. Also changed the headline from "a select+values formfield isn't displaying its mapped value"

Michael, I know. However, as you know, the display of formfields is decoupled from the schema that defines them. The schema is loaded for editing (hence the mapped field values) but is not loaded at the time a formfield is displayed. There is only the information from the META:FIELD available to complete the display - and that does not include the mapped value.

Of course you could extend the stored for to include the mapped value in a new attribute. Better that than loading the form definition for each display.

-- CrawfordCurrie - 06 Dec 2010

No, this is not a "docu problem".

A select+values formfield definition does indeed define both a storage schema and a view how to display the value. That's what the +values is all about.

More technocally speaking: both renderForEdit() and renderForDisplay() must call getOptions() to establish the value map before rendering the display, and then do the same replacement as it is done rendering the editor. There must not be a difference here as that's most irritating for the user.

Reverting the Summary to describe the error accurately again.

Fixing this bug is a preliminary step of an upcoming feature request to add +values to checkboxes and radioboxes.

-- MichaelDaum - 07 Dec 2010

I think you are both right.

The view should show the mapped value and not the stored value. The value of select+values is rather small if the displayed value is not the same as you select when you edit.

BUT Crawford is also right.

A topic view needs to be independent on the form definision topic for two reasons.

The form may have changed since the topic was created or edited last time and then the topic still needs to be displayed as it was with the values that were present in the form at that time. And the fields that were available at that time.

And the minute you edit the topic, you get the new form definition activated.

So the issue is - how do we fix the problem? We need a technical solution. Why not extend the META:FIELD so it holds both the current stored value and add a displayed value?

For compatibity the code starting from 2.0 will show the value if there is no stored displayed value.

There is still the current use case to consider. Maybe some users have used the very complex displayed edit value as a help text and do not really want it displayed during view? I doubt it but worth noting in a feature proposal. But even if a few have done this I think the majority of users will prefer things working as Michael suggests. And extending the feature for also radio and checkbox will be really good. I have missed this.

-- KennethLavrsen - 07 Dec 2010

Related report Item9647

-- MichaelDaum - 14 Mar 2011

FWIW, our site is now using Michael's code suggestion. Time to commit on trunk?

-- PaulHarvey - 07 Jun 2011

The complete patch including radio+values and checkbox+values has been proposed at AddPlusValuesToRadioAndCheckboxes

-- MichaelDaum - 07 Jun 2011

Re-opened. Fix broke unit tests. Fixed it.

-- CrawfordCurrie - 17 Jan 2012

Commenting is disabled while not logged in