joomla-cms
joomla-cms copied to clipboard
joomla
[5.2] New Date and Datetime fields
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
Nice one. Not necessarily something for this PR but would be good to have support for these native inputs:
- datetime-local: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local
- month: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/month
- week: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/week
Oh date time is deprecated: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime#browser_compatibility
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 :wink: 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?
It only gregorian. It is standart date and datetime-local input, works as described in HTML specs. No more no less :wink:
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">
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?
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?
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 https://github.com/joomla/joomla-cms/pull/37456#issuecomment-1086619145
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 :wink:
@laoneo could you elaborate on your thumbs down? Shouldn't Joomla implement the full HTML5 specs, and if so why?
@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 https://github.com/joomla/joomla-cms/issues/36346#issuecomment-997437474. The core can never use this field, because we want to support also none gregorian calendars.
You answered it here perfectly https://github.com/joomla/joomla-cms/issues/36346#issuecomment-997437474. 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:
- https://github.com/joomla/joomla-cms/blob/4.1-dev/layouts/joomla/form/field/color/simple.php
- https://github.com/joomla/joomla-cms/blob/4.1-dev/layouts/joomla/form/field/tel.php
- https://github.com/joomla/joomla-cms/blob/4.1-dev/layouts/joomla/form/field/time.php
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
https://github.com/joomla/joomla-cms/blob/1ee64271a331317331a86ced18d012342b7b3a86/components/com_contact/forms/form.xml#L169-L171
Honestly @laoneo its a pathetic argument that you are making. I'm sure we all have better things to do
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...