Topic on User talk:Daniel Kinzler (WMDE)/MCR-SlotRoleHandler

It's not clear to me what model you're envisioning here.

My best guess is that wrapOutput() + getOutputPlacement() + registerOutput() would be used for a model that has a central combiner: wrapOutput() applies framing to the Content's ParserOutput, getOutputPlacement() hints to the combiner where to put that ParserOutput in the combined page, and registerOutput() I guess is to override the modules and such embedded in the Content's ParserOutput (bikeshed: that name sucks. registerOutputMetadata()?).

I'm not sure what placeOutput() is supposed to be as an alternative. Allowing for splitting one ParserOutput across multiple "locations"? That makes some sense, and may be needed if we want to slot-ify the existing (non-SDC) File page stuff (render the File itself at the top and the upload history below, assuming we don't move that to the history page). I'm not clear as to what the $layout parameter is supposed to do/be though.

Another option I don't see here would be to only have a method like registerOutput(), and let it use utility methods (or directly getRawText() and setText()) to do the placing of HTML blobs into $combinedOutput.

Your guess of my intention with wrapOutput() + getOutputPlacement() + registerOutput() is correct.

The idea of placeOutput() is that it directly puts the desired HTML into the $layout (somewhere/somehow), which is essentially an array of HTML chunks. This avoids the need to specify some kind of abstract layout constants to be returned by getOutputPlacement().

But in the end, this mechanism won't work for anything beyond a simple list anyway. More sophisticated layouts, e.g. a side-by-side view for translations/transcriptions, would need a more powerful controller (in my mind, a PageTypeHandler).

I intentionally didn't mention the third option. Manipulating a ParserOutput in that way seems extremely scary to me. manipulation of HTML strings should be avoided with strong prejudice, even if it's just appending - especially if there is no way to make sure that it's really just appending.

A "side-by-side view for translations/transcriptions" seems like a very specialized use case, at least if you want a display that tries to keep corresponding sentences side-by-side instead of just dumping two articles. Even with a PageTypeHandler it would still have to be doing the "extremely scary" manipulation of HTML strings to properly line things up, or else it would have to be bypassing the normal ParserOutput objects entirely in favor of doing its own parsing.

I'd go for the 80% solution and let people scroll and align manually. Not as nice, but still a lot better than having to deal with separate browser windows.

The translation view is just a very obvious examples. Many use cases could benefit from departing from the "one column" model.

But if and how that should be done doesn't have to be decided here. Here,we only need to decide how a slot indicates roughly where its content should be shown.