pmiazga added a comment.
> if ( ExtensionRegistry::getInstance()->isLoaded( 'MobileFrontend' ) ) {
> $mobileContext = MediaWikiServices::getInstance()->getService(
'MobileFrontend.Context' );
> $isMobileView = $mobileContext->shouldDisplayMobileView();
> if ( $isMobileView ) {
> $out->addModule( 'ext.foo.bar' );
> }
> }
One thing that I'm worried about is this approach will create a tight
coupling between any extension and MobileFrontend, and if for any reason we
need to change MobileFrontend API, then all places that call it would have to
be updated. I know it's a common case and plenty of extensions do it this way
(https://codesearch.wmcloud.org/search/?q=shouldDisplayMobileView&files=&excludeFiles=&repos=).
This is what we currently do but I think if we could improve this. Especially
now as it looks like that with removing the target system more and more things
will require this check.
I'm wondering whether this should be a responsibility of the `OutputPage`
class or MW Core in general. Therefore I'm thinking about a better approach
where communication happens between extensions and MW - not between extensions.
MW has a notion of things, but does not implement those - and extensions
provide capabilities. To check for the capability - you ask MW Core if it can
handle such a scenario (thus you can have multiple extensions providing
specific case - for instance, someone could provide their own MobileFrontend
implementation).
The mobile view is more a browser/device capability and maybe we could
provide some notion of Browser features/capabilities/(naming is hard) and let
the OutputPage be aware of context instead of depending on MobileFrontend
directly.
Another approach could be providing a Hook but I'm not sure if we want to
keep adding hooks.
@Jdlrobson what do you think? Is it something worth pursuing?
TASK DETAIL
https://phabricator.wikimedia.org/T324991
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: pmiazga
Cc: ItamarWMDE, Manuel, Lucas_Werkmeister_WMDE, StudiesWorld, Jdforrester-WMF,
Aklapper, Krinkle, Catrope, Legoktm, TrevorParscal, ori, Ricordisamoa, Krenair,
gerritbot, Florian, brion, Nikerabbit, Tgr, pmiazga, Ciencia_Al_Poder,
Tacsipacsi, JohanahoJ, Ltrlg, AntiCompositeNumber, Lens0021, kostajh,
Universal_Omega, Michael, Jdlrobson, Themindcoder, Adamm71, Jersione,
Hellket777, LisafBia6531, Astuthiodit_1, 786, Biggs657, karapayneWMDE,
Invadibot, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, Akuckartz,
Hook696, darthmon_wmde, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420,
Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic,
QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton,
Scott_WUaS, Izno, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Mbch331,
Jay8g
_______________________________________________
Wikidata-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
