Item12090: Field name -with description- in Forms not working properly.

When I add a description to a field name in a Form ([[Name][Description]], Foswiki uses the 'description' part as the 'name' for the field.

Maybe it is easy to see in an example:

In the form "ChooseForm", with a form field with a name like:

[[Favourite][Tell us which is your favourite]]

You would think you have a 'ChooseForm.Favourite' field which you can refer to from within a topic. But this is no so, because the name of the field is not saved in the topic .txt file as name 'Favourite', but as "Telluswhichisyourfavourite":

%META:FIELD{name="Telluswhichisyourfavourite" attributes="" title="[[Favourite][Tell us which is your favourite]]" value=""}%

And therefore it must be referred to as 'ChooseForm.Telluswhichisyourfavourite', which seems wrong.

This has been tested in Centos 6 with foswiki version 1.1.5.

Cheers!.

-- FredAstaire - 25 Sep 2012

I suppose a lot of people (such as me) worked around with the current behaviour of foswiki. So a fix should not break this or show a path for correcting things easily.

-- MichaelLorenzen - 25 Sep 2012

I had also noticed this a while back and wondered whether I was just doing something wrong, but the description above is completely accurate. Under no circumstances can the shorter "FieldName" attribute in the example ever be used to refer to, or extract information from, a field named in this manner.

Even using a native internal Foswiki macro, an attempt to do:

 %FORMFIELD{Favourite}% 

...will fail every single time. Only:

  %FORMFIELD{Telluswhichisyourfavorite}%  

...would return the correct information. Thus there is really no proper functionality at all currently associated with the dual-part formfield naming syntax suggested in the documentation. It's just extra typing with no benefit returned.

-- DylanMaccarone - 19 Dec 2012

See related proposal for providing way to specify custom field title: CustomizeDisplayedFieldTitle.

-- LynnwoodBrown - 27 Apr 2015

I think that the documentation certainly could be clearer. There are two conflicting statements: (see System.DataForms#Form_field_attributes

Field names can in theory include any text, but you should stick to alphanumeric characters. If you want to use a non-wikiname for a select, checkbox or radio field, and want to get the values from another topic, you can use [[...]] double bracket links. This notation can also be used when referencing another topic to obtain field values, but a name other than the topic name is required as the name of the field.

I think that this is the statement that describes what you are seeing. It's the mechanism to associate a Topic name (the left side) with the Field name (right side). The right side, with spaces removed becomes the name of the field. For example: [[AeroMfgs][Aeroplane Manufacturers]] would load values from the topic named AeroMfgs, would store the selected choice into field AeroplaneManufacturers, and would display the field with the space Aeroplane Manufacturers

The next statement:

If you want the Field name to include embedded spaces, use the format [[FieldName][Descriptive human-friendly Field Name]].

This 2nd statement is in conflict with the first statement. The left side is not the Field Name, it's a topic name for choice retrieval. The left side cannot both be a topic name, as the 1st statement asserts, and a field name per the 2nd statement, and the right side cannot be both the field name, and the user friendly display name.

I think that the solution here is to drop that conflicting 2nd statement. And recommend MichaelDaum's suggestion of the FlexFormPlugin for more flexible rendering.

-- GeorgeClark - 24 Mar 2017

Yes. Just delete the 2nd statement. It is wrong.

-- MichaelDaum - 24 Mar 2017

Fixed as a documentation change.

-- GeorgeClark - 24 Mar 2017

Commenting is disabled while not logged in