Allow mapping of file URI to a field

It make sense. I'll add a note for a future implementation of that feature from 📌 [META] Roadmap for v3.0 Active (currently under "For v3 beta 5"):

See if xntt_file_field module could rely on an added file field property (computed) rather than on another xntt field for the URI mapping

As those are tightly related.

The URI mapping works by associating the URI with a label, which can create issues when dealing with multiple files. In this case, an array of URIs would be required, but this doesn't map well to the expected string format for the URI field. While this setup works fine for viewing, it causes problems when saving, as shown in my code.

My questions are, why is it necessary to map to a field that corresponds to a JSON property? Why not allow the file field to directly map to a property that can hold either a single URI or an array of URIs? Is there a specific use case where mapping to a label is beneficial? Additionally, is it possible to modify the approach so that the file field has its own property for direct mapping?

Furthermore, I have this parent::addFieldValuesToRawData($field_values,$raw_data,$context); commented out, as I was pretty sure it does nothing for the file field. Is that fine? or should I include it?

(...) why is it necessary to map to a field that corresponds to a JSON property? Why not allow the file field to directly map to a property that can hold either a single URI or an array of URIs? Is there a specific use case where mapping to a label is beneficial? Additionally, is it possible to modify the approach so that the file field has its own property for direct mapping?

I'm quite sure we can get rid of an extra text or URI field to map a file field. Like you said, I think it is possible to have the file field has its own file URI property. I didn't investigate though, so I can't guarantee it possible. That's why I added to the roadmap for v3 what I put in #2 here. It needs to be investigated, and it is quite complex I think. I was planning to do it in the coming months but not in the coming weeks. Feel free to investigate! :-) But I may not be able to provide extensive support due to my other priority tasks.

Furthermore, I have this parent::addFieldValuesToRawData($field_values,$raw_data,$context); commented out, as I was pretty sure it does nothing for the file field. Is that fine? or should I include it?

I'm not sure. I think I left it in case, one day, the parent needs to do something special that should be applied to every field mapper, for instance triggering an event. But if it is commented because it does nothing right now, it's ok. If one day, the parent does something, then (maybe after a new issue is raised... :) ) we would put back the call to the parent method. Not a big deal.

@guignonv: So the merge request (MR) is good so far? No major changes required?

@sugen: I would uncomment it and keep it it in. If it does nothing for now, that's fine, but at least we won't have to remember to add it back in later if/when we actually do need it.

I realized that the generic mapper is more efficient for both posting and retrieving data in the file module. Instead of modifying the file URL mapper, I will use the generic mapper, as it already maps the ID to its corresponding array effectively.