Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The current JSON-LD Normalizer directly processes the properties, accessing them with the getValue method and adding them to the array. However, there are some fields which should have custom processing of values, such as EntityReference fields.
Adding Normalizers at the field level in addition to the entity level will allow us to control the normalization on a type by type basis.
Comment | File | Size | Author |
---|---|---|---|
#13 | 1832840-13-field-normalizer.patch | 23.72 KB | linclark |
#13 | interdiff.txt | 2.12 KB | linclark |
#9 | 1832840-09-field-normalizer.patch | 23.61 KB | linclark |
#9 | interdiff.txt | 3.21 KB | linclark |
#6 | 1832840-06-field-normalizer.patch | 23.4 KB | linclark |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThis patch changes the JsonldNormalizer to JsonldEntityNormalizer. It also adds:
It removes the DrupalJsonld variant of the Normalizer, and makes it so that all Normalizers support both formats. For the cases where the two differ (for example, FieldItem), we will simply add a second Normalizer that only responds to drupal_jsonld and give it higher priority.
I removed the test for the regular jsonld format, since we don't yet support the difference between the two. It will be added back once there is a difference.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedWe're trying to prioritize POST and PUT handling in the REST development, which depends on #1838596: Add deserialize for JSON-LD, which depends on this issue... so hopefully we can start working through the review process.
Comment #4
fago+1 for running each complex data item through the serializer again.
What about doing a general typed data normalizer? I.e. iterate over the object and if the property/item is implementing the list or complexdatainterface invoke the normalizer on it. Or maybe better have 2 implementations, one for normalizing lists and one for complex data. The nice thing is that any typed data structure will have at least some reasonable default serialization.
Then, e.g. ER fields could chime in and override the normalizer with their own implementation.
Comment #5
webchickI believe this is pretty important to web services in core. Escalating to a "major" feature request.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commented@fago Thanks, that pointed out a flaw in the initial patch.
List: Traversables should be handled natively by Serializer.... so it turns out that Field (being a list) is already supported without the FieldNormalizer. I've removed that from the patch.
Complex Data: As far as I can tell, ComplexDataInterface is too broad to be useful when normalizing for JSON-LD. Both EntityInterface and FieldItemInterface extend it. For the EntityInterface, the bulk of normalizing is about placing the id, context, type, etc. For FieldItems (except EntityReference) these attributes don't apply. It might be useful, though, I could be missing something.
Comment #7
moshe weitzman CreditAttribution: moshe weitzman commentedThis looks solid to me.
4 instances of a single whitespace on a line.
Let's document the $format and $serializer params
LANGUAGE_NOT_SPECIFIED instead of 'und'
Would array_intersect() be simpler here?
Comment #8
fubhy CreditAttribution: fubhy commentedCan you move the ->addTag to a new line so it's more readable?
Also, I am not sure if the loop is more readable now. I think I preffered the 'old' version :).
In this simple case I wouldn't even put the $priority in a variable. But yeah, these are all just nitpicks.
Normalizer? This is in the encoder, no?
If you flip that statement around it would skip the parent::supportsNormalization if $data is not an instance of EntityNG. Just a minor improvement though I guess.
Why so complicated? $skip is just a single item, so why not just use unset($properties['skip']);
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks for the reviews.
Made all the changes in #7, except the last. We want to exclude the keys in the skip array, whereas intersect would give us only those keys.
From #8, moved ->addTag to a new line and fixed the comment.
RE: parent::supportsNormalization, order matters for that because the parent checks whether it is an object.
RE: the $skip array, the idea is that we will probably have other items that we want to ignore, like langcode. I'm waiting until we have a full representation before starting that discussion.
Comment #10
moshe weitzman CreditAttribution: moshe weitzman commentedI think feedback has been fully addressed. Please wait for green before commit.
Comment #11
fubhy CreditAttribution: fubhy commentedfrom IRC:
Comment #12
fagoSounds great.
I think there could be a general complex-data serializer, which then the entity-serializer extends in order to customize it. It can work like the field-item normalizer, but would require one addition: For each property check whether its a list or complex data itself and invoke normalizing on it if so. Howsoever, that's just a nice-to-have point, so if we want to do so, this can happen in a follow-up.
Maybe add a TODO to replace the check for EntityNG by EntityInterface once all entity types are converted.
I think this should use ->getPropertyValues() not getValue(). You could do your own field item having whatever plain value, while getPropertyValues() always returns the wanted array structure.
Should check for FieldItemInterface.
Setting to needs work for the last two points.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks fago, I've made those changes.
Comment #14
fagoThanks, looks good! Back to RTBC then.
Comment #15
Dries CreditAttribution: Dries commentedThis patch is a nice clean-up and very straight-forward. Committed to 8.x. Thanks!