You are here: Foswiki>Tasks Web>Item10071 (11 Apr 2012, GeorgeClark)Edit Attach

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

Priority: Normal
Current State: Closed
Released In: 1.1.5
Target Release: patch
Applies To: Engine
Component: DataForms
Branches: Release01x01 trunk
Reported By: MichaelDaum
Waiting For:
Last Change By: GeorgeClark
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:

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 would fix it:

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


    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

ItemTemplate edit

Summary select+values formfield doesn't display its mapped value
ReportedBy MichaelDaum
Codebase 1.1.4, 1.1.2, 1.1.1, 1.1.0, 1.1.0 beta1, 1.0.10, 1.0.9, 1.0.8, 1.0.7, 1.0.6, 1.0.5, 1.0.5 beta1, 1.0.4, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 1.0.0 beta3, 1.0.0 beta2, 1.0.0 beta1, trunk
SVN Range
AppliesTo Engine
Component DataForms
Priority Normal
CurrentState Closed
Checkins distro:dbb90cc38d6d distro:68bab4d01c12 distro:b81fa90080f8 distro:6cb12a165a97 distro:9d8f31287d87 distro:40c4191691d2 distro:d832f40bc81b distro:127ad835b238
TargetRelease patch
ReleasedIn 1.1.5
CheckinsOnBranches Release01x01 trunk
trunkCheckins distro:dbb90cc38d6d distro:b81fa90080f8 distro:9d8f31287d87 distro:d832f40bc81b
Release01x01Checkins distro:68bab4d01c12 distro:6cb12a165a97 distro:40c4191691d2 distro:127ad835b238
Topic revision: r25 - 11 Apr 2012, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy