Project

General

Profile

Actions

Bug #64532

closed

Epic #69347: EXT:form - Optimize form wizard

sysExt:Form Wizard taking Select->Option->value into Account

Added by Stephan Ude over 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Form Framework
Target version:
-
Start date:
2015-01-27
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
5.6
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

This is about the form extension of TYPO3 6.2. I have not tested the behaviour described below in other TYPO3 versions.

Currently the value attribute of select box options is not really used by the form extension. You can set the option value by adding the variable 'value' to the TypoScript object - an index is used if it is not set - but even the standard MailPostProcessor is not using this value. Instead it is sending the (HTML-)content of the option tag (data).

10 = SELECT
10 {
    name = salutation
    label {
        value = Salutation
    }
    10 = OPTION
    10 {
        data = Mr
        selected = selected
        value = 1
    }
    20 = OPTION
    20 {
        data = Mrs
        value = 2
    }
}

The wizard itself is ignoring the 'value' attribute completely. Even if you set the value in the TypoScript of your form, it will be deleted when the form is being saved with the form wizard.

In my opinion this behaviour should be changed. The data of an option tag is the label shown to the website user. It is not an ID or code, it may change any time and it even may be translated. This is not the right data for a PostProcessor.

I don't have a patch for the standard MailPostProcessor (and I guess it won't be changed anyway as the extension shall be backward compatible), but I did a patch for the form wizard so that one is able to edit and save the value field of a select option correctly.

With this patch (I hope the format is okay, I am a newbie to all this) we are at least able to handle the value attribute in our own PostProcessors. That would be great. As long as the wizard is deleting the value attribute on any save action, we are unable to use it anywhere.


Files


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Feature #69409: Forms: allow value attribute of OPTION object in wizardClosed2015-08-29

Actions
Actions #1

Updated by Björn Jacob almost 9 years ago

  • Category set to 1602
Actions #2

Updated by Björn Jacob almost 9 years ago

  • Category changed from 1602 to Form Framework
Actions #3

Updated by Björn Jacob almost 9 years ago

  • Tracker changed from Feature to Bug
  • TYPO3 Version set to 7
  • Is Regression set to No

It's a bug not a feature :)

Actions #4

Updated by Björn Jacob almost 9 years ago

  • Parent task set to #69347
Actions #5

Updated by Björn Jacob almost 9 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Stephan Ude

The issue describes several problems:

  1. The OPTION value is not transferred via postprocess. Right now I'm not sure what we should do with the value and how we could handle it. No real persons needs the value since it's not human readable. What do you want to achieve with the value? Should it be configurable somehow whether to use the value or the data attribute?
  2. The wizard does not support the value attribute. We will test your patch and include it if applicable. By design, the wizard does write the whole configuration when storing the wizard. There is no merge process, i.e. manually added values to the bodytext are overridden when storing the wizard. For this part I'm creating a new issue. See #69409:

@Stephan: Could you please answer me regarding problem 1.

Actions #6

Updated by Stephan Ude over 8 years ago

You are right, the standard postprocess algorithm (MailPostProcessor) is creating an email and there is not really a point in sending cryptic unique identifiers to a real person. For other purposes one should create an own PostProcessor which is using the value instead of the data.
My real concerns should be solved with ticket #69409.

In my opinion this ticket can be closed.

Actions #7

Updated by Björn Jacob over 8 years ago

  • Status changed from Needs Feedback to Closed

Issue #69409 has been solved already and is part of 7.5.

Closing this issue. Thx Stephan for your feedback!

Actions

Also available in: Atom PDF