Page MenuHomePhabricator

Calendar input widget for dates in template parameters
Open, NormalPublic

Description

This feature request could be implemented together with T100205.

The current text input field for dates and times could be replaced with a calendar widget / text field combination (I'm thinking of something similar to Django's standard form for timedate objects). This would help ensure that users input properly formated dates and that the dates they enter are really the dates that they're thinking of (i.e. typical date formating errors would automagically disappear, e.g. MMDDYY vs DDMMYY vs DDMMYYYY, etc.).

My idea of a super dooper widget would look lke this: Left a text field and right a calendar widget. The calendar widget could be used to select a date. On selection the date would appear in the text field (e.g. ISO formating). The user could edit the date at that point. Alternatively, the text field could be used to enter the date. If the date could be properly parsed, the calendar widget would refresh and show the date. If not, the text form could shake and highlight red or otherwise notify the user that the date could not be properly parsed. Improperly formated dates would lead to disabling the submission button until the date field was either empty or well formed.

Event Timeline

Erget created this task.May 24 2015, 4:32 PM
Erget raised the priority of this task from to Needs Triage.
Erget updated the task description. (Show Details)
Erget added a project: VisualEditor.
Erget added subscribers: Magioladitis, Erget, Aklapper.
Esanders updated the task description. (Show Details)Sep 25 2015, 2:45 PM
AlexMonk-WMF renamed this task from Calendar input widget for dates in infoboxes to Calendar input widget for dates in template parameters.Apr 10 2016, 6:10 AM
AlexMonk-WMF added a project: OOUI.
AlexMonk-WMF removed a project: OOUI.
AlexMonk-WMF claimed this task.EditedApr 12 2016, 12:27 AM
AlexMonk-WMF added a subscriber: AlexMonk-WMF.

In MediaWiki we have:

alex@alex-laptop:~/Development/MediaWiki (warningfix)$ tree resources/src -f | grep -iE "(calendar|date|time).*Widget\.js$"
│   ├── resources/src/mediawiki.widgets/mw.widgets.CalendarWidget.js
│   ├── resources/src/mediawiki.widgets/mw.widgets.DateInputWidget.js
│   ├── resources/src/mediawiki.widgets.datetime/CalendarWidget.js
│   ├── resources/src/mediawiki.widgets.datetime/DateTimeInputWidget.js

A date in TemplateData is defined as:

A date in ISO 8601 format, e.g. "2014-05-09" or "2014-05-09T16:01:12Z".

So we need to be able to deal with a simple date but maybe also a time.

AlexMonk-WMF added a subscriber: matmarex.EditedApr 12 2016, 12:41 AM

mw.widgets.CalendarWidget and mw.widgets.datetime.CalendarWidget (why do we have both @matmarex?) do not extend InputWidget.
mw.widgets.DateInputWidget doesn't do times.

mw.widgets.datetime.DateTimeInputWidget looks like it basically does what we want, although I'm not sure I like the UI. And even when you set type: 'date' in construction config, getValue still returns a full time like "2014-05-09T00:00:00.000Z"

mw.widgets.datetime.DateTimeInputWidget.prototype.getValueAsDate only appears to return null when you set type: 'date' or 'time' in construction config
But that doesn't matter much as we'd probably only be using getValue.

The calendar only opens below the input which can cause issues when there is no more space - the dialog does not get scrolled to the bottom, it just disappears off the screen.
And it opens the calendar when you select the time inputs as well as the date inputs.

We have two sets of these widgets because @Anomie implemented one for ApiSandbox while I implemented the other for UploadWizard, simultaneously, and when we realized we're both working on the same thing, we couldn't quite agree on which features to keep. So both implementations stayed. It would be wonderful if you made some decisions and merged them into one. :)

A summary of the differences between the two are in T91148#1932034. Previous UI discussion is on M53, which itself went through various changes during development of the two widgets.

And even when you set type: 'date' in construction config, getValue still returns a full time like "2014-05-09T00:00:00.000Z"

That does not seem to be the case when I try it?

And even when you set type: 'date' in construction config, getValue still returns a full time like "2014-05-09T00:00:00.000Z"

That does not seem to be the case when I try it?

new mw.widgets.datetime.DateTimeInputWidget( { type: 'date', value: new Date( '2014-05-09' ) } ).getValue()

"2014-05-09T00:00:00.000Z"

And even when you set type: 'date' in construction config, getValue still returns a full time like "2014-05-09T00:00:00.000Z"

That does not seem to be the case when I try it?

new mw.widgets.datetime.DateTimeInputWidget( { type: 'date', value: new Date( '2014-05-09' ) } ).getValue()
"2014-05-09T00:00:00.000Z"

Looks like a bug in the constructor, if you actually put the widget in a page and set the value and then read it back it doesn't do that. https://gerrit.wikimedia.org/r/284022

mw.widgets.datetime.DateTimeInputWidget.prototype.getValueAsDate only appears to return null when you set type: 'date' or 'time' in construction config
But that doesn't matter much as we'd probably only be using getValue.

Can no longer reproduce anyway

And it opens the calendar when you select the time inputs as well as the date inputs.

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

The calendar only opens below the input which can cause issues when there is no more space - the dialog does not get scrolled to the bottom, it just disappears off the screen.

Still need to figure this bit out.

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 20 2016, 1:10 AM

The calendar only opens below the input which can cause issues when there is no more space - the dialog does not get scrolled to the bottom, it just disappears off the screen.

Still need to figure this bit out.

This is a pretty annoying issue that also affects DateInputWidget, that I haven't found a satisfactory solution to yet. Potential solutions would be putting a placeholder element with the same size at DateInputWidget's position (the real one is rendered in an overlay) to allow scrolling, or just displaying the calendar above the widget if there's not enough space below.

AlexMonk-WMF removed AlexMonk-WMF as the assignee of this task.Apr 25 2016, 4:55 PM