Feature #81593

Usage of constants in YAML files

Added by Wolfgang Freund about 2 years ago. Updated 3 months ago.

Status:
New
Priority:
Could have
Assignee:
-
Category:
Form Framework
Target version:
-
Start date:
2017-06-16
Due date:
% Done:

0%

PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Are there any plans, or is it already possible to use constants in the FormDefinition YAML?
As for the email finishers i have to hardcode for example the recipientAddress.

As I work with different environments, mails should be sent to different recipients depending on the environment.

So it would be nice if following logic in the basic finishers would be possible:

finishers:
  -
    identifier: EmailToReceiver
    options:
      subject: 'Message form website'
      recipientAddress: {$my_site_package.fom.contact.recipient.email}
      recipientName: {$my_site_package.fom.contact.recipient.name}
      senderAddress: {$my_site_package.fom.contact.sender.email}
      senderName: {$my_site_package.fom.contact.sender.name}
      replyToAddress: '{email}'
      carbonCopyAddress: ''
      blindCarbonCopyAddress: ''
      format: html
      attachUploads: 'false'
      translation:
        language: 'en'

Related issues

Related to TYPO3 Core - Feature #84133: Variants - Frontend implementation Closed 2018-05-24

History

#1 Updated by Christoph Bessei about 2 years ago

Did you try TypoScript overrides? https://docs.typo3.org/typo3cms/drafts/code.tritum.de/TYPO3.CMS/Form_Documentation/Concepts/Index.html#typoscript-overrides
It's not exactly what you want, but sounds useful and I guess you could use constants there.

#2 Updated by Wolfgang Freund about 2 years ago

Yes already tried that. For me the approach with constants within the YAML file feels cleaner.
Nevertheless I tried some finisher overrides (for example the mail subject) and it does not seem to work in all cases...

#3 Updated by Denis Mir almost 2 years ago

The TS overrides are ok but constructs like

plugin.tx_form {
  settings {
    formDefinitionOverrides {
      SomeForm {
        renderables {
          0 {
            renderables {
              4 {
                properties {
                  privacyPageUid = {$plugin.someExt.general.privacyPagePid}
                }
              }
            }
          }
        }
      }
    }
  }
}

are not really nice since you have to hard code the indexes in the array which fail when something gets added in between in the configuration file. It would be a lot better to be able to use TS constants in the YML file.

#4 Updated by Ralf Zimmermann over 1 year ago

#5 Updated by Ralf Zimmermann over 1 year ago

  • Status changed from New to Needs Feedback
  • Assignee set to Wolfgang Freund

I think your use case can be handled with variants #84133.
Feel free to test the patchset :)

#6 Updated by Christian Ludwig about 1 year ago

The use of variants is really nice and useful but with constants you have imho some advantages.

  • You can centralize the things that need to be changed when moving to an other production stage. So simply changing or adding condition to one file will have effects to the complete installation.
  • When email addresses change, you will have one place to check and update.
  • It is possible to change constants within the page tree in a sub template (will break the two other advantages).

Or are all these things possible with #84133?

#7 Updated by Denis Mir about 1 year ago

Indeed Christian Ludwig is right.

For example we use constants as the one single entry point for configuration of the whole TYPO3 installation depending on locale, context and other conditions. We configure everything from one constants file sitting in our main extension. (every custom/sysext/third party extension including its plugins, modules etc.)

Variants look nice but I don't get why we need to duplicate all the functionality already available with constants. In addition it spreads the configuration all over our setup and adds another configuration point.

Variants do blow up the YAML file even further when it could be as easy as just reading the value from a constant.

#8 Updated by Bjoern Jacob 3 months ago

  • Status changed from Needs Feedback to New
  • Assignee deleted (Wolfgang Freund)
  • Priority changed from Should have to Could have
  • PHP Version deleted (7.1)

Also available in: Atom PDF