Bug #50785

FlexForm does not substitute markers in foreign_table_where

Added by Gabriel Kaufmann / Typoworx NewMedia almost 7 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2013-08-05
Due date:
% Done:

0%

TYPO3 Version:
4.7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

We tried to use a field-to-select condition in a flexform.

Simple example:

We have a FlexForm containing two Select-Fields:
1. StoragePid (Selecting from Pages-Table)
2. Any foreign record (like tt_address) that should show all records matching the FlexForm "StoragePid".

As FlexForm simply consists of XML'ified TCA we thought we can use ###REC_FIELD_StoragePid### (whereas "StoragePid" is the XML-Name of our Storage Selector form pages).

We noticed that the markers are not working correctly by reading/substituting those values from FlexForm XML.

class.t3lib_tceform.php_forge-50785.patch View (2.84 KB) Gabriel Kaufmann / Typoworx NewMedia, 2013-08-12 10:43


Related issues

Related to TYPO3 Core - Bug #30354: FlexForm select fields can't replace makers in their foreign_table_where clause Closed 2011-09-27
Related to TYPO3 Core - Bug #16392: Page-TSconfig ###PAGE_TSCONFIG_STR### not evaluated correctly in Backend Closed 2006-07-21

History

#1 Updated by Gabriel Kaufmann / Typoworx NewMedia almost 7 years ago

May be also related to: #30354

#2 Updated by Gabriel Kaufmann / Typoworx NewMedia almost 7 years ago

Well I didn't find the right entry-point for a Core-Patch yet.

  1. The ##REC_FIELD_[ ROW-FIELD ] is substituted within t3lib_befunc::exec_foreign_table_where_query.
  2. The parsing of different Field-Types for TCA is done in t3lib_flexformtools.
  3. Setting a "Dummy" Field within t3lib_flexformtools::traverseFlexFormXMLData (f.e.) doesn't work as t3lib_befunc is accessing the row using $TSconfig['_THIS_ROW']

Anyone having ideas how to solve this?

Of course I could also use an ItemProcFunc on EACH PROJECT I ever need this. But I really think there should be one place to solve this problem and this would be the Core to have a one-place solution that is working for all.

#3 Updated by Gabriel Kaufmann / Typoworx NewMedia almost 7 years ago

Since this issue/feature seems to be more complicated than I expected, I have to fall-back to itemProcFunc in FlexForm.

I believe we have to patch t3lib_BEfunc::exec_foreign_table_where_query()
as there the REC_FIELD's are substituted.

Too bad - there is no "row" argument used f.e. t3lib_transferdata::renderRecord_flexProc. Instead t3lib_BEfunc::exec_foreign_table_where_query() uses $TSconfig['_THIS_ROW'] build somewhere else.

I believe the integration way for this FlexForm-Feature would be:
  1. Check if the current-field renderes is inside FlexForm (refer to t3lib_transferdata::renderRecord_flexProc).
  2. Map all FlexForm-Values (of course we should respect lDEF and a possible localisation!) to the DB-Row temporarely (for Flex-Field rendering only).
  3. May be t3 t3lib-Rendering needs a complete clean-up to have one Storage for the current row?

Any ideas or suggestions are welcome!

#4 Updated by Gabriel Kaufmann / Typoworx NewMedia almost 7 years ago

I have worked-out a patch that is fixing the missing fields for the "###REC_FIELD_" markers.

For this I patched "t3lib_tceforms" (see patch file provided).

I would be glad for approval and submitting to Trunk. The patch has been created on TYPO3 4.7.12.

About the patch:
I had to set a class-variable around the flex-rendering to let sub-processess (also used by normal TCE rendering) that it is currently acting within FlexForm-Fields.

All "Flex" fields (marked as type "flex" in TCA) are processed now.

The current patch provides the following syntax:
###REC_FIELD_[ flex-fieldname ].[ flexform-field ]###

f.e. to access a field from TemplaVoila FlexForm field named "field_storagePid":
###REC_FIELD_tx_templavoila_flex.field_storagePid###

The original field is prepended to avoid conflicts between multiple database-fields that may have the same name!

I would be glad about any feedback here.

#5 Updated by Wouter Wolters almost 6 years ago

  • Status changed from New to Resolved
  • Is Regression set to No

Resolved with #16392

#6 Updated by Benni Mack over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF