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

Crell’s picture

Crell commented

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.

dawehner’s picture

dawehner
Primary language German
commented

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.

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Fixed

It doesn't do any longer.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.