JSON API Extras lets you disable and rename fields, as well as change the schema of the fields. There is a thin layer of abstraction that will make that almost transparent for Schemata, but we'll need to make use of it.

CommentFileSizeAuthor
#18 2882269-15-schemata-suppport-public-name.patch3.72 KBrichgerdes
#15 2882269-15-schemata-suppport-public-name.patch0 bytesrichgerdes
#15 2882269-12-15-interdiff.txt2.73 KBrichgerdes
#14 2882269-6-12-interdiff.txt3.74 KBrichgerdes
#12 2882269-12.patch2.87 KBShumaS
#6 2882269-6.patch1.54 KBwim leers

Comments

e0ipso created an issue. See original summary.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Active » Postponed

I could not figure out a way to implement this without getting too complex or without creating a dependency on JSON API. I'm going to postpone this. Feel free to close it.

Grayside’s picture

Grayside commented

Similar to #2864667: The service "serializer.normalizer.data_reference_definition.schema_json.hal_json" has a dependency on a non-existent service "rest.link_manager", we could have a normalizer that introduces support based on the given module being enabled. Kind of a progressive-enhancement of schema behavior. Good demonstrations of how the schema can be customized have value.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Support for JSON API Extras » Support for JSON API's ResourceType::getPublicName() and ResourceType::isFieldEnabled()
Priority: Normal » Major
Status: Postponed » Active
Related issues: +#2873820: Allow customizations, +#2873820: Allow customizations

JSON API Extras lets you disable and rename fields, as well as […]

You still need JSON API Extras for a UI to do this. But the infrastructure for this actually lives in JSON API itself, and has since April 2017, since #2873820: Allow customizations.

And now JSON API is looking to use this too, to make its normalizations truly comply with the JSON API spec: #2977669: Spec Compliance: some entity types have an "id", "type" or "uuid" field, this violates the spec. So that changes this from

supported by the base module but only ever used by the Extras module, which is used by ~10% of users

to

supported and used by the base module and hence 100% of users

.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2977669: Spec Compliance: some entity types have an "id", "type" or "uuid" field, this violates the spec, +#2967572: Small inaccuracies for JSON API schemas

#2967572: Small inaccuracies for JSON API schemas fixed similar inaccuracies earlier today.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Needs review
Issue tags: +API-First Initiative
StatusFileSize
new 2882269-6.patch1.54 KB

This makes it work!

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Category: Feature request » Bug report
e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Needs review » Needs work

Thanks for this patch! Much needed.

Now that Schemata picking up pace again I hope we can get rid of the similar code that does this in JSON API Extras.

  1. +++ b/schemata_json_schema/src/Normalizer/jsonapi/SchemataSchemaNormalizer.php
@@ -69,6 +69,27 @@ class SchemataSchemaNormalizer extends JsonApiNormalizerBase {
+          unset($properties['properties'][$field_kind]['properties'][$field_name]);

    What about NestedArray::unsetValue. 

  2. +++ b/schemata_json_schema/src/Normalizer/jsonapi/SchemataSchemaNormalizer.php
@@ -69,6 +69,27 @@ class SchemataSchemaNormalizer extends JsonApiNormalizerBase {
+          break;

    Is this meant to read continue? 

  3. +++ b/schemata_json_schema/src/Normalizer/jsonapi/SchemataSchemaNormalizer.php
@@ -69,6 +69,27 @@ class SchemataSchemaNormalizer extends JsonApiNormalizerBase {
+        //$processed_properties[$field_kind][$resource_type->getPublicName($field_name)] = $property;

    Probably a leftover that can be removed. 

  4. +++ b/schemata_json_schema/src/Normalizer/jsonapi/SchemataSchemaNormalizer.php
@@ -69,6 +69,27 @@ class SchemataSchemaNormalizer extends JsonApiNormalizerBase {
+        if ($field_name !== $alias) {

    Let's keep a consistent style and do something similar to:

    if ($field_name === $alias) {
  continue;
}

    Like in 77 and 82.

    Alternatively we could unconditionally rename so we reduce the cyclomatic complexity by one.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Yes, this was super rough, but I figured a rough initial patch that at least works is better than the previous situation (not working and no patch).

Agreed with all points in #8 :)

(I don't think I'll have time to work on this before going on vacation next week, so I won't touch it for now — hopefully somebody else takes it further, and if not, then I'll have my work cut out for me when I get back to it, thanks to @e0ipso in #8 :))

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

@Wim Leers is this something you are still interested in?

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

My priorities currently lie with JSON API 2.x and issues closely related to that — I won't be working on this any time soon.

ShumaS’s picture

ShumaS commented
Status: Needs work » Needs review
StatusFileSize
new 2882269-12.patch2.87 KB

I`m update the patch as specified in comment #6, please check and add comments if there are any, thank you.

richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented

This patch looks good. Is there a good way to test that this correctly maps and filters fields? If so, it would be good to have tests for this.

richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented
StatusFileSize
new 2882269-6-12-interdiff.txt3.74 KB

Reviewing this patch again. Attached an interdiff of #6 and #12. #12 also introduces a few other changes, including moving the new logic to a dedicated method. Additionally it includes some code standards fixes. I think all the changes look good.

richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented
StatusFileSize
new 2882269-12-15-interdiff.txt2.73 KB
new 2882269-15-schemata-suppport-public-name.patch0 bytes

I took a pass over this patch to clean it up and integrate some of the work being done in jsonapi_extras

richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented

#3048718: Remove schema alterations for ResourceType::getPublicName() and ResourceType::isFieldEnabled() has been opened in order to remove the replaced code in jsonapi_extras.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Needs review » Needs work

The patch in #15 is empty.

richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented
StatusFileSize
new 2882269-15-schemata-suppport-public-name.patch3.72 KB

I suck at git/patches sometimes, sorry for the delay re-uploading this.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

Note that this is approached differently in #3053272: Update JSON:API Schema generation. Both patches try to solve the same issue, we should only merge one.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Related issues: +#3053272: Update JSON:API Schema generation
richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented

@e0ipso,

Now that #3053272: Update JSON:API Schema generation is merged. Can this issue be closed?

richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented
Status: Needs work » Closed (duplicate)

I got confirmation that this issue is handled in #3053272: Update JSON:API Schema generation