Page MenuHomePhabricator

Handle form submission, data type validation, and inserting template markup into the WikiText (Infobox wizard)
Closed, ResolvedPublic8 Estimated Story Points

Description

Follows from T186662: Form for infobox wizard.

Acceptance criteria:
When you click submit...

  • It checks that the form data matches the data types specified in the TemplateData
    • If it doesn't match, it shows an error to alert the user
  • It formats the template WikiText according to the [[ https://www.mediawiki.org/wiki/Help:TemplateData#Custom_formats | format specified in the TemplateData ]]
  • It inserts the template markup into the page's WikiText at the correct cursor position

Event Timeline

kaldari created this task.
kaldari added a subscriber: Niharika.

With regard to matching formats, is it sufficient to provide relevant input widgets for the parameter type designations?

e.g.:

  • numberOO.ui.NumberInputWidget
  • boolean → Is there a tri-state bool widget of some sort?
  • datemw.widgets.DateInputWidget
  • 'wiki-user-namemw.widgets.UserInputWidget
  • 'wiki-page-namemw.widgets.TitleInputWidget
  • 'wiki-file-namemw.widgets.MediaSearchWidget
  • 'wiki-template-namemw.widgets.TitleInputWidget with only the template namespace.
  • and all others: OO.ui.TextInputWidget

I guess url can be parsed for correctness, perhaps.

Some other types are: content, unbalanced-wikitext, and line.

Once T53375 is done, we can add comboboxen to the list for pre-defined options.

Niharika is PMing this proof-of-concept, so I'll just chime in with my personal opinion/experience: I would absolutely love if the Infobox tool worked like a Contacts or Profile tool, with an intelligent GUI like you describe. However, I'm not sure there's actual data validation for type so we may provide a UI that inserts malformed parameters...

Definitely an idea worth exploring though!

@Samwilson Yeah, that sounds fine. We can also do some validation on inputs with pre-defined options.

With regard to matching formats, is it sufficient to provide relevant input widgets for the parameter type designations?

e.g.:

  • numberOO.ui.NumberInputWidget
  • boolean → Is there a tri-state bool widget of some sort?

I think we can use the usual boolean widget (two-state one) and have both options unchecked so that sorta makes it tri-state. The radio buttons cannot be unchecked upon checking though, IIRC.

  • datemw.widgets.DateInputWidget
  • 'wiki-user-namemw.widgets.UserInputWidget
  • 'wiki-page-namemw.widgets.TitleInputWidget
  • 'wiki-file-namemw.widgets.MediaSearchWidget
  • 'wiki-template-namemw.widgets.TitleInputWidget with only the template namespace.

These above four widgets don't allow auto-completion by default, right? Like for wiki page/file names?

  • and all others: OO.ui.TextInputWidget

I guess url can be parsed for correctness, perhaps.

Yeah, we can do some basic parsing there. We can also do a similar check for options with pre-defined values for now (until T53375 is implemented).

Some other types are: content, unbalanced-wikitext, and line.

Huh, how are those valid input types?

Niharika is PMing this proof-of-concept, so I'll just chime in with my personal opinion/experience: I would absolutely love if the Infobox tool worked like a Contacts or Profile tool, with an intelligent GUI like you describe. However, I'm not sure there's actual data validation for type so we may provide a UI that inserts malformed parameters...

Hmm, I don't think I understand. What do you mean by "I'm not sure there's actual data validation for type so we may provide a UI that inserts malformed parameters"?

For example — if I'm creating an infobox about a song, and I add duration as a parameter, I could mark in TemplateData the type as number. To my knowledge, TemplateData will not look at the template construction or its use on any page to validate if number is a valid type.

If the duration actually requires a string, then the user would not be able to provide the correct input in the GUI.

For example — if I'm creating an infobox about a song, and I add duration as a parameter, I could mark in TemplateData the type as number. To my knowledge, TemplateData will not look at the template construction or its use on any page to validate if number is a valid type.

If the duration actually requires a string, then the user would not be able to provide the correct input in the GUI.

Ah, I see what you mean. I don't think it's a big problem though. It's up to the template creators to ensure that there isn't a mismatch between expected and specified types. From what I can tell, most template editors haven't even bothered to tell TemplateData what to expect as type so the default is "string" pretty much everywhere (for instance see birth_date and death_date here). So we should make use of the type information wherever we can.
Furthermore, the template is ultimately being copied into wikitext, where it can be changed however the user wishes.
We can come back to re-evaluate if this is a problem in future if we get feedback telling us it is.

Samwilson edited projects, added Community-Tech-Sprint; removed Community-Tech.

Should part of this be done in TemplateData? e.g. a new class mediaWiki.TemplateData.TemplateFormatter that would handle the actual generation of the template text, including the formatting.

Should part of this be done in TemplateData? e.g. a new class mediaWiki.TemplateData.TemplateFormatter that would handle the actual generation of the template text, including the formatting.

Seems like an awkward fit for TemplateData. I like keeping TemplateData as a pure data input layer. Generating the output should be handled completely by TemplateWizard, IMO.

I guess I was just thinking that as that's the extension that defines the template formatting syntax, it could also provide some tools for working with it (and it's already got a GUI for creating the <templatedata> contents). But I'm happy either way.

Change 417234 had a related patch set uploaded (by Samwilson; owner: Samwilson):
[mediawiki/extensions/TemplateWizard@master] Restructure all classes, add tests, and start template creation

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

Patch https://gerrit.wikimedia.org/r/#/c/417234/ is ready for testing with:

mw.loader.load( 'https://en.wikipedia.org/w/index.php?title=User:Samwilson/TemplateWizard.js&action=raw&ctype=text/javascript' );

After we insert the template, do we want the cursor to be at the end or the beginning of the inserted text? At the moment it's the beginning.

Patch https://gerrit.wikimedia.org/r/#/c/417234/ is ready for testing with:

mw.loader.load( 'https://en.wikipedia.org/w/index.php?title=User:Samwilson/TemplateWizard.js&action=raw&ctype=text/javascript' );

After we insert the template, do we want the cursor to be at the end or the beginning of the inserted text? At the moment it's the beginning.

This looks great! I'd say having the cursor at the end makes more sense.
Two bugs I found while testing this -

  1. Cancel button doesn't seem to do anything.
  2. Testing with Infobox film on English wikipedia gives me a weird searchbox in the middle of the template wizard. Reproduced twice.

I'll cancel the cancelled cancelling.

And yeah, that seems to be mediawiki.gadgets.MediaSearchWidget. :-( I'll have a investigate. Maybe we just make it a page-name autocomplete, rather than a popup of thumbnails (even if we get the overlay grid of thumbs to work, it might be a bit odd in a small dialog box like that).

Fixed the buttons (also made the insert not appear till applicable, and the 'use' not work till there's a value). New code is up on enwp and in the gerrit patch.

Fixed the buttons (also made the insert not appear till applicable, and the 'use' not work till there's a value). New code is up on enwp and in the gerrit patch.

Cancel works great. I like the nice animation when it gets cancelled.
The MediaSearchWidget itself is great but the way it appears on top of text is incorrect. If we restrict it to appear for the correct param field, then it'd be awesome to use. I do still see the insert after the updated code.

Have just been playing around with this - looks great.

How about using a title input widget restricted to the file namespace? You can also set showImages to true to see thumbnails. (The MediaSearchWidget is designed for a full-page layout, e.g. see the search tabs in the gallery dialog and media dialog.)

That's a good idea. I've switched it to do so; see what you think.

That's a good idea. I've switched it to do so; see what you think.

Looks really good!

Change 417234 merged by jenkins-bot:
[mediawiki/extensions/TemplateWizard@master] Restructure classes, add tests, and insert template to editor

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