[#37456] - [5.3] New Date and Datetime fields
- Pending
- Medium
- Build: 4.2-dev
- # 37456
- Diff
- Fedik:datetime-fields
User tests: Successful: Unsuccessful:
Summary of Changes
Add 2 new input date (DateField class), and datetime-local (DatetimeField class). Fix Time field to support filter.
Links to MDN docs:
datetime-local: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local
date: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
Testing Instructions
Add fields in some XML, example in to mod_custom params:
<field type="date" name="date" label="Date"/>
<field type="time" name="time" label="Time" filter="SERVER_UTC"/>
<field type="datetime" name="datetime" label="Date Time" filter="SERVER_UTC"/>Expected result AFTER applying this Pull Request
Edit the fields, make sure the input works and values stored/displayed corectly
Documentation Changes Required
Add new fields info to list of fields: https://docs.joomla.org/Standard_form_field_types
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Layout Libraries |
| Labels |
Added:
?
Documentation Required
?
|
||
| Title |
|
||||||
Oh date time is deprecated
yes
datetime-local
This is DateTime here
Unfortunately month and week have bad support by Browsers, probably for another time
Or maybe I make another PR for them, will see.
Could you update the description please to be datetime not datetimelocal
What happens with non gregorian calendars?
What happens with non gregorian calendars?
It only gregorian. It is standart date and datetime-local input, works as described in HTML specs.
No more no less
Could you update the description please to be datetime not datetimelocal
Wich description do you mean?
It actualy displaing datetime-local, because datetime is deprecated (see @dgrammatiko coment)
@brianteeman that is correct.
Xml <field type="datetime"/> (wich is DatetimeField class in PHP), will render <input type="datetime-local">
nice and confusing
I would also deprecate our calendar field in favor of this one.
I would also deprecate our calendar field in favor of this one.
it not replacement, because it does not support non gregorian calendars
How do we handle gregorian calendars then?
How do we handle gregorian calendars then?
I assume you mean "non gregorian".
There a helper JS depend from language, one for jalali https://github.com/joomla/joomla-cms/blob/4.1-dev/build/media_source/system/js/fields/calendar-locales/date/jalali/date-helper.es5.js
Is this loaded then in this field?
Is this loaded then in this field?
Nope, that coded specificaly for calendar.js, it cannot be used somwhere else.
Only calendar field support "gregorian" and "non gregorian" calendars, that why it cannot be as replacement.
Also see my answer to Brian #37456 (comment)
If this pr can't be used in core, then I doubt we should add it. Especially when the fields can't be used all the languages we are supporting.
The fields is part of HTML5, that was missed in Form API.
Especially when the fields can't be used all the languages we are supporting.
They can be used, they translated by Browser.
It offers what HTML specification offers.
Support for different Calendars format it a huge different topic.
Is this issue still open? If yes, can I contribute to it?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37456.
If yes, can I contribute to it?
All is needed for this PR is to be tested
@laoneo could you elaborate on your thumbs down? Shouldn't Joomla implement the full HTML5 specs, and if so why?
You answered it here perfectly #36346 (comment). The core can never use this field, because we want to support also none gregorian calendars.
You answered it here perfectly #36346 (comment). The core can never use this field, because we want to support also none gregorian calendars.
You're mixing different things here. My comment that you are mentioning is about a tables sorting functionality that is totally a Joomla invented/created/coded thing but this PR is about adding some of the W3C platfrom's missing input types. So, yes Joomla shouldn't roll functionality about imaginary use cases (in the case of my comment the dev was going against the Joomla's architecture: items are direct descendants of a single category and asking to extend the functionality to cover their case) but also Joomla should FULLY support the HTML5 elements. Also Joomla rolls a few more input types that aren't actually used by the core, so that's not even an argument against, eg:
Joomla should FULLY support the HTML5 elements
Why? All I see here is a maintenance burden (even when it is small).
Color is used on many places, tel is used in contact and time in scheduler. Perhaps you should search other examples. Even then, when something can't be used in core, we should not add it.
Perhaps I miss here something, but from a maintainer point of view this looks like something which should be either published as custom field or in the respective extension, but not in core.
, tel is used in contact
No its not
joomla-cms/components/com_contact/forms/form.xml
Lines 169 to 171 in 1ee6427
but not in core.
Here is were I strongly disagree. For me ALL the HTML5 input fields should be provided from Joomla core for 2 reasons:
- Joomla's byproduct IS HTML5
- the core SHOULD roll those input types so devs cannot use their names for their own fields to prevent collisions (actually every dev should prefixing their input types/names so that won't ever be a thing)
But anyways, that's my point of view. Also one more thought here, if the maintainers of the project feeling intimidated to actually implement the full HTML5 specs then probably they shouldn't be maintainers of a WEB CMS...
How should an extension dev use this field then? Tell his customers that his extension is not working with gregorian calendars, but the rest of Joomla does?
If we are discussing on that level, then I'm out of this discussion. Do whatever you guys think is best for Joomla.
How should an extension dev use this field then? Tell his customers that his extension is not working with gregorian calendars, but the rest of Joomla does?
You mean non-gregorian calendars.
This pull requests has been automatically converted to the PSR-12 coding standard.
| Labels |
Added:
?
|
||
| Title |
|
||||||
I'm in favor for this PR, we can add a comment to the field that the browser support vor non-gregorian doesn't exists (yet) and the developer must decide if he/she needs it or not.
As long as this is a custom field and core doesnt change to use this field eg for publishing then I 100% agree as stated before.
obuisard
- | Labels |
Removed:
?
|
||
| Title |
|
||||||
| Title |
|
||||||
| Labels |
Added:
Feature
PR-5.0-dev
Removed: ? ? |
||
This pull request has been automatically rebased to 5.1-dev.
| Title |
|
||||||
| Labels |
Added:
PR-5.1-dev
|
||
I have tested this item ? unsuccessfully on 00f151d
Tested this item unsuccessfully on J5.0.3
The time field is not saved. The other two work just fine but what a god awful UI with these fields.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37456.
| Labels |
Added:
PBF
|
||
| Title |
|
||||||
| Title |
|
||||||
| Labels |
Added:
PR-5.2-dev
Removed: PR-5.0-dev PR-5.1-dev |
||
This pull request has been automatically rebased to 5.3-dev.
| Title |
|
||||||
Nice one. Not necessarily something for this PR but would be good to have support for these native inputs:
Oh date time is deprecated: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime#browser_compatibility