I agree with Joaquin. What are the benefits of decoupling? On Wednesday, April 15, 2015, Joaquin Oltra Hernandez < [email protected]> wrote:
> I don't see many advantages between the sub-module approach and just > leaving it in MobileFrontend and have Gather depend passively on a part of > MobileFrontend. I mean, the isolation can make us think that they are > decoupled but in reality they will still be highly coupled, and we'll need > to be as careful. > > It may help differentiate where Gather actually depends on MF and where it > depends on this base library, which could be useful to identify and remove > MF dependencies. Besides that, I don't see much else. > > Jon could you please elaborate on the advantages please? > > On Mon, Apr 13, 2015 at 9:44 PM, Jon Robson <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> No. Explicitly not. This would just be folding our code out into a sub >> module. The point is to remove dependencies! :) >> >> We dismantled it because code for templating when into core. >> On 13 Apr 2015 12:41 pm, "Bahodir Mansurov" <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> Essentially, does that mean we want to re-create Mantle? If so, we >>> should consider the reasons why we dismantled it. >>> >>> > On Apr 13, 2015, at 3:10 PM, Jon Robson <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >>> > >>> > I did a quick spike [1] to work out how Gather could stop depending on >>> > MobileFrontend. >>> > >>> > Essentially problems come into 2 categories: >>> > >>> > 1) Finding a place for Gather in the desktop skin and addressing >>> > styling issues in desktop skins (I am working on these and don't see >>> > any major blockers here). >>> > I think to fix this we simply need to provide Gather as a desktop beta >>> feature. >>> > This is tracked here: https://phabricator.wikimedia.org/T95227 and I >>> > see no issues with doing this. >>> > >>> > 2) frontend code standardisation >>> > The main problem with the hard dependency is that MobileFrontend uses >>> > a library that was built around the same time as OOJSUI. Migrating >>> > MobileFrontend to use OOJSUI is a big task and although has happened >>> > somewhat (the codebase now uses OOJS for class inheritance) it is by >>> > no means complete. >>> > >>> > Gather current depends on a variety of MobileFrontend modules which >>> > mainly include: API, overlay, user and user setting code, EventLogging >>> > schema code, notifications code. We also have a method >>> > mw.mobileFrontend.require and mw.mobileFrontend.define for defining >>> > modules. OOJS ui does this differently writing class names to the OO >>> > global variable object. >>> > >>> > ==The long term fix=== >>> > ... is obviously to migrate all the code to OOJS UI which I believe >>> > would require the following steps: >>> > * https://phabricator.wikimedia.org/T88559 which as an end result will >>> > rewrite overlay code in oojs ui >>> > * Rewriting mw.util.notify as an oo js ui component and folding the >>> > mobile toast notification into it. - >>> > https://phabricator.wikimedia.org/T66565 >>> > * Core should have a way to store user settings in localStorage rather >>> > than using $.cookie (similar to M.require( 'settings' ) ) - something >>> > akin to https://phabricator.wikimedia.org/T67008 >>> > * EventLogging Schema.js should be ported to oojs ui and moved into >>> core. >>> > * We only use user for the getEditCount function - it would be trivial >>> > to rewrite using mw.user >>> > >>> > == the short term fix== >>> > We could split out the frontend library MobileFrontend uses to allow >>> > us to share it between Gather and MobileFrontend. >>> > >>> > The way I see this working is to merge all the shared generic JS code >>> > into its own project just like oojs ui and slowly rewrite it there >>> > till it is pure oo js ui. This would take everything in the >>> > javascripts/common/ folder except application.js and bundle it into >>> > one file. >>> > >>> > We could include this as a submodule in both projects, both extensions >>> > conditionally adding a RL module for it when it does not exist. >>> > >>> > What do people think about taking this approach on the short term? >>> > >>> > [1] https://phabricator.wikimedia.org/T94100 >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> _______________________________________________ >> Mobile-l mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> >
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
