Create a Pass through Serializer/Normalizer about strawberryfield

[marlo-longley]

Ok, to clarify the answer that @DiegoPino gave to my above question in conversation. Yes, the task is to reverse. To be able to take an expanded Strawberryfield item and ingest it, through denormalizing in the StrawberryfieldFieldItemNormalizer, into the format the system expects to work with, aka a string. We discussed what the test for success for this task would be:

1. to correctly push an expanded SBF over REST or JSON:API and store it correctly
2. to correctly push JSON files stored in our minio dostorage. Each of these files are full backups of a digital object node, which can bear strawberryfields. The idea would be, in the future, to be able to fully restore Archipelago content based on these files alone.

Regarding test 2, which I took pretty literally. There are certain fields, like the node ID, stored in our minio JSON that cannot be present when creating a new node (uuid is OK). Also, some fields like those containing revision information are immutable (or, at least I was encountering permission issues with them, when operating as admin). These are node level fields, not inside Strawberryfield, so not denormalized with StrawberryfieldFieldItemNormalizer. I started trying to write a node-level Normalizer to deal with them, and asked Diego about the approach.

He pointed out this could potentially be way too powerful and impact the entire system, and suggested we could store potentially store data differently in minio. I agree, messing with Node denormalization is probably bad. Can return to this point later.

(whatever approach we come up with for fields like revision, it will be important to preserve that history, and potentially add a new revision while ingesting, or mark the ingest in some way in the data).

[DiegoPino]

See (all pretty basic)

https://www.mediacurrent.com/blog/using-normalizers-alter-rest-json-structure-drupal-8/
https://www.adcisolutions.com/knowledge/how-send-json-data-drupal-8-site

Tests Notes:

I will have to run something like

$serializer = \Drupal::service('serializer');
$node = Node::load(2);
$data = $serializer->serialize($node, 'json_passthrough', ['plugin_id' => 'entity']);

To make sure all is working once this is done?

[marlo-longley]

@DiegoPino I read and understood your work in #15, and what the difference in returned format is when StrawberryfieldFieldItemNormalizer is enabled vs disabled, and how it works together with StrawberryFieldItem.

My understanding of the task is to take an input in the format you can see at /do/<id>?_format=json nicely generated by your custom normalizer, and basically reverse the process. What is the larger context of when that reversal would need to take place? Purely over the REST? Understanding that would help me understand the concrete task.

[DiegoPino]

@marlo-longley good explanation. We/you can share a Dumped full Object in JSON here and mark those fields that can not be used via REST. Of course, when thinking about REST v/s a full blown recover-from-filesystem app, on the later, we can always preprocess the dumped JSON, stripping the protected properties out before denormalizing and ingesting skipping the REST endpoint.Not saying REST or JSON API are not needed, indeed we want that to work.

I also feel the all numeric uid and nid and fid (any content entity primary id really) should be removed and/or replaced by their UUID counterparts in our file/json/minio/dumps. Since we will have/already have nodes depending on other nodes or referencing files, and as you know, we have no control on what numeric IDs Drupal will end assigning them, making the interrelation between entities a nightmare to handle when dumping, e.g a full collection and restoring. But UUIDs are stable and can be set!

[DiegoPino]

Implemented