[18:40:51] Krinkle: ah, you have come across that tar pit too now :) I have long wanted to kill action overrides, and instead introduce "page types". We already have some hard coded (categories, image descriptions, user scripts, message pages), and some hacked in via content handler by extensions (e.g. wikidata). [18:42:49] duesen: I guess until MCR came along, this was analogous with content models, which doesn't seem like a hack to me [18:42:57] Page types would be determine by the title alone (namespace or ".js" extension, etc). They would control things like action overrides, and also the layout of multiple slots. Any anything else that currently varies for the kinds of pages mentioend above. [18:43:22] it's just that MCR messed that up, unless there is some overaching meta content model to handle it, which might make sense - where do we currently handle business logic of merging parseroutput/contenet objects into one? [18:43:53] Well, kind of... we have pages that share a content model but have different type behavior (message pages, image description pages). [18:45:01] Slot layout is currently in RevisionRenderer::combineSlotOutput. This is designed to be a "seam" where more flexible logic can be inserted. [18:47:35] Anyway - action names - and checking where an action exists, are rather hairy operations. See also the big comment in PermissionManager::checkUserBlock [18:48:44] That aside - action names should be defined outside the action, and should not be under the control of the action, I believe. It should work more like special page names. [18:49:03] The same action may be implemented by different classes in different contexts, but it would alway duesen: From a quick glance there, it doesn't seem like combination logic is extendible. There is a many-to-one relation between slot roles and content models, but afaik it's not enough to change the slot role for this unless we accept that non-wikitext pages will have 0 "main" slots and use their own override at that level to implement this. Speaking of that, I actually don't understand what a slot can/should do in practice. I've never [18:51:07] quite understood that level of abstraction. it seems both more flexible than needed and yet not flexible enough. [18:51:55] a page-level handler (whether WIkiPage subclass or new page type / page role) would presumably be able to trivially usurp that responsibility instead (which right now seems to just be whether to display the slot or not). [18:52:52] Note that there's also an old idea lying around to abolish "action" entirely in favour of just special pages. We've done this to a large extent already due to the messy nature of action overrides. [18:53:31] The main issue that that brings up is discoverability. It requires skin-level hooks to insert the links in the UI, which are based on guess work and approximating the page type, which aren't ideal. [18:56:04] it woudl match what we do for API and REST, there is only one flat list of actions to perform that take a title parameter or other kind of parameter. Not two separate worlds. e.g. "edit", "undelete", "login" and "newslettersubscribe" (extension) are siblings in the API [18:56:18] but in the UI, most are special pages with a few legacy actions [18:58:25] maybe ContentHandler::getSomething() would work as a way to aggregate a declarative array of possible actions to perform, which can express themselves in the UI as URLs to special pages (possibly with redirect to actions during the transition). Or if we need a page-level override, something like your page types or WikiPage-handler to make the final decision (with default being to accumulate from the page's slot's content objects) [19:36:14] Krinkle: I agree that SlotRoleHandler isn't really useful, PageTypeHandler is really want we want. It would control the slots and their meanings. [19:37:04] The original idea was that you could mix and match slots, and slots could have behavior associated with them beyond the content model. But in practice, it seems like such behavior is really for a combination of slots. [19:37:47] In my mind, the distinction of actions and special pages is that actions always operate on a specific page, and can be overwritten based on the type of that specific page. [19:39:13] as to the content layout: implementation of a flexible/configurable system was removed from the scope of the mcr project, so we hardcoded the bare minimum. Today, I would go for a PageTypeHandler concept that controls the layout.