Item9404: SEARCH's $ formfield() doesn't return the bare formfield values

Instead it calls FieldDefinition::renderForDisplay

This wasn't a problem before as there where no formfield types that implemented a specific way to display its values.

Now, we have color, rating and whatever which display their formfield values in a customized way.

However, in a SEARCH expression like this one

%SEARCH{"Rating0" scope="topic" nonoise="on" format="$web.$topic - $formfield(Rating)" }%

You'd actually want to have the real value, not the way it renders the view.

This bug also shows up on foswiki-1.0.9 and probably before that as well.

How to reproduce

1. create a RatingForm and add it to WEBFORMS

Name:	Type:	Size:	Values:	Tooltip message:	Attribute
Rating	rating	5	1, 2, 3, 4, 5

2. create a test topic Rating0 and attach RatingForm to it

3. add the above SEARCH expression

4. shows

5. should be Sandbox.Rating0 - 2

Any comments?

-- MichaelDaum - 28 Jul 2010

The reason formfields are rendered is mainly a problem with newlines

The most common format string in a SEARCH is a TML table. And a TML table that shows textarea with newlines will break the table.

It is important that we do not change the way things work so that $formfield stops encoding newlines as an html break.

We will break thousands of formatted searches among our users if we do.

The solution that has been discussed a lot has been to add a 4th parameter to $formfield so you can enable or disable the encoding - keeping current behaviour as default.

I am sure it is OK to not render formfields using the rendering function.

The only issue is to ensure that the newline and maybe the vertical bar gets encoded by default.

This is an enhancement needing a feature request. And not a release blocker.

-- KennethLavrsen - 28 Jul 2010

SEARCH is at the very heart of wiki-applications and why foswiki is called a structured wiki. That's why it is so important to get $formfield() right. I sure agree on the linebreaking thing with you. But calling all of the renderForDisplay() for it is an independent thing.

So: not returning the data and instead reaturn a view of a formfield is a missconception. For instance you can't further process the result using %CALC or whatever.

-- MichaelDaum - 28 Jul 2010

As long as we agree on the $formfield still encoding textareas as it does in 1.0.9 I am OK if you attempt to fix this.

But I still see it as no release blocker for 1.1. But if you can fix it in time for 1.1 go ahead.

-- KennethLavrsen - 28 Jul 2010

I would consider any change to the way $formfield works to be dangerous. Very dangerous. I explored changing it once before, and got into a world of pain, mainly because of the newlines/encoding/br issues.

A safer way to get the real value would be $percentQUERY{'Rating' topic=\"$topic\"}$percent

-- CrawfordCurrie - 29 Jul 2010

Based on Crawford's words I feel better that we change this to enhancement again and think about this carefully in a feature proposal for 1.2 or 2.0.

We are finally getting to a 1 digit number of urgent real bugs and I can start smelling a 1.1 release. Opening a can of worms now is not wise.

-- KennethLavrsen - 29 Jul 2010

Commenting is disabled while not logged in