Project

General

Profile

Actions

Feature #82211

closed

Allow generlOverride in formDefinitionOverrides

Added by Sebastian Fischer about 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Form Framework
Target version:
Start date:
2017-08-26
Due date:
% Done:

0%

Estimated time:
PHP Version:
7.0
Tags:
Complexity:
Sprint Focus:
Remote Sprint

Description

Currently it's possible to override form definitions for specific identifier.

If you have multiple forms and allow editors to add forms not all identifier are known while add typoscript for overriding.

Having an generalOverride that gets merged before the override of an identifier this would solve it.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Feature #84133: Variants - Frontend implementationClosedRalf Zimmermann2018-05-24

Actions
Actions #1

Updated by Gerrit Code Review about 7 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53809

Actions #2

Updated by Björn Jacob about 7 years ago

  • Sprint Focus set to Remote Sprint
Actions #3

Updated by Mathias Brodala almost 7 years ago

I'm not sure how exactly this would help with the usecase described. The only thing that would work reliably here is overriding toplevel form definition properties. As soon as you have renderables keys can be arbitrary (of course identifier s too) which makes it next to impossible to override specific entries.

Actions #4

Updated by Susanne Moog almost 7 years ago

  • Target version changed from 9.0 to 9.2
Actions #5

Updated by Björn Jacob almost 7 years ago

  • Sprint Focus deleted (Remote Sprint)
Actions #6

Updated by Björn Jacob almost 7 years ago

  • Status changed from Under Review to Needs Feedback

Sebastian, what do you think regarding Mathias's response? Do we still need this feature? How did you solve the issue for you? If you do not need this feature anymore, please abandon the patchset. Afterwards, we can close the issue. We are also open for discussing. On February 19 and 20 we are having a small sprint. This could be a good time for discussions ;)

Actions #7

Updated by Sebastian Fischer almost 7 years ago

Hi Bjoern,

i did not solved it for me. I just copies the form and modified the needed keys.

But to catch up Mathias comment i agree on what he said. BUT if we dont need a general overrides feature, why do we have an override for individual form definitions? Because what is true to my addition is also true to the part that is already there.
Once you are in a scope of renderable keys you cant override with $formDefinition['identifier'] anymore too.

For what i needed it was not solved by logic and clever coding but by swapping out templates by changing pathes via typoscript conditions. I still think its a stupid way of doing that but i wasnt willing to carry patches agains the core for that purpose.

If you still have problems with the patch i would like to know what the problem with the patch is. But by know it was only delayed without any good reason. I'd like to bring this issues to a solution but dont realy see what is blocking it.

I put it in your hands. If you think that having the opportunity to override all forms with certain values is less important then overriding values in forms with defined names then drop my request and explain why you dont want to have it in.

Kind regards
Sebastian

Actions #8

Updated by Sebastian Fischer almost 7 years ago

In addition: small example what is possible with that patch. You are able to override labels in a multilanguage multitree situation. Define the form once in german and have in a separate english tree different labels.

Or you can override email finisher configuration for development/staging to send the emails to a different testing emailbox then on production environment. For all forms even those that get added by editors in a later project state.

Actions #9

Updated by Björn Jacob almost 7 years ago

  • Status changed from Needs Feedback to New
  • Assignee deleted (Sebastian Fischer)
  • Sprint Focus set to Remote Sprint

Thx Sebastian. Next week we are having a small sprint to discuss the features of v9. I will put this issue on our agenda. Thx again for the detailed feedback and your effort.

Actions #10

Updated by Ralf Zimmermann over 6 years ago

The feature to override specific form definitions with typoscript is thought for integrators that render static forms from their site package.
Since these forms can not be changed by an backend editor, all form elements and their positions are known.
I think an override which applies to all forms for reasons already mentioned above is not helpfull.
We are currently developing a concept for conditional form elements, which should also solve the usecases you described.
In the next few days i will upload a first related patchset.

Actions #11

Updated by Ralf Zimmermann over 6 years ago

In the next few days i will upload a first related patchset.

https://review.typo3.org/c/54982/

Actions #12

Updated by Ralf Zimmermann over 6 years ago

Actions #13

Updated by Ralf Zimmermann over 6 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Sebastian Fischer

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

Actions #14

Updated by Sebastian Fischer over 6 years ago

Looks good to me. So this ticket can be closed in favor of 84133

Actions #15

Updated by Ralf Zimmermann over 6 years ago

  • Status changed from Needs Feedback to Closed
  • Assignee deleted (Sebastian Fischer)

Thanks.

Actions

Also available in: Atom PDF