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?

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.

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.

In T156235#2997069, @Ricordisamoa wrote:

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