Page MenuHomePhabricator

Factor out the hard-coded magic for knitting together the PHP and JS side of TabLayout as built for Special:Preferences so others can use it
Closed, ResolvedPublic

Related Objects

StatusSubtypeAssignedTask
Declineddchen
OpenNone
OpenNone
DuplicateNone
OpenFeatureNone
OpenFeatureNone
DuplicateNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolved Ramsey-WMF
ResolvedCparle
OpenNone
Resolved PDrouin-WMF
ResolvedCparle
Resolved Esanders
ResolvedJdforrester-WMF

Event Timeline

Jdforrester-WMF created this task.

There is no magic, just a bunch of hardcoded HTML in PreferencesFormOOUI::getBody().

I think you want to write PHP versions of the relevant layouts/widgets, as I argued when this was implemented:

But really, if we want to be able to render these classes from PHP code, then we should implement PHP versions of them in OOUI (and move them, and their styles, from 'widgets' module to 'core' module), and then use that here. This would be easy to do, but very boring, but then sometimes you gotta make sacrifices :(

Jdforrester-WMF renamed this task from Factor out the magic for knitting together the PHP and JS side of TabLayout as built for Special:Preferences so others can use it to Factor out the hard-coded magic for knitting together the PHP and JS side of TabLayout as built for Special:Preferences so others can use it.Feb 8 2019, 6:39 PM

Change 493432 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseMediaInfo@master] Tabify file information and structured data

https://gerrit.wikimedia.org/r/493432

Change 493282 had a related patch set uploaded (by Jforrester; owner: Cparle):
[oojs/ui@master] PHP: Added server-side versions of IndexLayout and relations

https://gerrit.wikimedia.org/r/493282

CC @matmarex & @cscott

The above patch is attempting to implement various *Layouts in PHP.

My understanding is that currently infusion means re-generating the entire DOM in JS and replacing it; but with Layouts parts of the DOM need to be preserved, as user content will be appended to them.

It might be possible that we can do this by overriding gatherPreInfuseState on the various layouts, and add user-appended content to the state variable.

You two know much more about infusion, so perhaps you can advise?

Sounds like a good approach.

You might want to use reusePreInfuseDOM() instead, the result of which is passed to the constructor. If you use gatherPreInfuseState(), the result is passed to restorePreInfuseState(), which is only called after the infused widget is inserted into the DOM in place of the old one. In practice I suppose they would work mostly the same, but theoretically reusePreInfuseDOM()/constructor should be more efficient.

(gatherPreInfuseState()/restorePreInfuseState() was only intented for state that would be lost when we detach the PHP widget from the DOM, e.g. keyboard focus or scroll position in a <textarea>.)

reusePreInfuseDOM() also allows you to reuse the existing DOM elements, just attaching events to them etc., instead of re-generating them from nothing in JS. We've not made a lot of use of this yet, but InputWidget's $input uses it.

Alternatively, you could pick up everything that has been inserted inside the widget in PHP, and include it in the array returned by getConfig(). On a smaller scale, this is used by ActionFieldLayout and FieldLayout for their child widgets. I think the solution you proposed is better though, since this would duplicate a bunch of the HTML output.

Change 493282 merged by jenkins-bot:
[oojs/ui@master] PHP: Added server-side version of IndexLayout

https://gerrit.wikimedia.org/r/493282

Change 496356 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update OOUI to v0.31.0

https://gerrit.wikimedia.org/r/496356

Change 496356 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.31.0

https://gerrit.wikimedia.org/r/496356

This shipped in MediaWiki core from 1.33.0-wmf.22 onwards.