Update: With thanks from Roan IRL I worked out the above problem - it
was due to not calling the parent initialize function. I made a few
more tweaks and now I have a patch which moves MobileFrontend to using
OOJS Class system.
This is a big change that effects our entire stack with a bunch of
dependencies and potential merge conflicts. Your help moving towards
this would be much appreciated.
The following 5 patches need review in this order:
Move MobileFrontend to using OO.EventEmitter:
https://gerrit.wikimedia.org/r/129336
Kill use of super in MobileFrontend:
https://gerrit.wikimedia.org/r/159552
https://gerrit.wikimedia.org/r/159555
Switch to using OO.inheritClass:
https://gerrit.wikimedia.org/r/159553
After this is done it would be good to sit down and document ways we
can make better use of OOJS in mobile.
On Tue, Sep 9, 2014 at 4:47 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
Update: Roan's patch got merged but Max identified
an issue with it in
MobileFrontend which is stopping us switching over to use it in
MobileFrontend [1]
It seems to be related to an event that we use called 'progress' that
we use in our api handler.
You can replicate it by trying to do a wikitext edit in the stable
mode of the mobile site with the above patch.
Uncaught TypeError: Cannot use 'in' operator to search for 'progress'
in undefined
load.php?debug=false&lang=en&modules=ext.mantle%7Cext.mantle.hogan%2Cmodules%2Coo%2Ctemplates%7Cjqu…:68oo.EventEmitter.emit
load.php?debug=false&lang=en&modules=ext.mantle%7Cext.mantle.hogan%2Cmodules%2Coo%2Ctemplates%7Cjqu…:68(anonymous
function)
Not sure if this is an issue with OOJS or the patch Roan made for us.
Any ideas VE guys?
[1]
https://gerrit.wikimedia.org/r/#/c/129336/
On Fri, Aug 22, 2014 at 11:36 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside
> the mobile and Flow projects.
>
> The following 3 patches kicks off moving MobileFrontend's class model
> towards that of oojs - many thanks for Roan for doing most of the
> legwork :-):
>
https://gerrit.wikimedia.org/r/155593
>
https://gerrit.wikimedia.org/r/155589
>
https://gerrit.wikimedia.org/r/129336
>
> On the long term we'd look to swap out the Class.js and
> eventemitter.js files in MobileFrontend for oojs, but this is going to
> be tricky and require some care, possibly mixing both oojs and
> MobileFrontend's class code in the repository at the same time. e.g.
> increasing JavaScript on the short term, but reducing it on the
> longterm. The MobileFrontend core development team will need to work
> out how best to manage this transition.
>
> Since Flow is very DOM-focused, as opposed to many smaller JavaScript
> modules with element management per the currently-accepted use of
> OOjs, it is unclear how we may go about integrating with OOjs fully.
> However, some potential use cases have been identified as candidates
> for implementing OOjs on an interim basis, primarily by abstracting
> some current FlowBoardComponent workflows, such as those which handle
> (re-)rendering of existing and new content fetched from the API.