Problem/Motivation
Having static methods on RendererInterface
causes people to call methods the default implementation of that interface directly.
Consequence: impossible to swap out the renderer.
Proposed resolution
Make the static method non-static.
(If there'd be many callers, we should maybe consider providing a trait similar to StringTranslationTrait
. But there's no need for that: there are only five calls to the 2 static methods, and they're all in "low-level" places.)
Remaining tasks
TBD
User interface changes
None.
API changes
TBD
Original report
See #2444231-68: Fix CacheableInterface so it makes sense (was: "Make Config objects & Entities implement CacheableInterface + add BubbleableMetadata::createFromCacheableObject()").1 + #2444231-62: Fix CacheableInterface so it makes sense (was: "Make Config objects & Entities implement CacheableInterface + add BubbleableMetadata::createFromCacheableObject()").1.
Comment | File | Size | Author |
---|---|---|---|
#20 | interdiff-2460695-18-20.txt | 1.03 KB | mitrpaka |
#20 | no_methods_on-2460695-20.patch | 9.21 KB | mitrpaka |
#18 | interdiff-2460695-16-18.txt | 5.46 KB | mitrpaka |
#18 | no_methods_on-2460695-18-0.patch | 9.2 KB | mitrpaka |
Comments
Comment #1
rpayanmPlease review.
Comment #3
mitrpaka CreditAttribution: mitrpaka commentedUpdated patch to pass unit test cases.
Comment #4
dawehnerWhat is the reason we can use
NestedArray::mergeDeep
instead of the implementation of the renderer.Comment #5
Wim LeersComment #6
mitrpaka CreditAttribution: mitrpaka commentedNestedArray::mergeDeep
does exactly what static method of mergeAttachments did.rendered
service is not valid when called out from the global services container. If implementation of the renderer is to be used then (I guess) service should be injected somehow via setter methods.Please advise / help which way to go from here?
Comment #7
Wim Leers@mitrpaka: in cases like this, we usually do something like:
And then:
$this->getRenderer()->mergeAttachments()
.Comment #8
mitrpaka CreditAttribution: mitrpaka commentedDid try that already but unit test cases fails due to missing (global services) container.
"\Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container."
Comment #9
Wim Leers@mitrpaka: see e.g.
\Drupal\Tests\Core\Session\AnonymousUserSessionTest
for an example of how to deal with that.Comment #10
rpayanmI can do something like this?
Comment #12
Wim Leers#10: that only works for plugins, because plugin instances are created using the static
::create()
method, but Response objects are created usingnew (Ajax)Response()
.Comment #13
rpayanmThen let me try with #7.
Comment #15
Wim LeersNow something like #9 is still necessary to fix the last few failures.
Comment #16
mitrpaka CreditAttribution: mitrpaka commentedFirst trial to fix the last few failures.
For some reason if container created using RendererInterface (instead of Renderer), e.g.
returned error (even though arguments were exactly the same in mergeAttachments())
Argument 1 passed to Drupal\Core\Ajax\AjaxResponse::setAttachments() must be of the type array, null given
Comment #17
Wim LeersThanks! Getting close! :)
Did you try
?
AFAICT that should allow you to get a mocked renderer with the
::mergeAttachments()
method exactly the same, without the need to mock all dependencies of the renderer :)(See https://phpunit.de/manual/3.7/en/test-doubles.html.)
Comment #18
mitrpaka CreditAttribution: mitrpaka commented@Wim Leers: Thank You! Was not aware of that (until now ;-).
Updated patch, as in #17.
Comment #19
Wim LeersIt takes a while to get the hang of PHPUnit :) Just giving the advice I wish somebody had given me long ago! :)
This looks great! Almost ready. Only nitpicks this time :)
We always typehint on the interface.
Just say "The renderer service." — that's enough :)
This should be:
(Just like in
ViewAjaxControllerTest
.)Comment #20
mitrpaka CreditAttribution: mitrpaka commentedThanks for the help and good advices once again!
Updated patch, changes as in #19.
Comment #21
Wim LeersPerfect, thank you! :)
Comment #22
alexpottThis issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed a0078c5 and pushed to 8.0.x. Thanks!
I considered asking for a CR but I don't usages of these methods with be widespread in custom or contrib yet - so I don't think it is worth the noise.