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

Looking through ContentHandler/Content, there are also these things:

• ContentHandler:
  • makeEmptyContent. Do we want to have role-based default values? (Specifically I'm thinking of roles holding JsonContent.)
  • getActionOverrides: these will effectively go away (maybe the main slot can use them but even that seems problematic), presumably replaced by something in PageTypeHandler. Do we need some new slot-level funcionality to replace them? E.g. customize the edit interface or do extra work on rollback/purge? Or just prevent certain actions? That's off-scope for the RfC but it should mention that this part will be filled in elsewhere.
  • createDifferenceEngine: do we want to tweak diff calculation or presentation for some roles? Make it more compact for example, or provide special handling for content model changes?
  • getPageLanguage/getPageViewLanguage: do we want or need a slot-level equivalent? Using a different language makes sense for some slots (e.g. source code is usually written in English, some slot might be in the interface language) but outputting lang attributes can be done in the HTML wrapping step, and I'm not sure what else the language would be useful for.
  • merge3: maybe some roles can do more intelligent conflict resolution by considering the usage patterns. E.g. a SAL-like slot where the content type is wikitext but conflicts where both edits append to the end can be special-cased.
  • getAutosummary: seems quite useful. Meaningful autosummary is rarely possible at the content level, while the slot can say things like "added <role>".
  • getChangeTag: seems useful for changes which do not normally happen (e.g. deleting a documentation slot) or are potentially disruptive (e.g. adding a templatestyle slot). But then, can be easily done via AbuseFilter as well so maybe it's needless complication (nothing seems to override the default ContentHandler behavior either).
  • getFieldsForSearchIndex/getDataForSearchIndex/getParserOutputForIndexing and similar methods in Content: some of this will probably move to the page level. Slot existence/nonexistence should probably be searchable but no need for any functionality in SlotRoleHandler for that. But slots will need to provide some sort of weight factor (finding a word in the template documentation slot is highly relevant; in the template itself, probably less relevant; in the template unit test slot, not relevant at all) at the very least. Maybe even more customization is needed.
• Content:
  • getWikitextForTransclusion: how would this work for non-main slots? Mostly they shouldn't be transcluded, but e.g. for TemplateStyles the current workflow is that you add a tag in the template; when SomePage.css becomes a slot on the template, we probably want to get rid of the tag as well and prepend automatically on transclusion.
  • isValid: do we want to add extra validation based on role? E.g. for the Wikidata description override, the content type would probably be TextContent, but an empty string or one containing newlines is not valid. It would be overkill to require a new content type just for that.
  • more generally, having an empty slot vs. a missing slot wasn't a meaningful difference before MCR (as "missing" would have meant page deletion) so little thought was given to it (although a long, long time ago there was much discussion about semi-deletion, and IIRC Flow also had something like that for a while), but now we should consider whether we want to keep the UI simple and use blanking as a slot deletion mechanism (or give role handlers some mechanism to decide whether they want that).
  • isCountable: should role handlers be able to suppress countable-ness of the content?
  • getSecondaryDataUpdates/getDeletionUpdates: role handlers should probably be able to add stuff. For example, various use cases that have been suggested involve CSS/JS slots. When slots change, the ResourceLoader module needs to be invalidated (currently that's not a data update but hardcoded in doEditUpdates, but we probably want to move away from that). The Content can't do that because it does not know its role name and the cache purge logic needs to differentiate between multiple CSS/JS slots on the same page.

• makeEmptyContent, merge3, isValid: Let's not if we can avoid it. If it's rare enough, an extension could just subclass the Content as they would now.
• getActionOverrides: That strikes me as a use case for a page type rather than anything that makes sense at a role level.
• createDifferenceEngine: I don't see much need for it to be role-specific, and handling changed models is out of scope IMO.
• getAutosummary, getChangeTag: Except "added role" and such wouldn't be determined at the slot level. That happens at the level of the revision as a whole, e.g. in EditController.
• Search stuff: Someone should probably ask the Search team.
• getWikitextForTransclusion: For the first version of MCR, I believe the plan is to have transclusion only transclude the main slot. When we add cross-slot stuff like the possibility of TemplateStyles automatically adding the stylesheet, that would be the time to consider expanding transclusion as well.
• Blanking as deletion: Let's not. We'll already need UI for adding a slot, also having UI for removing an existing slot doesn't seem like it would add too much more complexity.

makeEmptyContent. Do we want to have role-based default values? (Specifically I'm thinking of roles holding JsonContent.)

I think not. JsonContent is under-specified, it should really not be used directly. I'd love to make it abstract. JSON is a serialization format, it's not a content model at all.

getActionOverrides: these will effectively go away (maybe the main slot can use them but even that seems problematic), presumably replaced by something in PageTypeHandler.

Yes, this is among the main reasons I want a PageTypeHandler.

createDifferenceEngine: do we want to tweak diff calculation or presentation for some roles?

Maybe later. Since SlotRoleHandler is a base class, we don't need to have everything we may eventually need in there right away.

getPageLanguage/getPageViewLanguage

getPageViewLanguage should not be here at all. getPageLanguage() belongs to the Content.

merge3: maybe some roles can do more intelligent conflict resolution by considering the usage patterns.

That would indicate that it's a separate content model. SAL probably should be.

getAutosummary: seems quite useful. Meaningful autosummary is rarely possible at the content level, while the slot can say things like "added <role>".

I'm not convinced. "Added role" could come from PageUpdater. Also, something like "page blanked" needs to consider all slots at once.

getChangeTag

Potentially useful, but a bit unclear. What would this take as a parameter?

getFieldsForSearchIndex/getDataForSearchIndex/getParserOutputForIndexing

Perhaps the SlotHandler should be able to override getFieldsForSearchIndex, to provide boosts and the like. The rest is fine in ContentHandler, I think.

getWikitextForTransclusion:

For now, only the main slot can be translcuded directly. Non-wikitext transclusion is unclear anyway. I experimented with HTML-based transclusin a while ago. We'd need to re-open that can of works in order to get this right.

isValid: do we want to add extra validation based on role? E.g. for the Wikidata description override, the content type would probably be TextContent, but an empty string or one containing newlines is not valid. It would be overkill to require a new content type just for that.

It really doesn't make much of a difference whwther you define a new SlotRoleHandler subclass or a ContentHandler subclass...

isValid() needs to return a Status object anyway. Maybe this is an opportinity for fixing that, and to get rid of prepareSave().

more generally, having an empty slot vs. a missing slot

I'm not sure we want to offer any UI for directly removing a slot from a page.

isCountable: should role handlers be able to suppress countable-ness of the content?

Yes. And also redirects. I added:

• supportsRedirects()
• getArticleCountMethod()

getSecondaryDataUpdates/getDeletionUpdates: role handlers should probably be able to add stuff. For example, various use cases that have been suggested involve CSS/JS slots. When slots change, the ResourceLoader module needs to be invalidated (currently that's not a data update but hardcoded in doEditUpdates, but we probably want to move away from that). The Content can't do that because it does not know its role name and the cache purge logic needs to differentiate between multiple CSS/JS slots on the same page.

That sounds more like a PageTypeHandler use case. The CSS or JS may be used just for pages containing code, with no special meaning for the wiki. However, some pages have a special meaning for the wiki, and because of that special purging etc is needed. This has nothign to do with the slot (which is 'main' here, anyway).

• Role handlers of course should not be able replace the Action class, but they should probably be able to prevent complex undos, and do special handling on purges and rollbacks. So far this was available via action overrides, for roles it won't be so they need something else.
• Role handlers could generate nicer autosummaries (well, autosummary fragments). "Added template documentation", "Added 2 categories" etc...
• getChangeTag would take old and new content, like before. It's just that the tag might be specific to that role. (Yeah, not sure how useful that would be in practice. Even the Content-level ability to customize it does not seem to be used anywhere.)
• Search is the biggest issue IMO, and I agree with Brad that we should ask someone from that team.
• getWikitextForTransclusion: I think transcluding just the main slot is what we want 99% of the time anyway, and the remaining 1% could be handled easily by prepending/appending some tag or parser function that refers to the content of the other slots and having the extension's paerser function callback taking over from there. We just need the prepend/append ability.
• Having a UI for adding slots but not for removing them seems to be against wiki fundamentals. Unless we make the difference between no slot and empty slot very obscure, which goes back to my question.
• What does a redirect in a non-main slot do? Force the browser to visit the other page instead, like traditional redirects? Or just replace the contents of that slot with the contents of the target slot? There are use cases for the latter (e.g. shared template documentation) but they could be handled with transclusion as well, and maybe that would be less confusing.
• You can have CSS/JS in a non-main slot (TemplateStyles, CentralNotice, maybe gadgets). But the problem exists with any other kind of purge-able resource that can have multiple slots on a page. getSecondaryDataUpdates( Title, ...) is just not an appropriate interface when you are not using titles to address content objects anymore.

but they should probably be able to prevent complex undos

"Complex undos" are basically the same thing as resolving an edit conflict: if you have revisions A→B→C→D, and you want to undo B, it's the same as if you started editing at B and submitted the content of A as your edit, then try to merge3() the resulting edit conflicts due to C and D. I'm not sure there's too much point in trying to prevent such undos unless you're also preventing auto-fixing edit conflicts in general.

What does a redirect in a non-main slot do? Force the browser to visit the other page instead, like traditional redirects?

That's the one use case I can think of, instead of having every Content support some in-content syntax for redirects we could have a redirect slot or redirect as part of a "metadata" slot.

I see several interesting fine points and some rabbit holes here. While I'm tempted to dive in, I want to try to keep things simple in the name of finalizing the spec by Monday. So:

Which of these things do you believe need to be decided for a first version of SlotRoleHander?

Since we have a base class, we can easily add more methods later. What we can't easily do is remove methods or change signatures.

All of these are things we have in Content or ContentHandler right now which we might want to operate on the role level instead, so the only code change required would be to make sure a SlotRoleRegistry and a SlotRecord or such is available where the Content is available. That does not seem hard to do in the future, so I agree, we can easily do any of these later.