Page MenuHomePhabricator

Provide an alternative (more declarative) way to create classes in OOUI
Open, Needs TriagePublic

Description

Problem

Creating new classes/widgets with OOUI feels very cumbersome (see T155567). E.g. method declaration is split into different statements all across the source file.

Who would benefit

Any developer that wants to work with OOUI

Proposed solution

Create a high level function that allows more declarative creation of a class. E.g.:

OO.defineClass({
    className: 'MyExtension.ui.dialog.Edit' //"namespace" get's created automatically
    extends: 'OO.ui.Dialog',
    titleMsg: 'myext-dialog-edit-title',
    initialize: function () {
        MyExtension.ui.dialog.Edit.super.prototype.initialize.call( this );
        this.content = new OO.ui.PanelLayout( { padded: true, expanded: false } );
        this.content.$element.append( '<p>A simple dialog window. Press \'Esc\' to close. </p>' );
        this.$body.append( this.content.$element );
    }
});

Event Timeline

Osnard created this task.Jan 25 2017, 9:39 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 25 2017, 9:39 AM
Qgil added a project: OOUI.Jan 27 2017, 3:25 PM
RHeigl added a subscriber: RHeigl.Jan 31 2017, 4:29 PM

Meets a requirement of the MediaWiki Usage Report 2015: Developer support, skinning and UI

@Osnard @Ladsgroup help me understand if this task is similar to T155567. Both seems to be addressing the complexity of using OOJs UI for widgets, approaches might be different. Is that correct?

Tgr added a subscriber: Tgr.Feb 3 2017, 8:56 AM

T155567 is about writing a higher-level abstraction layer on top of OOUI; this just asks for a syntax change.

OO.defineClass({
    className: 'MyExtension.ui.dialog.Edit' //"namespace" get's created automatically
    extends: 'OO.ui.Dialog',
    titleMsg: 'myext-dialog-edit-title',
    initialize: function () {
        MyExtension.ui.dialog.Edit.super.prototype.initialize.call( this );
        this.content = new OO.ui.PanelLayout( { padded: true, expanded: false } );
        this.content.$element.append( '<p>A simple dialog window. Press \'Esc\' to close. </p>' );
        this.$body.append( this.content.$element );
    }
});

Would local variables get created automatically? How? (Eval is evil!) Doesn't that sound like magic?

What do you think about ECMAScript 2015 classes?

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Tgr updated the task description. (Show Details)Feb 5 2017, 3:06 AM

Pasting part of an email conversation I had with @matmarex here since its related:

In an email @Prtksxna wrote:

Are we currently converting Special pages in such a way that its possible to show some of them in dialogs (while still keeping the Special page). For example, Special:MovePage, choosing the Move option from the dropdown in Vector could open a ProcessDialog instead of taking the user to another page. The same could apply to some cases of Special:Block.
We did something similar in the initial UploadWizard prototype, with a single Uploader class that was used in the dialog. We did this to be able to have a dedicated Special page and have the VE dialog share the same code. I don't think we used the BookletLayout for the prototype as we ended up doing with the ForeignUploadDialog.
What are your thoughts on this, both from a design (special pages to dialogs) and OOUI perspective?

In response @matmarex wrote:

Phabricator does something similar for some actions, for example "View Remarkup" in a comment's dropdown menu – it opens in a popup normally, but you can middle-click the link to open it in a separate page.
We'd need some work to keep the no-JS accessibility – we'd probably have to invent something to be able to load the HTML of a special page, without the skin chrome, via AJAX, and put that in the dialog. (Or we'd need a duplicate JS implementation.) There is action=render, but it only works for content pages (e.g. https://en.wikipedia.org/wiki/Tsubaki_Grand_Shrine_of_America?action=render), not special pages.

Response by @Prtksxna:

If only there was a declarative way that could be used both by JS and PHP. Maybe something we should look at along with T155567: Make OOUI easier to use for gadgets and T156235: Provide an alternative (more declarative) way to create classes in OOUI.

Volker_E renamed this task from Provide an alternative (more declarative) way to create classes in OOJS (UI) to Provide an alternative (more declarative) way to create classes in OOUI.Jan 17 2018, 12:49 AM
Volker_E updated the task description. (Show Details)

Would local variables get created automatically? How? (Eval is evil!) Doesn't that sound like magic?
What do you think about ECMAScript 2015 classes?

@Ricordisamoa: You asked one year ago. Sorry for not responding. Shame on me. I can not answer your question completely, but there are libraries/frameworks that do something similar without eval ( e.g. [1]). I also like the idea of using ECMAScript classes, if that is feasible.

[1] https://docs.sencha.com/extjs/6.2.0/classic/src/ClassManager.js.html#Ext-method-define

Volker_E moved this task from Backlog to Next-up on the OOUI board.Feb 2 2018, 2:37 AM