Page MenuHomePhabricator

Make OOUI easier to use for gadgets
Open, HighPublic

Description

As I explained in T155473#2944504

For example when someone wants to make a dialog box in OOUI:

function MyDialog( config ) {
  MyDialog.super.call( this, config );
}
OO.inheritClass( MyDialog, OO.ui.Dialog ); 
MyDialog.static.title = 'Simple dialog';

MyDialog.prototype.initialize = function () {
  MyDialog.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 );
};
MyDialog.prototype.getBodyHeight = function () {
  return this.content.$element.outerHeight( true );
};
var myDialog = new MyDialog( {
  size: 'medium'
} ); 
var windowManager = new OO.ui.WindowManager();
$( 'body' ).append( windowManager.$element );
windowManager.addWindows( [ myDialog ] );
windowManager.openWindow( myDialog );

(Copied from here).

What I would love to see is some sort of form factory in JavaScript. Like HTMLFormFactory in PHP. So we only build an array of form descriptors and call it, then bam! the form is there. Something like:

windowManager.openWindow( 
  {
    name: 'MyDialog',
    title: 'Simple dialog',
    size: 'medium',
    elements: [
      {
        id: 'panel1',
        type: 'Panel',
        attr: { padded: true, expanded: false }
      },
      {
        tag: 'p',
        text: 'A simple dialog window. Press \'Esc\' to close.',
        parent: 'panel1'
      }
    ]
  }
);

And/or something like jQuery (which can consume existing HTML divs as the source of the dialogue:

<div id="MyDialog" title="Simple dialog">
  <p>A simple dialog window. Press \'Esc\' to close.</p>
</div>
$( function() {
   $( '#MyDialog' ).dialog();
 } );

Details

Related Changes in Gerrit:

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I'll say this again: YES.

We need this sort of abstraction for two reasons: ease of use, and more ability to change things about how it all works without breaking all the usage of it.

I get the idea here, but I think the task description by @Ladsgroup is not conveying what I think the idea is. His example above is an unfair comparison; the #dialog element has been defined somewhere else (using hard-coded HTML, or created on-the-fly using JS) and it has probably taken an equal number of rows of code as the OOjs UI example above.

I think what is being asked here is: create wrappers for basic use cases like simple dialogues, that can accept a simple list of form elements, for example in JSON, and creates and initiates the elements automatically.

If that is what is intended, then I will go ahead and change the task description accordingly. If not, I would appreciate clarification.

I get the idea here, but I think the task description by @Ladsgroup is not conveying what I think the idea is. His example above is an unfair comparison; the #dialog element has been defined somewhere else (using hard-coded HTML, or created on-the-fly using JS) and it has probably taken an equal number of rows of code as the OOjs UI example above.

No, read the documentation. It's three lines of HTML without any need to add classes, etc. Also It's not a competition which one has the least number of lines and quantifying difficulty of code by number of lines is an evil practice.

I think what is being asked here is: create wrappers for basic use cases like simple dialogues, that can accept a simple list of form elements, for example in JSON, and creates and initiates the elements automatically.

Have you worked with HTMLForm in mediawiki php? If not read this.

If that is what is intended, then I will go ahead and change the task description accordingly. If not, I would appreciate clarification.

Have you worked with HTMLForm in mediawiki php? If not read this.

Yes I have. And I think you and I are in agreement here! What is being asked is a simple way to define elements using associative arrays. Why don't you let me update the Task, and if it does not clarify you can revert it.

Huji updated the task description. (Show Details)

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.

I added the T101484 subtask because of this task's title (wide scope), not its description (narrow scope). In case only the narrower scope is desired, please clarify the title and edit related tasks.

Basically just make sure the title + description is something that's going to make sense on a wiki page for a voter who probably won't have time to read Phabricator discussions for all ~70 proposals.

This was the sixth most popular item in the Developer Wishlist results.

@matmarex you are one of the few people who has intimate knowlegde of both OOUI and HTMLForm. What do you think about building an exact replica of OOUIHTMLForm in JS (to cut down the learning curve and documentation costs)?

Volker_E moved this task from Backlog to Next-up on the OOjs-UI board.

Does this mean that this task is being committed, or in its way to? I am asking with big hopes to see this task moving forward, and reflecting that in the table at T158149: Find an owner for top 10 Developer Wishlist 2017 proposals. :)

@Volker_E Does this task need an owner? If so, would this be a good 2-3 month long project for a beginner? I'm asking as we are currently recruiting projects and mentors for GSOC 2017/ Outreachy Round 14.

Is this task specifically to Make OOjs UI dialogs easier to use for gadgets? Or is that just one example that we're talking about and should be added as a subtask?

Dialogs is an example, there are lots of things that need work.

Volker_E renamed this task from Make OOjs UI easier to use for gadgets to Make OOUI easier to use for gadgets.Jan 10 2019, 8:23 PM
Volker_E updated the task description. (Show Details)

@Ladsgroup Dialogs seems one of the biggest concerns, what other issues do you have in mind?

Change 365504 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[oojs/ui@master] SimpleDialogWidget: Create a simple dialog widget

