Closed (fixed)
Project:
JSON:API
Version:
8.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
26 Jan 2018 at 09:28 UTC
Updated:
28 Feb 2018 at 12:09 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
gabesulliceUpdating credits.
Comment #3
gabesulliceThis also depends on #2937961: ResourceType should provide related ResourceTypes.
Comment #5
wim leersUpdating title per #3.
Comment #6
gabesullice🎉 #2937961: ResourceType should provide related ResourceTypes landed!
Comment #7
wim leersWhat do you think about s/"public"/non-internal/? "public" is a term we don't use/is undefined in this context.
Or, better yet, just … no comment. A detailed explanation can be found in the related methods and interfaces.
Why is this helper method necessary?
s/$field/$field_name/
"internal field name" vs "non-internal relatable resource types"
These are two VERY different kinds of "internal".
Should be called
getAllowedResourceTypeNames().That, or the body should remove the
array_map().If
$fieldis already supposed to be an internal field name, then why do we need to call::getInternalName()?Comment #8
gabesullice1. I just removed it.
The "public" language came from
ResourceType::getPublicName()vs.ResourceType::getInternalName(), which I agree is conflating two different meanings of "internal". PerhapsgetFieldNameFromAliasandgetAliasFromFieldNamewould have been clearer, but it was introduced before internal data definitions.2. Small methods can make code more self-documenting and easier to read, which is why I love suggestions like #5 :)
3. 👍
4. I agree, see #1. I'm not sure how we can get around this without changing the ResourceType::getPublicName semantics (which might be a nice thing to do, it's worth discussing).
5. Excellent suggestion, monsieur.
6. Good catch!
Comment #9
gabesulliceComment #10
gabesulliceFurther clarified a comment.
Comment #11
wim leers#8:
Nit, but shouldn't we do the "is internal" check before getting the translation and use
continueinstead? Avoids unnecessary work/is slightly clearer.s/resource field/reference field/?
Nit: Perhaps mention that if the given field is NOT a reference field, that this will just return the empty array?
Once those nits are addressed, this is RTBC.
Comment #12
e0ipsoMartin Fowler always has something to say.
I've grown to dislike static methods because they are namespaced global functions. Hard to stub and test.
https://www.martinfowler.com/bliki/StaticSubstitution.html
Not suggesting a change, I only wanted to join the party 😝 in #11. This can be committed once @Wim Leers' comments have been addressed.
Comment #13
gabesulliceIn general, I've been trying to code/comment in the language of the spec over the language of Drupal as much as I can.
@e0ipso, I think the distinction is largely between public/protected static methods. Public methods, like
Node::load()should receive all the criticism that Martin Fowler brings up. They are "namespaced global functions". However, protected static methods are entirely different. They're not global at all. They simply indicate that the method doesn't use or mutate$this(how's that for a quote!? :P).Comment #15
wim leersShould be an easy fix. Then this is RTBC.
Comment #16
gabesullice🙃
Comment #17
gabesulliceComment #18
wim leersI was first wondering why we had to make this a property on the test class.
This is the reason.
One last question:
Why do we set this if we're not using it anywhere?
Comment #19
gabesulliceHm, dunno. Removed.
Comment #20
wim leersI extracted a test-only patch from #19. It passes tests, but it should not.
Comment #21
wim leersComment #22
gabesulliceThis requires an internal entity type for testing.
An issue for that has been opened here: #2943209: Mark at least one entity_test entity type as 'internal'
Comment #23
wim leersI don't think it make sense to postpone this on #2943209: Mark at least one entity_test entity type as 'internal'. I think this issue can continue by depending on the
content_moderationmodule and use that module's internal entity type for now. We can then have a follow-up for this issue that is blocked on #2943209: Mark at least one entity_test entity type as 'internal' which would use that internal test entity type instead.Comment #24
e0ipsoI agree with @Wim Leers. I don't think we should postpone one of our criticals based on a core issue that may (or may not) take months to resolve.
I don't think we should use
content_moderationbut I will not oppose it. I'd rather have ajsonapi_testmodule that builds uponentity_testto add that. Core can backport that at their own pace. Then we can deprecatejsonapi_testwhen #2943209: Mark at least one entity_test entity type as 'internal' is available in all supported core versions.This is what I meant to say the other day in Slack @gabesullice.
Comment #25
gabesulliceUn-postponing.
Comment #26
gabesulliceThese patches depend on: #2943209-13: Mark at least one entity_test entity type as 'internal'
The tests will be skipped in Drupal < 8.5 overall. My next patch is going to add a mirror of
EntityTestNoLabelinto a jsonapi_entity_test module so we can move forward if #2943209 takes too long to land. This will let us easily change the namespace when/if it finally does land as Mateu suggested in #24.Comment #27
gabesulliceHere's the JSON API only version. The test only patch should fail. The other one should be green.
The interdiff just shows the difference in the test file, not the addition of the test module.
Comment #30
gabesulliceFixing the test group.
Also including the interdiff mentioned in #27.
Edit: Testbot stole my comment number!
Comment #31
wim leersNit: Let's remove these lines.
Let's add a
@todoto remove this in the follow-up issue that #23 and #24 refer to.Nit: Missing inheritdoc.
Nit: Needs to be documented on the test class.
Nit: Does not need to be an object property (i.e. can become
$test_bundleinstead of$this->testBundle.)Nit: Same here.
First: this needs to be documented (see two points higher).
Second: "referencing entity" instead of "referencer entity", I think?
This seems unnecessarily complex, and the helper function seems to make things even more complex:
And once #2878463: [PP-1] Define a JSON API link relation for entities lands:
Comment #32
gabesulliceCan't wait for #31.8, that will be great.
Comment #33
wim leers… and when JSON API requires a core version that contains it. That can be fixed on commit.
This patch does come with proper test coverage (that's in fact the majority of this patch!), and does it in the way that @e0ipso indicated he prefers in #24. RTBC :)
Comment #35
wim leersComment #37
wim leersThis broke JSON API on Drupal 8.6: https://www.drupal.org/pift-ci-job/884832.
Looks like we're getting back a HTML 404 response.
Reverted.
Comment #38
wim leersDiscovered that regression at #2930028-68: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only.
Comment #39
gabesulliceThis includes the change from #35.
Comment #40
gabesulliceSince this was last committed, #2943209: Mark at least one entity_test entity type as 'internal' actually landed and was backported to 8.5. So it's safe to remove the JSON API placeholder :)
Comment #41
gabesulliceI don't know why this is in the interdiff. It's not in the patch though.
Comment #42
wim leers#40: Now that's a nice silver lining! 🎉
#40 was tested against both D8.4 and D8.6 … but before #2930028: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only was committed. Let's retest to make sure it still passes against both core branches.
If that comes back green, I'll commit this.
Comment #44
wim leersBoth came back green! Committed!