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

That strikes me as a bad idea, and in particular the implication that role+model determines the SlotRoleHandler. If some slot actually wants to do such a thing, IMO that would be better with composition: having a SlotRoleHandler based on the role, which uses some per-model subhandler.

I see two general types of slots:

• Slots that do something special with the Content and require a particular content model to do that.
• Slots that deal with things at the ParserOutput level, that don't care what content model produced it.

It seems unlikely to me that we'll have some sort of hybrid where the same role does different particular things with different kinds of Content, and if it does it can easily enough be done with composition as mentioned above.

In my mind, role+title determines the SlotRoleHandler, and the SlotRoleHandler determines the content model.

I don't really see a use case for your second type of slots. Maybe a "documentation" slot that supports wikitext but also markdown, or something?

What you propose wrt per-role sub-handlers is actually pretty close to letting the handler for the main slot be determined by the current main slot's model on a given page. The only difference is whether the factory selects and returns the sub-handler up front, or whether you do dispatching/delegation based on the content model inside the main slot handler.

More generally, a "documentation" slot that doesn't care what the content model is, it just takes whatever HTML the Content produces and displays it wrapped in a documentation box. Chances are in most cases it'll be wikitext, but there's nothing really forcing that.

The same could be done with an "infobox" slot, with expected content types being wikitext or some structured data but any HTML output could be accepted. Or a "metadata" slot that exists solely to produce categories, set the display title, and so on.

The problem with "role+title" is that you're then having to have a bunch of configuration and logic to decide which of multiple handlers for the role based on the title, and you can more easily wind up in a situation where no handler exists for a role+title despite the page having content for that slot.

I see the complication, but I don't see the solution.

Your approach just seems to move the problem from SlotRoleRegistery into SlotRoleHandler. Am I missing something?

The SlotRoleHandler can be smarter about the branching (e.g. doing it on the user-specified content model rather than guessing based on the title), and knows more context by virtue of being the role handler rather than a generic dispatcher, and doesn't have to be generic one-size-fits-all by the same virtue.