Closed ascheider closed 12 months ago
The reason is to not bloat the attribute mapping with loads of object brick / classification store fields. In our experience when more than 50 object brick / classification store fields get mapped, it is easier to map the fields directly via object brick container as key value array:
How to map fields via the container is described in the manual:
Alternatively you can directly map your data to the object brick / classification store container field by returning an associative array whose keys are the brick / classification store group names:
PHP:
return [ 'brickName' => [ 'field1' => $params['rawItemData']['field_1']['value'], 'field2' => $params['rawItemData']['field_2']['value'], 'name#de' => $params['rawItemData']['name de']['value'], // name is a localized field 'name#en' => $params['rawItemData']['name en']['value'], ], ];
Convenience features like resolving data query selectors are applied to all the provided fields, e.g.
return [ 'technicalAttributes' => [ 'cableLength' => 'AttributeValue:externalId:'.$params['rawItemData']['id']['value'].':value' ], ];
This will search for an object of the class
AttributeValue
whoseexternalId
equals the value from the raw data fieldid
and import this to the fieldcableLength
of the object bricktechnicalAttributes
.Or if the field name is part of the import data you can assign it dynamically:
return [ 'technicalAttributes' => [ $params['rawItemData']['attributeName']['value'] => $params['rawItemData']['attributeValue']['value'] ], ];
If this does not work for you, can you please describe your use-case a bit more?
@BlackbitDevs Hey,
thanks for feedback. i'm not speaking about more than 50 brick fields in general, but brick localized fields. If you have for example 10 languages and only 5 Fields in brick, the fields are missing in the mapping area. I also need an example how to translate the brick fields via deepL if i do it via container mapping. Thank you!
Ah ok, then I will change the limit field to check for "real fields", so that a localized field only counts as 1 field.
The translation can be triggered programatically via \Blackbit\DataDirectorBundle\lib\Pim\Item\Importer::translate("String to be translated", $targetLanguage, $sourceLanguage);
In 3.4 I now count localized fields only as one field. This should fix the problem in your case.
Nevertheless I will continue my original plan to be able to expand and collapse brick / classification store fields. This way if you have more than 50 brick fields, only the brick container field would be visible in attribute mapping but you can expand it with a "+" icon and then the single fields will get listed.
FYI: I just increased the threshold to 200 fields.
@BlackbitDevs Thanks. Works fine!
is there any reason why brick mappings area limited to 50 in the code? I have a customer with couple of bricks with localized fields, the mapping did not shown any of it. After some debugging i found some lines in Helper.php
if i remove break and if condition below, i can see all the mappings. In my opinion 50 is to few, if you have localized fields and couple languages.