Closed (fixed)
Project:
JSON:API
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 Jan 2017 at 12:50 UTC
Updated:
21 Jan 2017 at 00:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
wim leersThis is blocked on #2841056: Remove use of plugins.
Comment #3
wim leersComment #4
wim leersSlight simplification:
11 files changed, 59 insertions, 82 deletionsComment #5
wim leersThis is blocking #2841296: Rename ResourceConfig & ResourceManager and remove their interfaces.
Comment #6
wim leersComment #7
wim leersNow quite a bit of simplification:
15 files changed, 91 insertions, 140 deletionsComment #8
e0ipsoComment #9
e0ipsoComment #10
e0ipsoIs it really worth it to add a whole new dependency to load an entity by UUID? Given that you can do it with the entity type manager and you need it a anyways…
Should we also rename all occurrences of
$bundle_idto$bundle?Comment #11
e0ipsoI'm unsure about:
Dependency injection is a glorified bag of global variables. Grabbing a copy of it multiple times or once makes little difference at a technical level. For me these changes introduce a bit of cruft (which is against the spirit of simplification). Additionally, we agree that a JSON-API resource is intimately coupled to an entity type and a bundle. It makes sense to me that a ResourceManager can provide the EntityTypeManager.
Thoughts?
Comment #12
wim leers#10.1: but this class does NOT use the entity type manager! It uses only the entity repository. Because all it needs, is to load entities. That's what the entity repository is for.
#10.2: Yes, we should. Good catch! I indeed forgot to update the local variables. Will reroll in the morning.
#11: The point of a container is that there is a single source of truth. Every time you're getting access to a service via something else, you risk being out of sync with the container (in case a service is overridden) — which is why code stopped doing that because it introduced subtle bugs. It also makes unit testing more difficult. It also makes it more difficult to see what the *actual* dependencies of a service are. And finally: this is simply a hard requirement in core! I challenge you to find a single service in core that has a public "getSomeOtherService" method!
Comment #13
wim leersDone.
Comment #14
e0ipsoCorrect! Sorry, I didn't read it right.
This got me convinced. Let's do this!
Comment #15
wim leersYay :)
Comment #17
e0ipsoI think the interdiff in #13 is reversed, anyways the code looks good.
This was committed with a minor change to the patch in #13. See interdiff.
Comment #18
wim leersOops, and thanks! :)