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:
Kill use of super in MobileFrontend:
Switch to using OO.inheritClass:
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
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'
Not sure if this is an issue with OOJS or the patch Roan made for us.
Any ideas VE guys?
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 :-):
> 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.
> longterm. The MobileFrontend core development team will need to work
> out how best to manage this transition.
> 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.