BatchController should not rely on DefaultHtmlFragmentRenderer directly [#2295367]

Problem/Motivation

BatchController::__construct() has the 'html_fragment_renderer' service injected, but instead of typehinting HtmlFragmentRendererInterface, it typehints the implementation of DefaultHtmlFragmentRenderer, and calls public methods on that service that are *not* on the interface.

This means that anyone swapping out the HtmlFragmentRenderer must extend DefaultHtmlFragmentRenderer directly, and cannot just rely on the interface.

Proposed resolution

@todo

Remaining tasks

Find a way to fix this.

User interface changes

API changes

Comments

Comment #1

Crell CreditAttribution: Crell commented 30 June 2014 at 20:19

The broader issue here is that batch API (and a few other edge cases) need to render totally non-standard pages. Currently they do so by going all the way up to Response, complete with using the rendering services themselves. While that can work, it's obviously sub-optimal and leads to bugs like this.

IMO the correct solution is for such edge cases to return their own HtmlFragmentInterface-implementing objects, and then have view listeners that listen for those objects and convert them to pages their own way rather than the default way. As long as they have a higher priority than the default one it should work fine with the way the system is setup, and be consistent with how we'r eusing the view listeners right now.

Comment #2

dawehner

German

CreditAttribution: dawehner commented 1 July 2014 at 08:57

The broader issue here is that batch API (and a few other edge cases) need to render totally non-standard pages.

Didn't batch API just needed a way to render a page without any blocks? Not sure but it feels like this should be doable with the display architecture.