resolveuid deserializer doesn't handle lists or nested dicts about plone.restapi

[davisagli]

The current situation is that you can implement an IBlockFieldDeserializationTransformer adapter to do it for the specific blocks and fields where it is needed. For example plone.volto has one that handles fields named columns, hrefList, or slides: https://github.com/plone/plone.volto/blob/main/src/plone/volto/transforms.py#L45

The idea of handling this generically might be okay as long as:
a. the performance impact is not too bad
b. the volto team isn't concerned about the backwards incompatibility (transforming fields that were not transformed before)

I would feel better if it were based on a block schema so that we could do it only for the fields that we know are referencing object paths, rather than using a heuristic based on field name.

[JeffersonBledsoe]

@davisagli Fairly new to using the block transforms so forgive me for any lack of understanding:

a. the performance impact is not too bad

This is my biggest concern with the change. There's an initial PR linked to this issue if anybody wanted to test this against their bigger blocks

b. the volto team isn't concerned about the backwards incompatibility (transforming fields that were not transformed before)

While the actual data would change, a resolveuid should still return the same URL for a working link right? Would this be breaking or not?

I would feel better if it were based on a block schema so that we could do it only for the fields that we know are referencing object paths, rather than using a heuristic based on field name.

Completely agreed. However, we don't really have the notion of a URL field right? The only hint is the widget in the frontend when using Volto. Would we need some kind of formal schema (e.g. #923 or plone/volto#2252) support for blocks to achieve this?

For more specific use cases, I agree that it's probably best to have specific adapters for more specific use cases, but I image most sites would want resolveuid rather than just storing the path.

[davisagli]

@JeffersonBledsoe I will try to take another look at this during the Beethoven Sprint. I'm not too worried about the performance impact or backwards compatibility, and it would certainly help avoid the need for lots of custom adapters.

I also have an idea about storing some information during resolveuid deserialization to be used by the linkintegrity retriever instead of walking the blocks again, which could help recuperate any loss of performance.

One important note: we need a similar change to the serializer to make sure the resolveuid URLs actually get resolved when getting blocks content.