Handle different Akeneo data types in value handlers
Closed this issue · 5 comments
Currently there are some value handlers assuming a specific value array. For example all the TVs on the Akeneo demo cannot be imported with this plugin because its variant axe is the attribute display_diagonale which is an Akeneo pim_catalog_metric attribute. In this case the data key in the value array is like {"amount":"-12.78","unit":"KILOWATT"} but the ProductOptionValueHandler assume that this data is a plain string.
The full list of possible data types could be found here: https://api.akeneo.com/documentation/resources.html#product
Should we create a new MetricValueHandler and specify in the configuration which fields should be imported as metric or could we implement the "array data" handler in AttributeValueHandler?
In addition, if we choose the first choice, how could we let the metric attributes be handled only from MetricValueHandler and not also from AttributeValueHandler?
Good point. I think it should be the second choice. Currently all the value handlers naming and concept is based on where the data will be stored on Sylius rather than the attribute type on Akeneo.
With this concept in mind a "MetricValueHandler" should store data in some sort of metric data structure on Sylius. There's no such data structure on Sylius. So we have to think where we want to store, on Sylius, those Akeneo's metric attribute values.
One solution could be to store metric attributes values (and also price attributes values) in Sylius text attributes by concatenating the value with its measurement unit (or with its currency for price attributes).
What do you think @lruozzi9? And you @fabianaromagnoli?
Good point. I think it should be the second choice. Currently all the value handlers naming and concept is based on where the data will be stored on Sylius rather than the attribute type on Akeneo.
This is true for all ValueHandlers except FileAttributeValueHandler.
One solution could be to store metric attributes values (and also price attributes values) in Sylius text attributes by concatenating the value with its measurement unit (or with its currency for price attributes).
Yes, I think that this is a good solution.
This is true for all ValueHandlers except FileAttributeValueHandler.
Yes you're right... Probably, a better name of FileAttributeValueHandler should be something like RawFileValueHandler. Indeed, currently, if you have an image attribute on Akeneo and you want to store it as a raw file on Sylius you can use the FileAttributeValueHandler. So the FileAttributeValueHandler it's not necessary tied to an Akeneo file attribute.
What I think we could implement is a service "MetricAttributeHandler" or "MetricValueHandler" (the second would be more correct, but I think it could create confusion). This service handles the metrical attributes in AttributeValueHandler and other ValueHandler like PriceValueHandler and when necessary, could be implemented by the user to manage metric attribute as needed.