https://gerrit.wikimedia.org/r/365504

@Ladsgroup Dialogs seems one of the biggest concerns, what other issues do you have in mind?

It has been a while since I developed a gadget using OOUI. I can ask others though.

Change 365504 abandoned by VolkerE:

[oojs/ui@master] SimpleDialogWidget: Create a simple dialog widget

Reason:

Assuming that it's time to abandon this patch. The tasks with the former links to the patch will continue to remain open in case someone else wants to pick up where we've left.

https://gerrit.wikimedia.org/r/365504

Izno closed this task as Declined.EditedAug 23 2025, 8:54 PM
Izno subscribed.

I'm actually going to decline this a few years down the road, since OOUI is largely deprecated in favor of Codex.

If Codex needs assistance, tasks specific to specific needs should be filed under that project.

Is (mass?) declining ooui tasks a good idea? Has codex achieved enough feature parity with ooui to replace it in all situations? Is ooui actually "deprecated", or discouraged, or just something softer?

I don't think it makes sense to say OOUI is discouraged for gadgets while T313945: [EPIC] Enable gadget and user-script developers to use Vue and Codex is still open. And then we'd need a Codex version of this task.

I wonder if MediaWiki just offer an API for converting HTMLForm descriptor arrays to HTML. HTMLForm is not great but it already exists; requiring an API call to generate forms is also not great, but very easy to implement.

As the author of this ticket. I feel two different points need to be made:

  • Yes, ooui and codex don't have feature parity yet. Specially on components that are related to mediawiki (page lookup, user lookup, etc.). That is hindering my work. For example, I really like to get rid of jquery ui in action=edit: T209059: Replace WikiEditor widgets with Codex components but since title lookup or image lookup doesn't exist in codex, I have to either re-implement it for something so simple or wait until it's done for some other product.
    • I acknowledge that codex is not a good place to hold mediawiki based components as it tries not to be bound to mediawiki (rightfully so, I have used codex in many non-mediawiki projects too) but a shared components library for mediawiki ones is missing and this is a major productivity issue.
  • The second point is this: Vue is deigned for complex, feature-rich web apps. It makes the life of the devs much easier. I've worked in a team that built the query builder in Vue and I quite liked it. But I think both vue or ooui are not suitable for concept of wiki gadgets where the most you want is a dialog that would call a couple of APIs to ban a user (and notify them). Ironically, jquery.ui was a pretty good library for that in terms of DX (and I say this as a person who hates jquery.ui with a burning passion). I think probably because in the internet of jquery.ui era, feature-rich frontend were not a thing.
    • I know building a simple dialog in codex is doable (and easier than ooui considering when T313945 is done) but to me feels like mowing your lawn with a tank. I wish there were an abstraction that could e.g. only load codex-css with some vanila js. That would make many of gadgets much easier to build/maintain and anything slightly more complex, they would be better to use vue/codex instead.

Thanks for these insightful comments. Re-opening for now per T155567#11112922

I wonder if MediaWiki just offer an API for converting HTMLForm descriptor arrays to HTML. HTMLForm is not great but it already exists; requiring an API call to generate forms is also not great, but very easy to implement.

Good idea. Worth exploring a bit more. I filed T402741: create a mediawiki core API that is a wrapper for HTMLForm

Re-opening for now per T155567#11112922

Be a little more patient maybe. I would have liked to respond and didn't get around to it midday yesterday.

Is (mass?) declining ooui tasks a good idea? Has codex achieved enough feature parity with ooui to replace it in all situations? Is ooui actually "deprecated", or discouraged, or just something softer?

I did not (mass?) decline OOUI tasks. I picked out the couple of tasks that I think have 0 expectation of being worked (use and documentation of OOUI for gadgets). I did this for a few reasons:

  1. Activity on Phab
  2. Activity in the code base
  3. https://www.mediawiki.org/wiki/OOUI which has

OOUI was deprecated in favour of Codex in MediaWiki 1.39. Codex is the recommended user interface design system for Wikimedia, and is used in all current and future product development. For more information, see OOUI. For migration guidance, see Codex/Migrating from MediaWiki UI.

It is indeed identified as deprecated by documentation via a patch version that is multiple years old at this point.

And lastly:

  1. OOUI is largely seen as a pain (indeed in the vein as Ladsgroup above says) at a minimum in the context of gadgets, so I anticipate 0 people wanting to spend more time on it in that context.

I don't think it makes sense to say OOUI is discouraged for gadgets while T313945: [EPIC] Enable gadget and user-script developers to use Vue and Codex is still open. And then we'd need a Codex version of this task.

I acknowledged that task directly. On its relation here. 1. that task itself has comments which already identify that It Works (at whatever quality of It Works), and 2. a similar task like this one is in the realm of "never closable" which is bad tasking anyway. Decide what hurts and make tasks for those issues. (See also T2001.)

a similar task like this one is in the realm of "never closable" which is bad tasking anyway.

The title of the task is vague, but if you read the task description, it's pretty clear: there should be a concise way to create common, simple widgets (dialogs etc) that does not involve a nontrivial amount of Javascript initialization code.