Problem/Motivation
There is a subtle difference in how RestExport::buildResponse
and Feed::buildResponse
function with regards to the response object. The former instantiates a response after the view is rendered, while the latter injects an empty response object into the view, so it can have headers added as needed.
For views built on top of the RestExport class, it would be nice to have access to the response object during processing, so for instance something like the Content-Disposition
header could be added.
Proposed resolution
Refactor the logic in RestExport::buildResponse
to inject an empty response into the views processing pipeline.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#14 | 2779807-14.patch | 4.41 KB | jhedstrom |
#9 | 2779807-09-TEST-ONLY.patch | 3.27 KB | jhedstrom |
Comments
Comment #2
jhedstromA practical example of using this can be seen here: https://github.com/d8-contrib-modules/views_data_export/pull/13/files#di...
Comment #3
dawehnerNice cleanup!
Comment #4
alexpottThis change looks testable.
Comment #5
jhedstromGood call!
Here's a test that ensures the response object is available when building/rendering the view (the test-only patch is the interdiff).
Comment #7
dawehner<3
Comment #8
alexpottThis is confusing. I guess you meant to have a test where
reset_test-views_set_header
is not set?Comment #9
jhedstromOops. Indeed, I was planning to do a test before/after. This adds that test.
Comment #12
jhedstromRe-queued #9 for testing, as those fails looked unrelated.
Comment #14
jhedstromI still can't see how those errors are related. Rebasing off of latest 8.3.x.
Comment #15
dawehnerFor future references you could also make your life easier and just invalidate the render cache tag, but nevermind :)
Comment #17
catchCommitted/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!
Comment #20
dawehneryou are drunk testbot
Comment #21
Wim LeersNice!