Jump to content

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

Anomie (talkcontribs)

IMO perpetuating the hard-coded MCR-like logic in WikiFilePage/ImagePage is not necessary. That can be generalized to multiple MCR slots without requiring page types.

Claiming that one small if() block in WikiPage::doEditUpdates() "effectively defines page types" for messages is a bit of a stretch, and I see nothing at all that has to do with modules (either Scribunto or anything else I can see). There could perhaps be better abstraction of per-namespace updates in there, although I'm not even sure of that.

I think the tangle being proposed here is a bit telling: page type is somehow determining roles which is somehow determining the main slot content model which is somehow supposed to determine page type.

Tgr (WMF) (talkcontribs)

Image pages for remote files transclude the description page from the remote file repository, if there is no local description (=main slot, post-MCR). That seems hard to do without some kind of page-level controller. The EXIF metadata stuff doesn't neatly fit into a slot either.

Not to mention file storage itself, fitting that into MCR is a whole new can of worms (with or without PageTypeHandler).

Anomie (talkcontribs)

Chances are that the remote repo stuff should happen at a higher level than MCR.

Tgr (WMF) (talkcontribs)

Maybe, but that's most of what WikiFilePage / WikiCategoryPage deals with, and it needs to go somewhere, whether we declare that somewhere inside or outside MCR. What would the alternative be?

(I agree that page type determining what roles can be used does not seem useful. It's a tangle either way though; extension X might want to provide a slot that supplements extension Y's slot, so it cannot be handled with a straightforward hook mechanism. Maybe all slot handlers should be called in a loop until they all stop modifying the list of allowed slots.)

Anomie (talkcontribs)

There will still be code in the handling of a view action that checks whether the page exists or not. If it does exist it'll get into MCR's rendering code. If not, that'd be where the global fallbacks (foreign files, global user page, etc) should happen.

Reply to "Ugh, Flow."